Never thought of using the token approach, though, definitely makes things simpler to work with.
Never thought of using the token approach, though, definitely makes things simpler to work with.
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.
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_dsaHaving 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.
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.