mjhjmtu

I wanted to understand how SSH exactly works and I stumbled upon this article: https://www.digitalocean.com/community/tutorials/understanding-the-ssh-encryption-and-connection-process

The author wrote that an SSH session is established in two stages:

1. Client and server establish encryption to secure the communication


2. Client authentication

During the first stage both parties take part in generating a shared session key that would be used to encrypt messages. It is used during the authentication stage:

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.

My question is: Why go through the process of generating a shared session key if the authentication process fails? The messages are secured by public key encryption and private key decryption anyway, so is another layer of security really neccessary, or is it just a security measure just to be sure it's safe?

It would make more sense to me if the client had been first authenticated and after that a shared session key was generated.

It is the asymmetric (public/private) operations that are expensive (the fewer you do, the better), symmetric crypto is cheap. SSH first establishes a full symmetric encryption between the client and server and then it starts discussing authentication methods.

Multiple keys can be offered and rejected as part of the negotiation (your suggestion would make this more expensive). Then other authentication methods may be tried. You want to let any eavesdroppers know as little as possible about this phase, so it makes sense to have full end-to-end encryption already in place for it.

Bonus argument: your suggestion makes failed attempts cheaper, we don't actually want that, they should be at least as expensive as successful ones.

No. This is the primary layer of encryption. There's no other layer.

The messages are secured by public key encryption and private key decryption anyway

They aren't. Public-key encryption/decryption is never used to protect all traffic, for various reasons (e.g. considerably worse performance of asymmetric algorithms versus symmetric encryption, or lack of forward secrecy, or simply the protocol using algorithms suitable for signing but not encryption).

Instead, both SSH and TLS/SSL use a "hybrid" model where the public/private keypairs are only used to negotiate a session key (or more commonly, just to secure the negotiation) and not used at all afterwards.

Besides, how would the server encrypt data if the client didn't have a keypair at all? Remember that SSH has a variety of client (user) authentication methods – such as simple password, which needs to be encrypted somehow. (And for comparison, in general TLS/SSL usage the client isn't authenticated at all.) Ideally, the authentication process wouldn't reveal to outsiders who is currently authenticating.

Having one encryption layer just for the authentication details, and switching to another for the rest of the session, would be possible but unnecessarily complex – because after all it wouldn't even avoid the 'issue' you mention (of having to do a key exchange before authentication).