What exactly happens when you use SSH without generating a key pair?

Question

This seems far too simple and I feel like I might have missed something glaringly obvious, but what is actually happening when you use SSH without generating a key pair?

A variant on this question has been asked here and like the answer, I had always understood that without the key pair, SSH falls back to password authentication.

However, the Wikipedia article only describes two ways of using it. Both seem to involve key pairs, one manually generated and one automatically.

There are several ways to use SSH; one is to use automatically generated public-private key pairs to simply encrypt a network connection, and then use password authentication to log on.

Another is to use a manually generated public-private key pair to perform the authentication, allowing users or programs to log in without having to specify a password

When I create an SSH connection to an unsecured server without a key pair, I'm prompted for my username and password, then I have access to the shell.

Is the password fallback an implementation detail and therefore not in the wiki? Has a keypair been automatically generated, as suggested (if so, how did the public key get to the server)? Or is it going on password alone.

If it's using only the password and username combination, is the data being encrypted at all? If so, how is it being encrypted?

Answer 1

The Wikipedia article is confusing different SSHv2 layers. (It might have been somewhat correct for SSHv1 a decade ago, but it's definitely simplified to the level of nonsense.)

SSHv2 key pairs, both yours and server's, are used for authentication only, and encryption setup is always done using temporarily generated DH key pairs for every connection. The server's SSH key pair only signs encryption setup data (to prove the server's identity), while the client's SSH key pair isn't used for this process at all.

---

In SSHv2, when you connect to the server (after both ends exchange lists of supported algorithms), the first step is key exchange, which somehow generates a symmetric key used to encrypt the entire connection. (The server is also authenticated as a side effect of this process.)

Most of the time D–H or ECDH will be used for this, which means:

1. The client generates a DH keypair (used for this connection only) and sends its DH public key.

2. The server also generates a fresh DH keypair. It also loads its SSH "host key" keypair from disk.

   Then it signs the DH public key with SSH private key, and sends both public keys (as well as the signature) to the client.

3. The client checks the signature and verifies that the server's SSH public key is in known_hosts.

   Then it uses both DH keys (client's private + server's public) to generate the shared encryption key, and throws away its DH keypair.

4. The server also uses both DH keys (server's private + client's public) to generate the same shared encryption key, and also throws away its DH keypair.

5. Both sides enable encryption.

(There are some other key exchange methods but they're rarely used.)

The next step is client authentication. Notice that at this point the connection is already encrypted, even though the client's SSH key wasn't used yet!

1. The client sends a "service request" for client authentication.

2. The server offers some mechanisms – "password", "public-key", possibly others.

3. If you have a SSH key pair, the client selects "public-key", sends your SSH public keys, and uses your SSH private key to sign some random data provided by the server, to prove key ownership.

   If you don't have a SSH key pair, the client selects "password" and sends your password directly – however, still inside the encrypted tunnel.