1

I am reading in a Linux Admin book, from a well known publisher:

When a client initiates the SSH handshake, the server asks for the client's public key and verifies it against its allowed public keys. If there's a match, the SSH handshake succeeds, the server shares its public key with the client, and the SSH session is established. Further client-server communication follows standard encryption/decryption workflows. The client encrypts the data with its private key, while the server decrypts the data with the client's public key. When responding to the client, the server encrypts the data with its own private key, and the client decrypts the data with the server's public key.

Is this simply wrong, or am I missing something? I states that session communication is implemented with asymmetric encryption, using two keypairs, one for the direction client->server, and an other one to server->client.

All other Internet references state, that server and client establish a symmetric session key then using symmetric encryption during the session...

gronostaj
  • 58,482
g.pickardou
  • 609

1 Answers1

4

The book is wrong on practically every thing that was quoted.

(How would the described procedure work if the client used password authentication and didn't have its own keypair?)

The book might have been influenced by the (now completely obsolete) SSHv1 protocol, in which the server did use its asymmetric RSA keypair to encrypt/decrypt some things (it was always RSA in SSHv1), but even then it was only for authentication and not for bulk data encryption (which still used symmetric algorithms such as 3DES).

But this is no longer done in SSHv2, which (just like TLS) has fully moved to DH-based keying and signature-based authentication.

When a client initiates the SSH handshake, the server asks for the client's public key and verifies it against its allowed public keys. If there's a match, the SSH handshake succeeds, the server shares its public key with the client, and the SSH session is established.

Thus is backwards and incomplete. Server authentication happens before client auth, for various reasons, but among them the fact that clients do not necessarily use keypairs to authenticate – they might use ordinary passwords, for example, so you would want to authenticate the server before sending it your password.

Also, neither of those keys is used for encryption at all. Both keys are only used to sign things; the actual encryption keys are generated new for each session, during the "key exchange" procedure that the book neglected to mention (usually a form of DH/ECDH).

The DH "key exchange" is the first thing to happen and generates symmetric keys (the server provides its public key during this phase), then the symmetric encryption is established, and then the client authenticates itself to the server – possibly with a keypair, but possibly not.

Further client-server communication follows standard encryption/decryption workflows. The client encrypts the data with its private key, while the server decrypts the data with the client's public key. When responding to the client, the server encrypts the data with its own private key, and the client decrypts the data with the server's public key.

This is wrong. Although SSH does use distinct keys in both directions (client-to-server and server-to-client), they both are still used with a symmetric cipher such as AES, so there is no "public key" involved in this – the client uses the same symmetric key to encrypt data as the server uses to decrypt.

Practically all protocols use only symmetric encryption for bulk data transfer, SSH and TLS both work this way.

You can take a look at ssh -v or plink -v somehost to see what cipher is being negotiated; it will show you AES or another similar symmetric cipher being in use in both directions, and such a cipher does not have public keys.

grawity
  • 501,077