( Note that there are a few technical details, such as hashing the values together with the session key, but those are not important for understanding the overall flow.) Local Port Forwarding If the values match, the client’s identity is verified and is authenticated now. The server will simply encrypt a random value using the client’s public key (taken from ~/.ssh/authorized_keys) and send it over, the client verifies itself by being able to decrypt the message (because it owns the private key) and sends it back. Lastly, the client is authorized against the server using it’s RSA keypair. Instead, SSH uses symmetric encryption (e.g. You might be thinking why not use the already existing RSA keys (public/private keypair) of the client/server to encrypt the traffic? The answer is simple: asymmetric encryption is slow. If you always say yes without verifying the host key, you’re vulnerable to a man-in-the-middle-attack.Īfter the server authenticity is confirmed, and the client and the server use Diffie-Hellman to negotiate a session key, which is then used to encrypt all of the traffic between them. This is where SSH asks you to verify the host fingerprint, which is the fingerprint of its public key, and if you say yes, it means you’re validating the server truly is who they say they are (and not an attacker), and they key exchange can continue. That’s where one more step comes in and the server uses its private key to sign a hash of some of the Diffie-Hellman parameters ( check out section 8 of the RFC on what exactly gets signed), and the client then verifies the hosts signature using its public key. The issue with Diffiel-Hellman is that while you can exchange a secret, you don’t really know who you’re exchanging it with, and is vulnerable to the main-in-the-middle attack (someone could pretend to be the server and exchange the key with you instead). 16 m o d 5 = 1 16 \mod 5 = 1 1 6 m o d 5 = 1) you can understand Diffie-Hellman, as it’s only a few steps that could be done even on paper. If you’ve ever configured nginx and run into something called dhparam or ssl_dhparam, the dh in there stands for the Diffie-Hellman algorithm, which is an amazingly simple algorithm to exchange a secret key over an insecure communication channel, without any prior knowledge. There are three types of encryption used at different stages: Diffie-Hellman, RSA, and AES (or other algorithms depending on configuration). You don’t need to understand it to use SSH tunnels in practice. If you just want to get to the practical bits, feel free to skip this section and jump straight to Local Port Forwarding. Backgroundīut first a tiny bit of background on how SSH works and why it’s secure. We can use this channel to run commands on the remote server, expose a local port in a remote computer, expose a remote port on the local computer, or route traffic via a SOCKS proxy (more on this later). In its essence, port forwarding allows SSH to securely create an encrypted communication channel (a tunnel) between two computers on the network. In this post I hope to explain it in such a way that you’ll have no confusion about when to use SHH’s local, remote, or even dynamic port forwarding. SSH tunneling is an extremely useful feature of SSH that is very often googled, but less often understood enough to use without a reference. Dark theme SSH Tunnel - Local, Remote and Dynamic Port Forwarding
0 Comments
Leave a Reply. |
AuthorWrite something about yourself. No need to be fancy, just an overview. ArchivesCategories |