![]() ![]() 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. |