“Ghost in the Shell - Remake”

Re:“Ghost in the Shell - Remake” by diimdeep on Monday April 24, 2017 @05:53AM (#14183024)

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

[ Parent | on HN ]

Re:“Ghost in the Shell - Remake” by IsmaOlvey on Monday April 24, 2017 @06:09AM (#14183090)

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.

[ Parent | on HN ]

Re:“Ghost in the Shell - Remake” by deathanatos on Monday April 24, 2017 @12:42PM (#14185738)

> Specifying just IdentitiesOnly is not enough.

In what manner?

[ Parent | on HN ]

Re:“Ghost in the Shell - Remake” by js2 on Monday April 24, 2017 @01:03PM (#14185967)

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.

[ Parent | on HN ]

Re:“Ghost in the Shell - Remake” by deathanatos on Monday April 24, 2017 @05:22PM (#14188423)

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.

[ Parent | on HN ]

Re:“Ghost in the Shell - Remake” by js2 on Monday April 24, 2017 @10:10PM (#14190207)

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

[ Parent | on HN ]

Re:“Ghost in the Shell - Remake” by pslam on Monday April 24, 2017 @01:38PM (#14186268)

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

[ Parent | on HN ]

Re:“Ghost in the Shell - Remake” by jit_hacker on Monday April 24, 2017 @07:49AM (#14183455)

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?

[ Parent | on HN ]

Re:“Ghost in the Shell - Remake” by Belphemur on Monday April 24, 2017 @08:54AM (#14183893)

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.

[ Parent | on HN ]

Re:“Ghost in the Shell - Remake” by openasocket on Monday April 24, 2017 @10:15AM (#14184460)

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.

[ Parent | on HN ]

Re:“Ghost in the Shell - Remake” by scott_karana on Monday April 24, 2017 @01:10PM (#14186021)

> 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

[ Parent | on HN ]

Re:“Ghost in the Shell - Remake” by openasocket on Monday April 24, 2017 @01:50PM (#14186362)

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.

[ Parent | on HN ]

Re:“Ghost in the Shell - Remake” by mook on Monday April 24, 2017 @07:47PM (#14189535)

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.

[ Parent | on HN ]

Re:“Ghost in the Shell - Remake” by Joeboy on Monday April 24, 2017 @06:29AM (#14183175)

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.

[ Parent | on HN ]

Re:“Ghost in the Shell - Remake” by jordigh on Monday April 24, 2017 @07:37AM (#14183417)

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

[ Parent | on HN ]

Re:“Ghost in the Shell - Remake” by baby on Monday April 24, 2017 @07:17AM (#14183348)

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

[ Parent | on HN ]

Re:“Ghost in the Shell - Remake” by akent on Monday April 24, 2017 @07:21AM (#14183367)

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.

[ Parent | on HN ]