SSH automatically presents a public key to the server when trying to authenticate. If the server doesn't know that key, then SSH tries the next one. You can enumerate all of someone's keys this way (like https://blog.filippo.io/ssh-whoami-filippo-io/ SSH server does)
If you want to disable this sort of behaviour you can disable SSH from sending keys automatically, and then tell SSH which identity files need to be sent to each host.
In your .ssh/config, something like:
# Ignore SSH keys unless specified in Host subsection
IdentitiesOnly yes
# Send your public key to github only
Host github.com
IdentityFile ~/.ssh/id_rsa
With IdentitiesOnly, any explicitly configured via IdentityFile, or the default identity file if none are configured explicitly, is/are still sent. Using "-i /dev/null" in combination with IdentitiesOnly prevents that.
Interesting. If you're right, the manual leaves out the rather critical "or the default identity file" bit:
> Specifies that ssh(1) should only use the authentication identity and certificate files explicitly configured in the ssh_config files or passed on the ssh(1) command-line, even if ssh-agent(1) or a PKCS11Provider offers more identities.
Serious question, what's the real harm in this since it's just public keys? Just allowing a server to discover all the other servers you may have been talking to?
In most cases, no real harm. However, it does give away some information about you which can be used to fingerprint you. This data is also, I'm 99% sure, transmitted in plaintext, so a passive adversary can gather this information as well. For most uses I wouldn't worry about it. But, if you're an attacker, say forcing your way onto an SSH server with a weak password, it can be a valuable source of information for identifying you.
> This data is also, I'm 99% sure, transmitted in plaintext
I was curious about this, so I did some research.
First, if you run `ssh -v`, you can see that there's a key exchange (eg, Diffie-Hellman), then a cipher and MAC are negotiated, and only once you get to the user authentication portion do your public keys get sent to the server.
So, only Alice and Bob can see the public keys: not Mallory.
Ah yes, you're right! I remembered there is some stuff transmitted in plaintext at the beginning, but it's just the normal SSL cipher-suite negotiation.
If you have multiple ssh keys, that can easily make you run out of login attempts. I have a key per server/client pair (because I'm weird), all stuffed into my ssh-agent, so that breaks basically all logins for me.
So, to stop it iterating through your keys for a single host, you have to specify IdentitiesOnly globally? That would explain why I couldn't make it work last time I tried it.
If I recall correctly, if you specify it for a single host, it tries all your default keys then tries the specified key if nothing else worked. Which seems weird and wrong to me, but what do I know. Anyway, thanks for (possibly) solving a mystery for me.
Configuration options may be separated by whitespace or
optional whitespace and exactly one `='; the latter format
is useful to avoid the need to quote whitespace when
specifying configuration options using the ssh, scp, and
sftp -o option.
If you want to disable this sort of behaviour you can disable SSH from sending keys automatically, and then tell SSH which identity files need to be sent to each host.
In your .ssh/config, something like:
https://news.ycombinator.com/item?id=10004678