1

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.

3
  • See RFC4252 (tools.ietf.org/html/rfc4252), section 7, for how the server authenticates the client via SSH public key authentication. To see how the client authenticates the server based on the server's public key, see RFC5656 (tools.ietf.org/html/rfc5656), section 4.
    – mti2935
    Jun 18, 2020 at 23:55
  • Your understanding of TLS is way out of date. SSLv2 in the 1990s did use RSA-encrypt(servercert.pub,premaster). SSLv3 and TLSv1.0-1.2 allow this but also support several versions of Diffie-Hellman keyexchange, providing 'forward secrecy' or PFS, which became much more popular after Snowden in 2013. TLSv1.3 since about 2018 now supports only DH (and a form of PSK used mostly to replace resumption). In contrast, SSHv2 has mostly used only DH since before 2000. Jun 19, 2020 at 2:17
  • @mti2935: although many have switched to EC host keys not all have, so also 4253 6.6. Jun 19, 2020 at 2:20

1 Answer 1

0

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.

3
  • 1
    Thank you for your reply. When I referenced the TLS steps above, I was referring to them from the standpoint of what format I would have liked to have received the SSH authentication steps in. Aside from that, your reply was very helpful and I am accepting it as the answer. I will dig through ietf.org documentation for my own edification at this point to get a deeper look into the mechanics.
    – OTM
    Jun 19, 2020 at 0:28
  • Sounds good, have fun!
    – hft
    Jun 19, 2020 at 0:50
  • pubkey-encrypt a challenge was only used in SSHv1, broken and obsolete before 2000. Nobody uses it now, or for quite a while. rfc4252 as suggested on the Q is far better. Jun 19, 2020 at 2:18

You must log in to answer this question.

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