When explicitly specifying identity file to ssh:

ssh -i ./id_rsa ...

I have these lines in ssh debug trace:

debug1: Offering public key: ./id_rsa
debug3: send_pubkey_test
debug2: we sent a publickey packet, wait for reply

Does it mean ssh-generated id_rsa contains public RSA exponent as well? id_rsa format seems to be rather explicit that it contains private key with its "BEGIN PRIVATE KEY" block, so "offering public key" must mean something other than "sending out the public key to the server".


To clarify, I want to know what exactly is going on behind the "offering public key" line. If the client holds multiple keys, they all will be offered to the server one by one.

  • To add to that problem there is a method for the server to check if we got a good key before the challenge. Because I already had a server refused our key before I even unencrypt it. The error where there because of name not well specified.
    – Gopoi
    Oct 29, 2010 at 3:24

3 Answers 3


in order to connect to an SSH server and authenticate with your public/private keypair you have to first share your public key with the server.

this is done by copying the public key for your private key to the server, and adding it to ~/ssh/authorized_keys either by copy/paste, copying id_rsa.pub to ~/.ssh/authorized_keys on the server or with cat id_rsa.pub >> ~/.ssh/authorized_keys, appending it to the list.

when you connect, the server uses your public key to sign a challenge, and your client uses your private key id_rsa to decrypt the challenge, re-encrypt it with the server's public host key and send it back.

the host verifies that you decrypted the challenge properly, by decrypting your response with its private key, and the client/host establish an encrypted connection, based on the shared data, not on your public/private keys.

at NO POINT in the exchange is your private key, or the host's private key exchanged or revealed to one another. your public key IS stored on the server, but that's why it is a PUBLIC key.

  • Yes, that's all good and well, but this all happens before the server identified the public key to encrypt the challenge with. I have several keys and they are all "offered" to the server one by one. What exactly does that entail? And yes, I realize the private key is not really sent, I should probably remove that line from the question altogether. :P
    – Alex B
    May 18, 2010 at 6:37
  • when you specify ssh -i keyname you are telling your ssh client exactly WHICH key you plan to use to connect to the server. if you have a dozen keys in ~/.ssh/ your client will NOT iterate through each key. it will look for ~/.ssh/id_rsa, ~/.ssh/id_dsa potentially a few other filenames that are coded into the client, or what key is specified for that host in ~/.ssh/config... long story short; your client is not /offering/ any keys to the server.
    – cpbills
    May 18, 2010 at 6:45
  • when you connect, your /client/ decrypts the challenge from the server, and then falls to its list of standardized local private keys to encrypt the challenge, to send the response. IF the challenge-response fails, it /may/ move on to the next hard-coded key-name, re-encrypt with /that/ private key, and try again. again, your keys, public and private are not /shared/ with the server at login authentication.
    – cpbills
    May 18, 2010 at 6:47
  • 1
    oh, i reread your comment; host: encrypts challenge with host key, client: decrypts challenge with host pub key, client: encrypts challenge with private key, host: attempts to decrypt challenge with all listed public keys in ~/.ssh/authorized_keys the host knows what the challenge is, and what it is looking for, so once a public key unlocks it, it knows to use that key.
    – cpbills
    May 18, 2010 at 6:55
  • @cpbills, sorry I forgot to mention I have a few keys from a forwarded agent, hence multiple keys are offered (-vvv log does shows all of them offered, even though I specify the identity file).
    – Alex B
    May 18, 2010 at 7:50

Public/Private Key Cryptography is based on a very simple system:

You have a public key that is capable of doing one-way encryption, and a private key that is capable of decryption. The public key can then be given to everyone in the world, and no one will be able to decrypt your encrypted data, though they WILL be able to encrypt data that you can decrypt with your private key.

So the answer to your question is, "Your public key."

  • Yes, thanks, I know in detail how public key crypto works, but I want to know the specifics of SSH protocol, and key format. I'm interested in knowing whether it stores the public exponent in the private key file, or does it not? For all I know "offering public key" may as well mean signing a nonce with your private key, so the server can find a corresponding public key.
    – Alex B
    May 18, 2010 at 5:45
  • Yes. it does ssh-keygen -y will give you public key of the private key, the reverse doesnt work Jul 23, 2012 at 5:52

I don't think it should actually be sending the public or private key at this time. An encryption should be performed by the client using the private key on plaintext that is already known to the server. The host can decrypt this message using the public key, knowing that the only one that could have encrypted it properly is a client that holds the corresponding private key, thus authenticating the client.

I believe it says Offering public key: ./id_rsa because it uses the private key (stored in ./id_rsa) to perform an encryption on plaintext that is known by the server and then the server will use the public key to decrypt this ciphertext and confirm that it matches the plaintext. The public key file ./id_rsa.pub should never be needed by the client after the initial key generation. This is only used by the server for decryption.

  • I was suspecting something like this happens, but I wanted some specifics (i.e. actual SSH key negotiation protocol). Not sure why you got downvoted.
    – Alex B
    May 18, 2010 at 5:51
  • Sorry my answer was so hand-wavey. I'm not familiar with the specifics of SSH key negotiation, only the general negotiations necessary in public-key authentication. I might have been down-voted for the non-specific answer. May 18, 2010 at 6:08

You must log in to answer this question.

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