How can SSH ensure a cyphered communication in both directions?

40 Views Asked by At

There is something I do not get with public/private key authentification.

Let's take the example of using SSH communication between my PC and GitLab. I generate a pair of 2 keys, one private, one public. I can share the public one and give it to GitLab, and I keep the private one secret. The public is used to cypher a message, the private is used to decypher it.

So people (and in particular GitLab) can send me a cyphered message with the public key, and I can decypher it with my private key. That's cool, there is a one-directional communication, from GitLab to my computer. I am happy that GitLab can send me cyphered messages.

But on the other hand, I cannot send cyphered messages to people (and in particular GitLab) because they do not have a private key to decypher it. In such a case, how can SSH send cyphered messages from my PC to GitLab ? How can GitLab be sure that it is indeed me that is sending the message?

I have read something about "The private key is used to sign the message" but I do not understand it. Aren't private keys used only to decypher?

Thanks.

1

There are 1 best solutions below

0
nneonneo On

Actually, you've missed a few steps in SSH:

  • Hosts have private/public keys too - you're prompted to accept the key the first time you connect to a new host.
  • Host and user keys are used for authentication, not for encryption. In authentication, a private key is used to sign some data to prove ownership of the corresponding public key.
    • When you connect to a host, the host presents its public key, and you decide whether to trust that key for that host. The host will sign some data using its private key to prove it owns that public key.
    • When you go to authenticate as a particular user, you will sign some data using your private key, and the server will check that the corresponding public key is authorized (e.g. in authorized_keys).
  • Session keys for actual encryption are negotiated using a separate protocol, usually one based on Diffie-Hellman key exchange. Diffie-Hellman is usually done by computing ephemeral public/private keys, and requires that the endpoints have authenticated each other to avoid a man-in-the-middle attack.