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 _______________________________________________ openssh-unix-dev mailing list openssh-unix-dev@xxxxxxxxxxx https://lists.mindrot.org/mailman/listinfo/openssh-unix-dev
