3

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 ?

3

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

  • for those that say this isn't a privacy issue checkout blog.filippo.io/ssh-whoami-filippo-io – sektor Aug 6 '16 at 5: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 6 '16 at 6:21
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.

  • 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 4 '16 at 18:08
  • @sektor one thing is a local log and another thing data sent over the network – yzT Aug 4 '16 at 20:56
  • @HerringboneCat and how does my public key fingerprint ends up in logs ? – sektor Aug 5 '16 at 5:50
  • same question for @Ay0 – sektor Aug 5 '16 at 5:50
  • 2
    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 5 '16 at 10:54

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.