1

It is not clear to me why the SSH key authentication needs the public key saved on server. Usually the steps involved are:

  • Generate a key pair on client
  • The public key is saved on server and the private key is used by client to perform authentication

I've never seen a solution like:

  • Generate a key pair on server
  • Public key saved on client

I think the last solution is possible but never used due to impossibility to guarantee access to a restricted number of user: the public key can be used by anyone during the authentication phase. Is this the case or other motivations are present?

Improve this question
1
  • 1
    You certainly have seen your second method. If using OpenSSH client or compatible, look in ~/.ssh/known_hosts -- those are the server publickeys, saved and used for checking. If PuTTY/Win or compatible including WinSCP, check your registry under HKCU\Software\SimonTatham\PuTTY\SshHostKeys (added) Note this authenticates the server not the client.
    – dave_thompson_085
    Jul 8, 2018 at 13:47

2 Answers 2

Reset to default
6

There's multiple keys and encryption schemes used in SSH:

  1. Server keys, to authenticate the server to the user. The server has the private key, and hands out the public key to anyone asking.
  2. Client keys, to authenticate the client to the server. The client has the private key, the server the public.

Purpose of #1 is to authenticate the server to the user. The user can use the public key to verify that the server has knowledge of the private key. This ensures that there's no man in the middle-attack, as he would be unable to produce the same keys.

Purpose of #2 is to authenticate the user to the server. The server can use the public key to verify that the user has knowledge of the private key.

Authentication may be by the server using the public key of the client to encrypt a random number. If the client has the corresponding private key, it can decrypt the random number, and tell the server the value. This proves that the client has the corresponding private key, and thus authenticates the user - without revealing any information apart from that it has the private key.

The client can do the same with the server key; encrypt a random number, and transmit to the server and ask the server to decrypt it.

For encryption of data in transit, neither is used. A symmetric cipher, with ephemeral keys is used for encryption of data passing over the wire. The key for this is worked out using a key exchange protocol.

This is obviously a very brief overview, and it's simplified. More information can be found in this short and not-to-technical text about ssh authentication.

Improve this answer
4
  • Thanks for the explanation and the interesting link. If I understood well, the steps involved are: 1. Server authentication, 2. Symmetric session key generation, 3. Client authentication. Last question: is the server key used in point 1. the "hosts key" generated with dpkg-reconfigure openssh-server?
    – Alvin
    Jul 8, 2018 at 13:32
  • The server key is commonly called the host key yes. The order of authentication is roughly as you describe. If you run ssh -v user@host you'll see the debug messages, indicating what happens. To see more, add an extra v, e.g. ssh -vv or ssh -vvv.
    – vidarlo
    Jul 8, 2018 at 13:34
  • 1
    SSHv2 never authenticates by publickey-encrypting a nonce, only by signing and verifying. See rfc4252 section 7 and rfc4253 section 8. Of the four publickey types currently supported, only RSA is even capable of encrypting, DSA ECDSA and Ed25519 could not.
    – dave_thompson_085
    Jul 8, 2018 at 13:45
  • @dave_thompson_085 very true, I obviously did not check this thoroughly enough. Thank you for the correction :)
    – vidarlo
    Jul 8, 2018 at 13:47
-2

I think these videos explain very well:

Public Key Cryptography - Computerphile

If you can't/don't want to watch the video, here is a quick summary:

A key pair consists of two keys that can encrypt something but the encrypted product can only be decrypted by its pair.

The server has public and private keys and the client has public and private keys that the client got from the server.

Server's public key is broadcasted to everyone.

Client's public key is stored on the server as a known host, but can also be broadcast to anyone. It is just important that the server definitely knows who that public key belongs to.

When the client wants to contact the server, they first encrypt the stream with their private key and then the server's public key.

The server then can verify with the client's public key that it indeed was the client that requested access because only the client has their private key, and nobody knows what the content of the data exchange because the only one that can decrypt the rest of it is the server.

So to answer your concern, no, that public key is not saved on the client, but rather broadcasted to everyone always.

Improve this answer
2
  • 1
    That video may be a decent explanation for the layperson, but it has several inaccuracies (though he does admit it's oversimplified). Public and private keys are not interchangeable as it implies, and private keys can't be used to encrypt, only sign.
    – AndrolGenhald
    Jul 8, 2018 at 18:21
  • 2
    The server's public key is saved on the client so that the client can tell if it changes for a future connection and warn the user (trust on first use).
    – AndrolGenhald
    Jul 8, 2018 at 18:22

You must log in to answer this question.

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