4

When I connect to a SSH server I know that I am sending my publickey to be compared to authorized_keys file.

The question is how much from the public key is sended over the wire ? It includes user and hostname of the owner of the key?

How can I record this data ?

sektor
  • 65
  • 4
  • Related http://security.stackexchange.com/a/131762/86652 – techraf Aug 05 '16 at 00:04
  • SSH keys don't have an 'owner'. In OpenSSH (not the only implementation though an important one) a key can have a _comment_, and if you create with `ssh-keygen` (not the only way) by _default_ the comment is user@host doing the creation. You can change the comment to something else or delete it, and if you use something other than `ssh-keygen` there usually is no comment. If there is a comment, it's not sent to the server. The userid you are logging-on to _on the server_ is sent, always (even if not using publickey). – dave_thompson_085 Oct 28 '21 at 02:57

3 Answers3

4

When you connect to the SSH server, you are not sending your public key for comparison. Rather, what's going on is the client/server exchange data encrypted with the public key and then validate that the client does in fact have access to the corresponding private key.

In SSHv1, the server encrypts a message with the client's public key and the client returns a checksum of the message.

In SSHv2, the client encrypts a message with the client's private key and sends a signature of the message. The server then recreates the message and looks through authorized_keys to validate the signature.

In essence, what happens is the server tests to see if you can decrypt and then reply to information encrypted with the public key.

None of this is sent "over the wire" unencrypted, as an encrypted SSH connection is started before the exchange of these phrases.

To see further details, you can use WireShark, Snort, Suricata or another packet sniffer to inspect the raw traffic.

Herringbone Cat
  • 4,242
  • 15
  • 19
  • Well that's wierd because if I enable verbosity mode in sshd when I try to connect to it it outputs in log the ssh public key fingerprint of the computer witch attempts a connection (even if the key is refused) so that's why I asked. – sektor Aug 04 '16 at 18:08
  • @sektor one thing is a local log and another thing data sent over the network – The Illusive Man Aug 04 '16 at 20:56
  • @HerringboneCat and how does my public key fingerprint ends up in logs ? – sektor Aug 05 '16 at 05:50
  • same question for @Ay0 – sektor Aug 05 '16 at 05:50
  • @sektor because that's how it works. How would you know who logged into the machine then? – The Illusive Man Aug 05 '16 at 08:00
  • 3
    `you are not sending your public key` ... that is not true. In default configuration, before the authentication, the full public key is send to be compared with the authorized keys (of course in the established encrypted channel). After this successful comparison, what you describe is going on. – Jakuje Aug 05 '16 at 10:54
  • @Jakuje thanks, you should elaborate an answer because obviouslly this is a wrong answer as you can see in logs the public key fingerprint witch attempted an authentication (even if that key doesn't appear in authorized_keys). By "you are sending full public key" is with user@host appended to it belonging to creator ? – sektor Aug 05 '16 at 18:43
  • @HerringboneCat: When you say `In SSHv2, the client encrypts a message with the client's private key and sends a signature of the message`, don't you mean `In SSHv2, the client encrypts a message with the **server's public** key and sends a signature of the message`? Private keys are for decryption and signing, not encryption, and in any case the client needs to verify that the server's key pair is correct (which your described scheme wouldn't do)! – CBHacking Aug 06 '16 at 03:10
4

Ok, I was pushed to write up some answer to clear things up. Not that the other would be completely wrong, but it does not show the whole picture of what is going on in the SSH protocol.

The authentication to ssh server works in two steps. The first one is validation if your public key is in the authorized_keys file, the second one checks if the signature provided by the appropriate private part is valid. In the server debug log, you can see:

sshd[9951]: debug1: test whether pkalg/pkblob are acceptable
sshd[9950]: debug1: matching key found: file /home/user/authorized_keys, line 1
sshd[9950]: Found matching RSA key: 8b:3c:20:c5:03:c4:c0:03:74:83:0a:8f:2d:d8:48:a2
sshd[9951]: Postponed publickey for vagrant from 10.0.2.2 port 54361 ssh2

referring to the first step (test whether pkalg/pkblob are acceptable). And later one

sshd[9950]: debug1: matching key found: file /home/user/authorized_keys, line 1
sshd[9950]: Found matching RSA key: 8b:3c:20:c5:03:c4:c0:03:74:83:0a:8f:2d:d8:48:a2
sshd[9950]: Accepted publickey for user from 10.0.2.2 port 54361 ssh2
sshd[9950]: debug3: mm_answer_keyverify: key 0x7f54ce6ac570 signature verified

is checking the real signature made by the private part of the key.

Slightly paraphrased my answer from different question on sec.SE

But note, that the first step is not compulsory. If you specify only private key, or force the usage of specific key, the first step is skipped and in this case, the above question is correct.

All the above communication (authentication) is already encrypted. It goes on the wire, but it is not possible to intercept it in between. The server has to see it, if you offer this key.

If you are worried about your public key, note that for example Gitbub is exposing the public keys on the url https://github.com/<username>.keys. It is not a big deal as a name (public) says. Based on this, there is service, which identifies you even outside of github, but you still need to do the first step (connect to untrusted server, which is usually bad idea).

Community
  • 1
Jakuje
  • 5,229
  • 16
  • 31
  • for those that say this isn't a privacy issue checkout https://blog.filippo.io/ssh-whoami-filippo-io/ – sektor Aug 06 '16 at 05:46
  • Yes, that was exactly the link I was searching for and failed. I would not call that privacy issue. It is more like connecting to untrusted targets, what reveals your privacy. – Jakuje Aug 06 '16 at 06:21
0

The client always sends the whole publickey. This is defined in RFC-4252.

Most clients send a SSH_MSG_USERAUTH_REQUEST without a signature to the server in the first step. This step is used to know which private key can be used to login, because a private key can be protected by a password. This avoids entering a password for an unused key.

Even if the first step is skiped (wich is allowed by RFC-4252), the publickey is sent and the signature is added to the request.

So in both cases, the publickey is sent to the server. The only difference is, that when querying the server for allowed keys, all known keys are sent to the server as long as the server does not respons with a SSH_MSG_USERAUTH_PK_OK.

At the moment, most clients does not support sending a SSH_MSG_USERAUTH_REQUEST with a signature directly.

And yes, there is an information leak on the server side: CVE-2016-20012

Manfred Kaiser
  • 1,236
  • 2
  • 4
  • 19