4 ms·

I'd be wary of "proving one's identity" via (one of) one's SSH key by connecting to an unknown SSH host. The main reason is a (maybe not on HN) little known sc

I'd be wary of "proving one's identity" via (one of) one's SSH key by connecting to an unknown SSH host. The main reason is a (maybe not on HN) little known scenario where the user has SSH key forwarding enabled, and the host they SSH to takes that forwarded identity and uses it to, say, fetch your private repos on github and the like. https://news.ycombinator.com/item?id=9425805 https://news.ycombinator.com/item?id=9425805 https://www.reddit.com/r/netsec/comments/3frnxb/my_ssh_server_knows_who_you_are_seriously_try_ssh/ https://www.reddit.com/r/netsec/comments/3frnxb/my_ssh_serve... I'd have _no problems at all_ signing a pgp message the likes of "I'm proving I am myself, and that you requested me to sign also with token QIMdoV76LIvymGvTxXEB8LkIIqfM4nEm5W"

marcosdumay 10y ago
In both cases, the key must be unique for the site. In both cases, key reusing would be very dangerous. But in both cases, you can have a single published key you can use to sign the site-specific shared keys.
tokenizerrr 10y ago
Well, most SSH keys are RSA keys. Could it not also be used for signing? Also you could use a special alias/command (-a) that explicitly disables agent forwarding.
kerkeslager 10y ago
This is pretty easily solved by using different keys for each service you wish to authenticate with (the same idea as using different passwords, basically). I already do this when pushing to GitHub over SSH versus SSHing into my own server.
- dice 10y ago
  This can become problematic if you're using an SSH agent and have 4+ keys loaded into it. The problem is that your agent will step through keys to try auth with, but most OpenSSH servers will reject keys after 3 failed attempts. This means that you also need to keep an up-to-date entry in ~/.ssh/config as to which key to use with which system.
  - matthewaveryusa 10y ago
    *6 attempts, I just looked that up today :)
  - ak4g 10y ago
    Do people not already do this? I don't really make an effort to use a different keypair for every service, but I ran into the the max-attempts thing very soon after I started using ssh-agent, and so I do have to keep my .ssh/config up-to-date. I assumed the benefit for ssh-agent was in not having to retype the passphrase for each connection, not for it to try every keypair for every login.
  - niftich 10y ago
    Is there a way to specify the hashed key fingerprint (or a just-long-enough subset of the key fingerprint) instead, as you try to authenticate to a specific host? Or an interactive key selection on the command-line? With a 'Remember my choice' option. These could be relatively easy UI enhancements for a command-line SSH agent.
    - frumiousirc 10y ago
      With the agent the -i flag or IdentityFile config option is not honored. You then must maintain different agents, one for each distinct set of keys you want to use. The ssh-ident package helps do this. Or, you must insert a filter proxy between the real agent and the ssh client. The ssh-agent-filter package helps do this.
  - kerkeslager 10y ago
    That's true, but I keep an up-to-date entry for each of my servers in my ~/.ssh/config anyway. Some of them don't even have hostnames; they only have IPs. I can't imagine having to remember that.
  - mook 10y ago
    That is very annoying; luckily, it's possible to use %h and other variables to embed the remote host name in the file name of the key. Definitely useful to also have IdentitiesOnly set to avoid the automatic attempts, though.
- beagle3 10y ago
  If you keep your keys on a smartcard, you'll need a number of cards that grows linearly with the number of keys.

marcosdumay 10y ago

In both cases, the key must be unique for the site. In both cases, key reusing would be very dangerous. But in both cases, you can have a single published key you can use to sign the site-specific shared keys.

tokenizerrr 10y ago

Well, most SSH keys are RSA keys. Could it not also be used for signing? Also you could use a special alias/command (-a) that explicitly disables agent forwarding.

kerkeslager 10y ago

This is pretty easily solved by using different keys for each service you wish to authenticate with (the same idea as using different passwords, basically). I already do this when pushing to GitHub over SSH versus SSHing into my own server.

dice 10y ago
This can become problematic if you're using an SSH agent and have 4+ keys loaded into it. The problem is that your agent will step through keys to try auth with, but most OpenSSH servers will reject keys after 3 failed attempts. This means that you also need to keep an up-to-date entry in ~/.ssh/config as to which key to use with which system.
- matthewaveryusa 10y ago
  *6 attempts, I just looked that up today :)
- ak4g 10y ago
  Do people not already do this? I don't really make an effort to use a different keypair for every service, but I ran into the the max-attempts thing very soon after I started using ssh-agent, and so I do have to keep my .ssh/config up-to-date. I assumed the benefit for ssh-agent was in not having to retype the passphrase for each connection, not for it to try every keypair for every login.
- niftich 10y ago
  Is there a way to specify the hashed key fingerprint (or a just-long-enough subset of the key fingerprint) instead, as you try to authenticate to a specific host? Or an interactive key selection on the command-line? With a 'Remember my choice' option. These could be relatively easy UI enhancements for a command-line SSH agent.
  - frumiousirc 10y ago
    With the agent the -i flag or IdentityFile config option is not honored. You then must maintain different agents, one for each distinct set of keys you want to use. The ssh-ident package helps do this. Or, you must insert a filter proxy between the real agent and the ssh client. The ssh-agent-filter package helps do this.
- kerkeslager 10y ago
  That's true, but I keep an up-to-date entry for each of my servers in my ~/.ssh/config anyway. Some of them don't even have hostnames; they only have IPs. I can't imagine having to remember that.
- mook 10y ago
  That is very annoying; luckily, it's possible to use %h and other variables to embed the remote host name in the file name of the key. Definitely useful to also have IdentitiesOnly set to avoid the automatic attempts, though.
beagle3 10y ago
If you keep your keys on a smartcard, you'll need a number of cards that grows linearly with the number of keys.