SSH publickey leak

Question

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 ?

Answer 1

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).

Answer 2

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.

Answer 3

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