Allowing private keys without a newline at the end

[Jan Schermer]

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 at mindrot.org> 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 at mindrot.org
> https://lists.mindrot.org/mailman/listinfo/openssh-unix-dev