4 ms·

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 enu

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/ 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 https://news.ycombinator.com/item?id=10004678

IsmaOlvey 10y ago
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.
- deathanatos 10y ago
  > Specifying just IdentitiesOnly is not enough. In what manner?
  - js2 10y ago
    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.
    - pslam 10y ago
      Or just never install an identity in the default location (.ssh/id_*)
    - deathanatos 10y ago
      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.
      - js2 10y ago
        I verified the behavior with ssh -vv (macOS Sierra).
Joeboy 10y ago
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.
baby 10y ago
Are you sure it's not IdentitiesOnly=yes instead? Or do both work? (I have this line in my config: VisualHostKey=yes )
- akent 10y ago
  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.
jordigh 10y ago
I couldn't quickly remember how to not send my public keys at all, so I did "sudo -u nobody ssh ..." instead.
jit_hacker 10y ago
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?
- Belphemur 10y ago
  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.
- openasocket 10y ago
  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.
  - scott_karana 10y ago
    > 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 https://tools.ietf.org/html/rfc4253
    - openasocket 10y ago
      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.
- mook 10y ago

IsmaOlvey 10y ago

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.

deathanatos 10y ago
> Specifying just IdentitiesOnly is not enough. In what manner?
- js2 10y ago
  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.
  - pslam 10y ago
    Or just never install an identity in the default location (.ssh/id_*)
  - deathanatos 10y ago
    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.
    - js2 10y ago
      I verified the behavior with ssh -vv (macOS Sierra).

Joeboy 10y ago

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.

baby 10y ago

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

akent 10y ago
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.

jordigh 10y ago

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

jit_hacker 10y ago

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?

Belphemur 10y ago
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.
openasocket 10y ago
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.
- scott_karana 10y ago
  > 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 https://tools.ietf.org/html/rfc4253
  - openasocket 10y ago
    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.
mook 10y ago