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 ?

2
  • Related security.stackexchange.com/a/131762/86652
    – techraf
    Aug 5 '16 at 0: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). Oct 28 '21 at 2:57
5

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

2
  • 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.

8
  • 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
    – Ay0
    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
  • 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 5 '16 at 10:54
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

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.