openssh unix dev - Jul 2025 - Allowing private keys without a newline at the end

I recently opened a feature request in the bugzilla [0], and was
wondering if anyone has any opinions about it.
[0] https://bugzilla.mindrot.org/show_bug.cgi?id=3849

The full text of the bug:


Currently ssh and ssh-keygen don't manage to read private keys that
don't have a newline at the end. It fails with this error:
```
openssh-portable/$ ./ssh-keygen -y -f no_newline_ed25519
Load key "no_newline_ed25519": error in libcrypto
```
Adding a newline to the end fixes it:
```
openssh-portable/$ echo $'\n' >> no_newline_ed25519
openssh-portable/$ ./ssh-keygen -y -f no_newline_ed25519
ssh-ed25519 AAAAC3NzaC1lZDI1NTE5AAAAIImNVUrqnrw2eKhwaX1bGpNu3isBRESXny4NF9gjnHRi
comment
```
Earlier versions failed with an `invalid format` error.

I suggest not checking if there is a new line (\n) at the end of the
private key. This matches the behavior of openssl, and in general
makes it more user friendly. A lot of text editors don't show if there
is a newline at the end of the file, and private keys are often copied
and pasted.
See some examples for people having trouble with this behaviour: [1][2][3][4]
>From RFC 7468[5] it seems that a new line at the end of PEM encoded
messages aren't necessary, although if I understand correctly the
openssh key format isn't strictly in PEM format.
>From looking at the code, the main change needed is to remove the
'\n'
from the end of `MARK_END` in sshkey.c.

What do you think?

[1] https://github.com/semaphoreui/semaphore/issues/183
[2] https://github.com/openshift/console/issues/6858
[3] https://madhead.me/posts/private-key-newline-fuckup/
[4] https://github.com/jenkinsci/ssh-credentials-plugin/pull/33
[5] https://www.rfc-editor.org/rfc/rfc7468.html#section-3

On Wed, 23 Jul 2025, Yedaya Katsman wrote:
> I recently opened a feature request in the bugzilla [0], and was
> wondering if anyone has any opinions about it.
> [0] https://bugzilla.mindrot.org/show_bug.cgi?id=3849
> 
> The full text of the bug:
> 
> 
> Currently ssh and ssh-keygen don't manage to read private keys that
> don't have a newline at the end. It fails with this error:
> ```
> openssh-portable/$ ./ssh-keygen -y -f no_newline_ed25519
> Load key "no_newline_ed25519": error in libcrypto
> ```
> Adding a newline to the end fixes it:
> ```
> openssh-portable/$ echo $'\n' >> no_newline_ed25519
> openssh-portable/$ ./ssh-keygen -y -f no_newline_ed25519
> ssh-ed25519
AAAAC3NzaC1lZDI1NTE5AAAAIImNVUrqnrw2eKhwaX1bGpNu3isBRESXny4NF9gjnHRi
> comment
> ```
> Earlier versions failed with an `invalid format` error.
> 
> I suggest not checking if there is a new line (\n) at the end of the
> private key. This matches the behavior of openssl, and in general
> makes it more user friendly. A lot of text editors don't show if there
> is a newline at the end of the file, and private keys are often copied
> and pasted.
> See some examples for people having trouble with this behaviour:
[1][2][3][4]
> 
> From RFC 7468[5] it seems that a new line at the end of PEM encoded
> messages aren't necessary, although if I understand correctly the
> openssh key format isn't strictly in PEM format.
> 
> From looking at the code, the main change needed is to remove the
'\n'
> from the end of `MARK_END` in sshkey.c.
I don't think that's sufficient, because we don't want to support
keys
that look like

-----BEGIN OPENSSH PRIVATE KEY-----
b3BlbnNzaC1rZXktdjEAAAAABG5vbmUAAAAEbm9uZQAAAAAAAAABAAAAMwAAAAtzc2gtZW
[...]
-----END OPENSSH PRIVATE KEY-----somejunkonthesameline

So at the very least the key unwrapping code need to check for \n
or EOF as an end marker.

-d