12

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

EDIT:

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.

Alex B
  • 1,714
  • 2
  • 18
  • 30
  • 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 '10 at 03:24

3 Answers3

14

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.

cpbills
  • 2,720
  • 18
  • 12
  • 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 '10 at 06: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 '10 at 06: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 '10 at 06: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 '10 at 06: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 '10 at 07:50
  • i'm not entirely sure how the forward agent works, but i presume the encrypted challenge from the server comes back down the chain of connections, to each of your forwarded key hosts, where the challenge is decrypted, and re-encrypted with the local 'offered' private key. that does change things, but it doesn't change that SSH wasn't well thought out enough to keep your private keys PRIVATE. – cpbills May 18 '10 at 14:14
  • for example, if you have a chain of connections, host1 -> host2 -> host3 -> host4, using the forward agent, host4 is going to encrypt a challenge when connecting, the challenge will be passed to host3, where it will be decrypted, re-encrypted, and resent to host4, if that fails, host4 is aware you are using forwarding, so it will look to the next host, host2, and then finally host1. if all 3 fail, then you get denied. – cpbills May 18 '10 at 14:16
  • does that answer all of your questions? – cpbills May 18 '10 at 21:07
  • Public keys are not used to sign anything. Private keys are. – Fixee Sep 16 '13 at 14:59
  • "when you connect, the server uses your public key to sign a challenge" - completely fails to explain how the server knows what your public key is. – aaa90210 Apr 02 '18 at 22:29
1

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

Satanicpuppy
  • 5,946
  • 1
  • 17
  • 18
  • 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 '10 at 05:45
  • Yes. it does ssh-keygen -y will give you public key of the private key, the reverse doesnt work – Mâtt Frëëman Jul 23 '12 at 05:52
1

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.

Trey Hunner
  • 1,282
  • 10
  • 9
  • 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 '10 at 05: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. – Trey Hunner May 18 '10 at 06:08