What are the logical steps taken to perform ssh key authentication?

Question

I understand the logical steps of asymmetric key cryptography as it relates to TLS, however, I've started using Git and in a bid to avoid having to use a password for authentication, I've set up ssh keys for passwordless authentication. I understand that these ssh keys are complements of each other but I do not understand how the actual authentication is taking place. I've copied the public key to Git and stored the private key locally. As such, I am able to do what I set out to do (passwordless authentication) but I do not know the underlying steps as to why the authentication is successful. I've tried searching the web but every answer I've found thus far has been too high level in that they did not specify the steps. For example, were I looking for the TLS steps, I'd expect something along the lines of: Check cert of https page (server) - Grab public key and encrypt secret with it - Securely send secret to server which should be the only entity with the corresponding private key to decrypt - Server and client now switch over to encrypted communications using the, now, shared secret.

Answer 1

For example, were I looking for the TLS steps, I'd expect something along the lines of: Check cert of https page (server) - Grab public key and encrypt secret with it - Securely send secret to server which should be the only entity with the corresponding private key to decrypt - Server and client now switch over to encrypted communications using the, now, shared secret.

You're on the right track, but kind of in reverse.

For HTTPS the private key is on the server and you receive the public key on your client machine via the certificate.

When you use ssh keys, the private key is on the client (your computer) and the public key is on the server.

The protocol can proceed in different ways. The explanation in this paragraph is a high-level description that is appropriate for older versions of SSH. The server can use your public key to encrypt a challenge that is sent to you. Since you are the only one with the private key (hopefully), you are the only one who can decrypt the challenge. Thus, by successfully decrypting the challenge you have authenticated yourself without having to enter a password.

For more modern versions of SSH the protocol proceeds in somewhat the "opposite" direction. The protocol is described in RFC 4252. At a high level, the difference is that rather than accept a challenge from the server that is encrypted with the public key (on the server), the client uses the private key (which only the client has) to sign a message. The message the client signs contains: 1) session ID string; 2) message code byte; 3) user name; 4) service name; 5) authentication method; 6) boolean TRUE; 7) algorithm name string; 8) public key ID string. The server receives the signature and verifies it with the user's public key. This establishes the user's identity and so authenticates the user.

For more of the gory details, you can, for example, use Wireshark to observe your own traffic as you connect to a server using your ssh key. This will give you a better understanding of the detailed messages sent in practice.