This is similar (though somewhat better in some respect) to the previous one, but it's the firewall that does all the work (not your local client). Now it's again possible to work around this problem (see eg HostKeyAlias), but the point is that if you use this method the burden can only increase. RSA host key for :1111 has changed and you have requested strict checking. Offending key in /root/.ssh/known_hosts:2 Please contact your system administrator.Īdd correct host key in /root/.ssh/known_hosts to get rid of this message. It is also possible that the RSA host key has just been changed. Someone could be eavesdropping on you right now (man-in-the-middle attack)! Then you connect to port 1111 on localhost and dang: client:~$ ssh -L1111:172.16.0.17:22 ssh -p 1111 WARNING: REMOTE HOST IDENTIFICATION HAS CHANGED! IS POSSIBLE THAT SOMEONE IS DOING SOMETHING NASTY! But some day you need to connect to an entirely different firewall, to access the network behind it, and you light-heartedly reuse port 1111 for forwarding to some internal box. Also think when using scp, you have to remember which port corresponds to which host and use the -P option to specify it.īut there is another problem with this setup: ok, you're clever and remember all the ports you've forwarded. Sure, you could use a clever mapping between forwarded ports and IP addresses or names of the internal hosts, but when the number of servers you need to log into grows, that still becomes difficult to track. However, what if you need access to many internal hosts? You need to open an equivalent number of sessions to the firewall, each one forwarding a different local port, and you have then to remember which is which: client:~$ ssh -L1111:192.168.0.1:22 ssh -L1112:192.168.0.27:22 ssh -L1113:192.168.0.4:22 Which port was 192.168.0.4 again? 1112 or 1113? The first thing one might come up with is something like this: client:~$ ssh -L1111:192.168.0.1:22 # open another shell now.Ĭlient:~$ ssh -p 1111 login: Thu Jan 5 22:10: from 10.8.0.210 on pts/12Īnd you're in. If that is not the case, all the methods described here will work just as fine, but you'll get prompted for passwords, of course. In other words, your public key on client also appears in the ~/.ssh/authorized_keys file on the target hosts (and public key authentication is enabled, of course).

I'm going to assume you have password-less SSH login to the firewall (for example using public key authentication), and possibly to the internal host as well. The local box from where you connect is called client. In this scenario, the internal hosts are on network 192.168.0.0/24, and for simplicity names relate to addresses, so 192.168.0.1 is internal1, 192.168.0.2 is internal2, etc. Let's see a couple of ways to achieve this (the best one at the end!).

It would be nice if there was some mean to say 'ssh or similar and it 'just worked'. This works of course, but it's a bit inconvenient. You have SSH access to the firewall, and from the firewall you can then ssh into some internal host.

You have one or many hosts you want to access that are behind some kind of firewall (perhaps even behind NAT, and they're using private IP addresses).

Netcat ssh proxy