4 ms·

Really like the approach here. In the past, I've typically managed my SSH keys by naming them as id_<purpose> like so, then tinkering with the ssh_config to mak

• sbf501 4y ago
  The config file already does this, this is just a shortcut with %h and the file system structure. You literally start an entry with "Host <hostname>" follwed by "User" and "IdentifyFile". There's even a bash autocomplete rule for it so you can tab through your servers "ssh <tab>". It won't send all the keys to the server if you organize this way (which doesn't really matter anyway, since they are PUBLIC KEYS). It resolves to a preference: using a file or the OS filesystem to organize your keys.
  • moviuro 4y ago
    > You literally start an entry with "Host <hostname>" follwed by "User" and "IdentifyFile". But that's so much pain. > The config file already does this, this is just a shortcut with %h and the file system structure. No. % ssh -F /dev/null -v whoami.filippo.io debug1: Trying private key: /home/moviuro/.ssh/id_rsa debug1: Trying private key: /home/moviuro/.ssh/id_ecdsa debug1: Trying private key: /home/moviuro/.ssh/id_ecdsa_sk debug1: Trying private key: /home/moviuro/.ssh/id_ed25519 debug1: Trying private key: /home/moviuro/.ssh/id_ed25519_sk debug1: Trying private key: /home/moviuro/.ssh/id_xmss debug1: Trying private key: /home/moviuro/.ssh/id_dsa
    • sbf501 4y ago
      Did you have an entry for "Host whoami.fillippo.io" in your config file?
  • tialaramex 4y ago
    > It won't send all the keys to the server if you organize this way (which doesn't really matter anyway, since they are PUBLIC KEYS). Having a public key doesn't teach an observer your private key, and so they can't impersonate you, but it does allow the observer to distinguish you from others. If you would like to prevent observers from correlating identity this way (most famously if you use a public key for GitHub and also other things) you will want to explicitly forbid your SSH client from offering to prove identities other than the one you know will be used. The setting in OpenSSH (which you can enable for individual Hosts) is IdentitiesOnly yes Your proposed configuration will choose to try the file named, but it will not tell the remote server that you don't have any other identities, for that you need IdentitiesOnly. The default is no, although I guess it's possible you have overridden that to "Yes" previously and then forgotten.
    • sbf501 4y ago
      > to distinguish you from others Yeah, that's a good point. The less information that is leaked, the better. > have overridden that to "Yes" previously and then forgotten. Another good point. I have this at the start of my macOS config: Host * IdentitiesOnly Yes UseKeychain Yes Edit: Uh oh, I think I misunderstood something! I'm still seeing nonexisting identify files being tried: % ssh -v whoami.filippo.io OpenSSH_8.6p1, LibreSSL 3.3.5 debug1: Reading configuration data /Users/x/.ssh/config debug1: /Users/x/.ssh/config line 4: Applying options for whoami.filippo.io debug1: /Users/x/.ssh/config line 21: Applying options for \* debug1: Reading configuration data /etc/ssh/ssh_config debug1: /etc/ssh/ssh_config line 21: include /etc/ssh/ssh_config.d/\* matched no files debug1: /etc/ssh/ssh_config line 54: Applying options for \* debug1: /etc/ssh/ssh_config line 58: Applying options for \* debug1: Authenticator provider $SSH_SK_PROVIDER did not resolve; disabling debug1: Connecting to whoami.filippo.io port 22. debug1: Connection established. debug1: identity file /Users/x/.ssh/id_rsa type -1 debug1: identity file /Users/x/.ssh/id_rsa-cert type -1 debug1: identity file /Users/x/.ssh/id_dsa type -1 debug1: identity file /Users/x/.ssh/id_dsa-cert type -1 debug1: identity file /Users/x/.ssh/id_ecdsa type -1 debug1: identity file /Users/x/.ssh/id_ecdsa-cert type -1 debug1: identity file /Users/x/.ssh/id_ecdsa_sk type -1 debug1: identity file /Users/x/.ssh/id_ecdsa_sk-cert type -1 debug1: identity file /Users/x/.ssh/id_ed25519 type -1 : Even though those don't exist, it is still trying them.
      • egberts1 4y ago
        That’s because you have your SSH client config having to try them all.
        • sbf501 4y ago
          But I have IdentityOnly: Yes for all hosts. Shouldn't that prevent it?
          • omniglottal 4y ago
            It appears that it's not so much attempting alternative identities as it's trying (potentially nonexistent) keys for different ciphers.