I have a machine behind a big firewall, and I want to be able to access it via ssh without poking a hole through the firewall.

So, I reverse SSH from the machine behind the firewall into my private server. Then, I can simply ssh into my private server and tunnel into the machine I'm trying to access.

There is a small security problem with this though. To access the machine behind the firewall, I only need to authenticate to my private server, when I want to also authenticate to the machine behind the firewall (private key or password).

Is there a way to do this? I don't consider my private server to be extremely secure, so I'd like to keep the sshd layer of protection from the machine behind the firewall.

(Actually, do you even need to authenticate into the private server? I think maybe not, so this is a bigger hole than I thought)


I think in trying to avoid not poking a 'hole' in your firewall you are making the solution more obscure and less secure as your not 'extremely secure' server becomes the keys to the kingdom.

Personally I would feel much safer with ssh forwarded through the firewall to the server you ultimately want to access. Ideally this server should only allow private key authentication, not allow root logins and perhaps have ssh connections rate limited in iptables.

Remember shh is supposed to be secure, and used correctly I can't think of any reason you'd need a 'big firewall'.


If the internal server is too sensitive to open directly to the internet, then creating a permanently accessible connection to it via an insecure external device decreases your security posture.

If this server needs to be accessible externally, the ideal scenario would be to use a VPN into the the site where it resides, using industry standard two-factor authentication methods, and limiting access to specific IP addresses.

The method you have chosen effectively extends your security perimeter out to wherever the "private server" resides, and the security architecture used to protect it.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.