3 ms·

So if ssh-rsa is going away, does that mean millions of smart card second factors will be bricked? Or since it's not RSA being taken out, is this just a matter

So if ssh-rsa is going away, does that mean millions of smart card second factors will be bricked? Or since it's not RSA being taken out, is this just a matter of updating .authorized_keys with new SHA256 hashes for the same keys?

tialaramex 6y ago
Neither. The smart card just makes RSA signatures over input data, and an updated SSH client will use SHA256 rather than SHA-1, as input data so nothing changes for the smart card. The Authorized Keys list is of actual public keys, not hashes, so that doesn't change. That's why the line length is much longer for a larger key (e.g. 4096-bit RSA) and shorter for small key like ECDSA.
- knorker 6y ago
  Doh, of course. Think-o on my part. Thanks. So in what sense is "ssh-rsa" going to be removed? Just as a protocol enum, with no user-visible impact for these purposes?
  - tialaramex 6y ago
    Both future clients and servers will refuse to do this algorithm, so it becomes user visible if your clients are not new enough to know anything acceptable to your servers or vice versa. The ssh-rsa algorithm is one of two authentication algorithms described in the first SecSH (IETF standardised SSH version 2) documents in 2006. The other (ssh-dsa) was never very popular and has been untrustworthy for a long time. So up until this point even a very old client or server could expect to interoperate with the latest software using ssh-rsa. Of course an individual setup might forbid this, but in general it could work. The announced change in OpenSSH means it will be necessary to give up on very old systems because they're incompatible, or else use a shim to restore compatibility if that's essential for you. This previously happened with SSH version 1 - once upon a time OpenSSH could interoperate with SSHv1, then it required a config override to allow that, and then they removed the compatibility from their source code entirely, but SSHv1 pre-dates the widespread modern popularity of SSH, so it probably had less impact than this will.

tialaramex 6y ago

Neither. The smart card just makes RSA signatures over input data, and an updated SSH client will use SHA256 rather than SHA-1, as input data so nothing changes for the smart card. The Authorized Keys list is of actual public keys, not hashes, so that doesn't change. That's why the line length is much longer for a larger key (e.g. 4096-bit RSA) and shorter for small key like ECDSA.

knorker 6y ago
Doh, of course. Think-o on my part. Thanks. So in what sense is "ssh-rsa" going to be removed? Just as a protocol enum, with no user-visible impact for these purposes?
- tialaramex 6y ago
  Both future clients and servers will refuse to do this algorithm, so it becomes user visible if your clients are not new enough to know anything acceptable to your servers or vice versa. The ssh-rsa algorithm is one of two authentication algorithms described in the first SecSH (IETF standardised SSH version 2) documents in 2006. The other (ssh-dsa) was never very popular and has been untrustworthy for a long time. So up until this point even a very old client or server could expect to interoperate with the latest software using ssh-rsa. Of course an individual setup might forbid this, but in general it could work. The announced change in OpenSSH means it will be necessary to give up on very old systems because they're incompatible, or else use a shim to restore compatibility if that's essential for you. This previously happened with SSH version 1 - once upon a time OpenSSH could interoperate with SSHv1, then it required a config override to allow that, and then they removed the compatibility from their source code entirely, but SSHv1 pre-dates the widespread modern popularity of SSH, so it probably had less impact than this will.