The CentOS machine would *not* permit logins with the public key's[...]
matching private key. I suspect it is because of PuTTY's public key
format:
---- BEGIN SSH2 PUBLIC KEY ----
When I changed the key in the authorized_keys file to the more standard format >ssh-rsa AAAA[...]==
then private key login succeeded.
Is this an issue? Should openssh be accepting PuTTY's key format? Or is >PuTTY's key format sufficiently obscure that PuTTY should change...
should I open a bug?
Chaim writes:
The CentOS machine would *not* permit logins with the public key's
matching private key. I suspect it is because of PuTTY's public key
format:
---- BEGIN SSH2 PUBLIC KEY ----[...]
When I changed the key in the authorized_keys file to the more standard format
ssh-rsa AAAA[...]==
then private key login succeeded.
Is this an issue? Should openssh be accepting PuTTY's key format? Or is >PuTTY's key format sufficiently obscure that PuTTY should change...
should I open a bug?
OpenSSH does not accept the standardised (RFC4716) public key format
(that starts "---- BEGIN SSH2 PUBLIC KEY ----").
Did you use the PuTTYgen Windows GUI tool to generate your keypair?
That tool has a control labelled "Public key for pasting into OpenSSH authorized_keys file", which contains the one-line format you needed.
I'm not sure how it could be clearer.
<https://the.earth.li/~sgtatham/putty/0.70/htmldoc/Chapter8.html#puttygen-pastekey>
Thank you for the clarification. I simply performed "Save public key" and tried to use the key in that file (RFC4716 format) ssh-copy-id. Perhaps in order to ease the use of the ssh-copy-id program, there could be a toggle option for "Save public key":"Putty format", "OpenSSH format". A user could then save directly to OpenSSH format and then be able to directly use the ssh-copy-id program.
On Tuesday, July 31, 2018 at 7:04:14 PM UTC+3, Jacob Nevins wrote:
Chaim writes:
The CentOS machine would *not* permit logins with the public key's >matching private key. I suspect it is because of PuTTY's public key >format:
---- BEGIN SSH2 PUBLIC KEY ----[...]
When I changed the key in the authorized_keys file to the more standard format
ssh-rsa AAAA[...]==
then private key login succeeded.
Is this an issue? Should openssh be accepting PuTTY's key format? Or is >PuTTY's key format sufficiently obscure that PuTTY should change... >should I open a bug?
OpenSSH does not accept the standardised (RFC4716) public key format
(that starts "---- BEGIN SSH2 PUBLIC KEY ----").
Did you use the PuTTYgen Windows GUI tool to generate your keypair?
That tool has a control labelled "Public key for pasting into OpenSSH authorized_keys file", which contains the one-line format you needed.
I'm not sure how it could be clearer.
<https://the.earth.li/~sgtatham/putty/0.70/htmldoc/Chapter8.html#puttygen-pastekey>
Thank you for the clarification. I simply performed "Save public key"
and tried to use the key in that file (RFC4716 format) ssh-copy-id.
Chaim Kutnicki <chaimkut@gmail.com> wrote:
Thank you for the clarification. I simply performed "Save public key"
and tried to use the key in that file (RFC4716 format) ssh-copy-id.
I can certainly understand why the OpenSSH maintainers wouldn't want
to support RFC4716 format in their actual authorized_keys file format.
Even if long-term stability of the format were not an issue (which
surely it is), it's also not at all clear how a multi-line public key
format would interact with the rest of the authorized_keys syntax
(e.g. force-command and other modifiers) involving prefixes on the
line containing the key.
But I wonder if having RFC4716 support in ssh-copy-id might be a more >feasible feature request? There's certainly no reason ssh-copy-id
couldn't recognise a file in that format and convert the public key to
the OpenSSH one-line format before writing it into the remote
authorized_keys file.
A patch to Windows PuTTYgen to add an option to save to a file in
OpenSSH format wouldn't be hard either; I'd accept one if someone felt >motivated to write it.
Sysop: | Keyop |
---|---|
Location: | Huddersfield, West Yorkshire, UK |
Users: | 293 |
Nodes: | 16 (2 / 14) |
Uptime: | 210:11:51 |
Calls: | 6,619 |
Calls today: | 1 |
Files: | 12,168 |
Messages: | 5,317,189 |