Allowing private keys without a newline at the end

[Damien Miller]

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