Hacker News Reader

Comment by diimdeep | Hacker News Reader

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

https://news.ycombinator.com/item?id=10004678

View on HN

If you want to do this only for a single invocation, this will work:

  ssh -o IdentitiesOnly=yes -i /dev/null host

Specifying just IdentitiesOnly is not enough.

> Specifying just IdentitiesOnly is not enough.

In what manner?

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.

I verified the behavior with ssh -vv (macOS Sierra).

Or just never install an identity in the default location (.ssh/id_*)

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?

Someone pulled thd public keys of github and created a ssh server that would greet you by your username/name.

Configuring your ssh correctly would avoid a specific system to link you to another one. More privacy issue than security.

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.

Further reading: SSH transport layer, https://tools.ietf.org/html/rfc4253

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.

I couldn't quickly remember how to not send my public keys at all, so I did "sudo -u nobody ssh ..." instead.

Are you sure it's not IdentitiesOnly=yes instead? Or do both work? (I have this line in my config: VisualHostKey=yes )

Tl;dr: both work. From the ssh_config man page:

  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.

Reply on news.ycombinator.com