3 ms·

SSH is an incredibly versatile and useful tool, but many things about the protocol are poorly designed, including its essentially made-up-as-you-go-along wire f

by dlenski 7mo ago

SSH is an incredibly versatile and useful tool, but many things about the protocol are poorly designed, including its essentially made-up-as-you-go-along wire formats for authentication negotiation, key exchange, etc. In 2024-2025, I did a survey of millions of public keys on the Internet, gathered from SSH servers and users in addition to TLS hosts, and discovered—among other problems—that it's incredibly easy to misuse SSH keys in large part because they're stored "bare" rather than encapsulated into a certificate format that can provide some guidance as to how they should be used and for what purposes they should be trusted: https://cryptographycaffe.sandboxaq.com/posts/survey-public-keys-internet/#keys-that-were-not-generated-using-best-practices:~:text=SSH%20typically%20uses%20%E2%80%9Cbare%E2%80%9D%20keys%20and%20lacks%20a%20mechanism%20like%20the%20X.509%20key%20usage%20extension%20which%20can%20be%20used%20to%20define%20the%20intended%20purpose%20of%20a%20key%2C%20and%20thus%20limit%20its%20inadvertent%20misuse%20for%20an%20unrelated%20purpose https://cryptographycaffe.sandboxaq.com/posts/survey-public-....

Charon77 7mo ago
What good does certificate format do? Certainly won't make people not reuse it the same way. > where the affected users might be surprised or alarmed to learn that it is possible to link these real-world identities. I feel like it's obvious that ssh public keys publically identifies me, and if I don't want that, I can make different keys for different sites.
- bauruine 7mo ago
  ssh by default sends all your public keys to a server. Yes you can limit some keys to specific hosts but it's very easy to dox yourself.
  - ulrikrasmussen 7mo ago
    I had never thought about that. Seems like an easy problem to fix by sending salted hashes instead.
    - unsnap_biceps 7mo ago
      The server matches your purposed public key with one in the authorized keys file. If you don't want to expose your raw public key to the server, you'll need to generate and send the hashed key format into the authorized keys file, which at that point is the same as just generating a new purpose built key, no? Am I missing something?
  - grey-area 7mo ago
    Doesn’t it try one key at a time rather than send all?
    - unsnap_biceps 7mo ago
      It does, and there's typically a maximum number of attempts (MaxAuthTries defaults to 6 IIRC) before the server just rejects the connection attempt.
      - 84634E1A607A 7mo ago
        Yep, but this is server-side setting. Were I a sniffer, I would set this to 10000 and now I can correlate keys.
    - bauruine 7mo ago
      True but a server that wants to "deanonymize" you can just reject each key till he has all the default keys and the ones you added to your ssh agent. You can try it yourself [0] returns all the keys you send and even shows you your github username if one of the keys is used there. [0] ssh whoami.filippo.io
      - grey-area 7mo ago
        Nice, tried it out. This wording is incorrect though: "Did you know that ssh sends all your public keys to any server it tries to authenticate to?" It should be may send, because in the majority of cases it does not in fact send all your public keys.
    - rwmj 7mo ago
      Modern sshd limits the number of retries. I have 5 or 6 keys and end up DoSing myself sometimes.
      - grepfru_it 7mo ago
        This thread made me realize why fail2ban keeps banning me after one failed password entry :lightbulb:
  - est 7mo ago
    so it's good practice to store key in non-default location and use ~/.ssh/config to point the path for each host?
    - geocar 7mo ago
      Specifically to use a different key for each host.
    - 9dev 7mo ago
      What a great case of "you're holding it wrong!" I need to add individual configuration to every host I ever want to connect to before connecting to avoid exposing all public keys on my device? What if I mistype and contact a server not my own by accident? This is just an awfully designed feature, is all.
      - est 7mo ago
        > add individual configuration to every host I ever want to connect Are you AI? You can wildcard match hosts in ssh config. You generally have less than a dozen of keys and it's not that difficult to manage.
        kemotep 7mo ago
        I have over a dozen ssh keys (one for each service and duplicates for each yubikey) and other than the 1 time I setup .ssh/config it just works. I have the setting to only send that specific host’s identity configured or else I DoS myself with this many keys trying to sign into a computer sitting next to me on my desk through ssh. Like I can’t imagine complaining about adding 5 lines to a config file whenever you set up a new service to ssh onto. And you can effectively copy and paste 90% of those 5 short lines, just needing to edit the hostname and key file locations.
    - wasmitnetzen 7mo ago
      I would say it's best practice to use a key agent backed by a password manager.
- dlenski 7mo ago
  > > where the affected users might be surprised or alarmed to learn that it is possible to link these real-world identities. > I feel like it's obvious that ssh public keys publically identifies me, and if I don't want that, I can make different keys for different sites. You're probably not the only one for whom it's obvious, but it appears to be not at all obvious to large numbers of users.
dotwaffle 7mo ago
That's the point, though. An SSH key gives authentication, not authorization. Generally a certificate is a key signed by some other mutually trusted authority, which SSH explicitly tried to avoid.
- simonjgreen 7mo ago
  SSH does support certificate based auth, and it’s a great upgrade to grant yourself if you are responsible for a multi human single user system. It grants revocation, short lifetime, and identity metadata for auditing, all with vanilla tooling that doesn’t impose things on the target system.
  - waynesonfire 7mo ago
    > multi human single user system A rather niche use-case to promote certificate auth... I'd add the killer-app feature is not having to manage authorized_keys.
    - simonjgreen 7mo ago
      They are remarkably common in long lived enterprise Linux servers. Think eg database servers or web servers where they are of the (much longer lived) pet era not cattle era. Not sure why you need to belittle one example just to add another
- _bernd 7mo ago
  You can also sign ssh host keys with an ssh ca. See ssh_config and ssh-keygen man-pages...
- dlenski 7mo ago
  Agreed, this makes sense in principle. But what I found, empirically, is that a substantial number of observable SSH public keys are (re)used in way that allows a likely-unintended and unwanted determination of the owner's identities. This consequence was likely not foreseen when SSH pubkey authentication was first developed 20-30 years ago. Certainly, the use and observability of a massive number of SSH keys on just a single servers (ssh git@github.com) wasn't foreseen.
arcfour 7mo ago
SSH does have a certificate format that can place restrictions on what the user can do when connecting with that key. I'm not so sure about the hostkey side of things though. For example: https://smallstep.com/blog/ssh-vs-x509-certificates/#certificate-structure https://smallstep.com/blog/ssh-vs-x509-certificates/#certifi... you can see here that X11 forwarding is permitted for this certificate, among other things.

by dlenski 7mo ago

Charon77 7mo ago

What good does certificate format do? Certainly won't make people not reuse it the same way. > where the affected users might be surprised or alarmed to learn that it is possible to link these real-world identities. I feel like it's obvious that ssh public keys publically identifies me, and if I don't want that, I can make different keys for different sites.

bauruine 7mo ago
ssh by default sends all your public keys to a server. Yes you can limit some keys to specific hosts but it's very easy to dox yourself.
- ulrikrasmussen 7mo ago
  I had never thought about that. Seems like an easy problem to fix by sending salted hashes instead.
  - unsnap_biceps 7mo ago
    The server matches your purposed public key with one in the authorized keys file. If you don't want to expose your raw public key to the server, you'll need to generate and send the hashed key format into the authorized keys file, which at that point is the same as just generating a new purpose built key, no? Am I missing something?
- grey-area 7mo ago
  Doesn’t it try one key at a time rather than send all?
  - unsnap_biceps 7mo ago
    It does, and there's typically a maximum number of attempts (MaxAuthTries defaults to 6 IIRC) before the server just rejects the connection attempt.
    - 84634E1A607A 7mo ago
      Yep, but this is server-side setting. Were I a sniffer, I would set this to 10000 and now I can correlate keys.
  - bauruine 7mo ago
    True but a server that wants to "deanonymize" you can just reject each key till he has all the default keys and the ones you added to your ssh agent. You can try it yourself [0] returns all the keys you send and even shows you your github username if one of the keys is used there. [0] ssh whoami.filippo.io
    - grey-area 7mo ago
      Nice, tried it out. This wording is incorrect though: "Did you know that ssh sends all your public keys to any server it tries to authenticate to?" It should be may send, because in the majority of cases it does not in fact send all your public keys.
  - rwmj 7mo ago
    Modern sshd limits the number of retries. I have 5 or 6 keys and end up DoSing myself sometimes.
    - grepfru_it 7mo ago
      This thread made me realize why fail2ban keeps banning me after one failed password entry :lightbulb:
- est 7mo ago
  so it's good practice to store key in non-default location and use ~/.ssh/config to point the path for each host?
  - geocar 7mo ago
    Specifically to use a different key for each host.
  - 9dev 7mo ago
    What a great case of "you're holding it wrong!" I need to add individual configuration to every host I ever want to connect to before connecting to avoid exposing all public keys on my device? What if I mistype and contact a server not my own by accident? This is just an awfully designed feature, is all.
    - est 7mo ago
      > add individual configuration to every host I ever want to connect Are you AI? You can wildcard match hosts in ssh config. You generally have less than a dozen of keys and it's not that difficult to manage.
      - kemotep 7mo ago
        I have over a dozen ssh keys (one for each service and duplicates for each yubikey) and other than the 1 time I setup .ssh/config it just works. I have the setting to only send that specific host’s identity configured or else I DoS myself with this many keys trying to sign into a computer sitting next to me on my desk through ssh. Like I can’t imagine complaining about adding 5 lines to a config file whenever you set up a new service to ssh onto. And you can effectively copy and paste 90% of those 5 short lines, just needing to edit the hostname and key file locations.
  - wasmitnetzen 7mo ago
    I would say it's best practice to use a key agent backed by a password manager.
dlenski 7mo ago
> > where the affected users might be surprised or alarmed to learn that it is possible to link these real-world identities. > I feel like it's obvious that ssh public keys publically identifies me, and if I don't want that, I can make different keys for different sites. You're probably not the only one for whom it's obvious, but it appears to be not at all obvious to large numbers of users.

dotwaffle 7mo ago

That's the point, though. An SSH key gives authentication, not authorization. Generally a certificate is a key signed by some other mutually trusted authority, which SSH explicitly tried to avoid.

simonjgreen 7mo ago
SSH does support certificate based auth, and it’s a great upgrade to grant yourself if you are responsible for a multi human single user system. It grants revocation, short lifetime, and identity metadata for auditing, all with vanilla tooling that doesn’t impose things on the target system.
- waynesonfire 7mo ago
  > multi human single user system A rather niche use-case to promote certificate auth... I'd add the killer-app feature is not having to manage authorized_keys.
  - simonjgreen 7mo ago
    They are remarkably common in long lived enterprise Linux servers. Think eg database servers or web servers where they are of the (much longer lived) pet era not cattle era. Not sure why you need to belittle one example just to add another
_bernd 7mo ago
You can also sign ssh host keys with an ssh ca. See ssh_config and ssh-keygen man-pages...
dlenski 7mo ago
Agreed, this makes sense in principle. But what I found, empirically, is that a substantial number of observable SSH public keys are (re)used in way that allows a likely-unintended and unwanted determination of the owner's identities. This consequence was likely not foreseen when SSH pubkey authentication was first developed 20-30 years ago. Certainly, the use and observability of a massive number of SSH keys on just a single servers (ssh git@github.com) wasn't foreseen.

arcfour 7mo ago

SSH does have a certificate format that can place restrictions on what the user can do when connecting with that key. I'm not so sure about the hostkey side of things though. For example: https://smallstep.com/blog/ssh-vs-x509-certificates/#certificate-structure https://smallstep.com/blog/ssh-vs-x509-certificates/#certifi... you can see here that X11 forwarding is permitted for this certificate, among other things.