When using SSH, my private key is stored on my computer safely and my public key is given to the other party I wish to communicate with.

I understand that the two keys are mathematically related, and so what is encrypted with the public key can be decrypted (only) with my private key.

When I started an SSH session now, communicating with a Linux server, I received a message "Authenticating with public key "imported-openssh-key" "

What exactly is happening here to authenticate it? My guess is the server simply writes a known message to me, encrypts it with my public key. I then decrypt it on my side with my private key and send the message back to the server where it compares the message.

Is this how it works or is there something more mathematically complicated behind it?

  • Dupe security.stackexchange.com/questions/23227/… (although the bear is less verbose than usual). For v2, your client program signs (with privatekey) session-dependent data and the server verifies (with publickey) this signature is valid and (for OpenSSH) matches ~/.ssh/authorized_keys (or a configured other location). Dec 15, 2018 at 20:36

2 Answers 2


What about this description?

  1. The client begins by sending an ID for the key pair it would like to authenticate with to the server.
  2. The server check's the authorized_keys file of the account that the client is attempting to log into for the key ID.
  3. If a public key with matching ID is found in the file, the server generates a random number and uses the public key to encrypt the number.
  4. The server sends the client this encrypted message.
  5. If the client actually has the associated private key, it will be able to decrypt the message using that key, revealing the original number.
  6. The client combines the decrypted number with the shared session key that is being used to encrypt the communication, and calculates the MD5 hash of this value.
  7. The client then sends this MD5 hash back to the server as an answer to the encrypted number message.
  8. The server uses the same shared session key and the original number that it sent to the client to calculate the MD5 value on its own. It compares its own calculation to the one that the client sent back. If these two values match, it proves that the client was in possession of the private key and the client is authenticated.
  • That description is only for SSHv1, which was broken during the Clinton presidency and was (in nearly all cases) replaced by v2 during Bush-2. Dec 15, 2018 at 20:34

SSH2 does public key authentication based on RFC4252.

According to RFC4252, section 7, the client uses its private key to create a signature over the following data:

  string    session identifier
  string    user name
  string    service name
  string    "publickey"
  boolean   TRUE
  string    public key algorithm name
  string    public key to be used for authentication

The session identifier is derived from the previously setup SSH transport layer between the client and the server, typically setup using ephemeral keys (see RFC5656).

RFC4252, section 7 goes on to state:

When the server receives this message, it MUST check whether the
supplied key is acceptable for authentication, and if so, it MUST
check whether the signature is correct.

In practical terms, the first part of this (i.e. the server checking whether the supplied key is acceptable for authentication) means that the server checks if the public key is contained in the authorized_keys file.

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .