Why not support it as long as it can be loaded? It should complain but work. I regularly encounter certificate chains with comment like that in them and stuff loads them just fine. I would even hazard a guess that PEM specs allow it (they also explicitely allow CRLF if I remember correctly) Jan > On 24. 7. 2025, at 2:57, Damien Miller <djm@xxxxxxxxxxx> wrote: > > 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 _______________________________________________ openssh-unix-dev mailing list openssh-unix-dev@xxxxxxxxxxx https://lists.mindrot.org/mailman/listinfo/openssh-unix-dev
