Remote access to a Linux machine behind a firewall

Question

I'm going to be deploying an Linux machine as a sort of public terminal at a remote location. I'd like to be able to access it remotely via SSH for maintenance but I don't want to keep a port open on the remote firewall for the rare occasions I need to access this machine. I've though about a simple script to create a reverse SSH tunnel to a machine on the outside, but I'd rather not have to have a user have to do anything when I need to access it. Any ideas?

Update: I've decided to go with my original plan of a script to create a reverse ssh tunnel. While other suggested solutions, such as port knocking would be more along the lines of what I really want to do, in this case, I don't have any access to configure the router other than walking a user through a config. shudder

Solution 1

It has less to do with being concerned with a port being open and more to do with not wanting to walk a user though the process of opening up a port. I don't have any access to this router at all unfortunately.

If changing the router is completely out of the question, you may need to look at a P2P or VPN solution like Hamachi. If you setup the system to automatically establish the VPN connection at startup, then you should be able to connect in whenever you need to. Hamachi does all the firewall negotiation for you. The one drawback is you have to rely on the Hamachi servers being up and functional when you need to connect.

If you have a server that is always up, you could setup autossh so that the remote system always keeps a tunnel open and connected to your server. The one drawback is the remote system is compromised they attacker will get the keys that where used to establish the ssh session. It would be very important to keep your system that accept the ssh connection really locked down.

---

Below is my original answer, I had assumed that updating the router was an option.

One solution you might want to investigate if you firewall supports it, is port knocking. With some firewalls it should be possible to send out a special set of packets that the firewall notices and then temporarily opens hole through the firewall.

There are many implementations some better then others. Some use strong cryptography to make it nearly impossible for a person without the right keys to send the correct knock.

Solution 2

I wouldn't be that worried about leaving port 22 accessible to the internet, but I would take some steps to secure it.

Firstly, disable keyboard interactive authentication and move to ssh keys.

Secondly, install something like fail2ban on your remote server to blackball IP addresses that repeatably probe your machine. Because you have setup ssh keys, there should be no authentication failures for authorized users.

Alternatively if you are able, take WerkkreWs advice and configure the firewall in front of the machine to terminate a vpn connection, then only allow the ssh daemon on the remote server to accept connections coming across that vpn.

Alternatively if your firewall can't terminate the vpn connection, you can probably forward the GRE or IPSEC packets to your linux machine, and terminate it there.

Solution 3

It sounds like you are looking for knockd

You can install that on the linux server itself, with iptables so that it's kind of like a 2nd level firewall. Even with port 22 open on the frontend firewall, it wouldn't be open on the server, so portscans wouldn't see any open ports. Then when you send the "secret knock", all of a sudden you have an open path to port 22.

Does that make sense?

Solution 4

To sum up all answers:

use ssh, but make it more obscure and secure.

For security:

• Make sure root login is not allowed (PermitRootLogin no).
• Limit users, which can log in by config option AllowUsers or AllowGroups.
• Ensure it uses only 2 version ssh protocol (Protocol 2).
• It is advisable to use only authentication keys, but password is more convenient, when there can be a need to connect to server from holiday where you have no access to authentication keys.

For obscurity:

• Change ssh port to some random high port you would remember, like 20486. This would get rid of most automatic bruteforcers, but it would not hide it from all port scan on server.
• Hide ability to connect to port. One way is port knocking mentioned in other answers, but you need special software, which can not be accessible everywhere. Another simple option is to use iptables firewall with recent module to create rule, which would allow to connect only on second or third try. So you know you have to try several times to connect successfully, but simple all port scan would not reveal ssh port. Rules would be similar to those:

iptables -A INPUT -m tcp -p tcp --dport 20486 -m state --state NEW -m recent --set
iptables -A INPUT -m tcp -p tcp --dport 20486 -m state --state NEW  -m recent --rcheck --seconds 60 --hitcount 2 -j ACCEPT
iptables -A INPUT -m tcp -p tcp --dport 20486 -j DROP

Solution 5

Look into port-knocking to open up your SSH tunnel.

Also, run denyhosts to lock out people after too many bad requests.

Both packages are available in the standard Ubuntu, Fedora, and RHEL repositories.

View more solutions

Comments

[WerkkreW]

Agreed. Unless you have a way to VPN in, the only real solution is to basically open a port. If you are nervous about it you could always use a non-standard port.

[baudtack]

That sounds like a great idea! Unfortunately the firewall in question is just a simple consumer grade Linksys or some equivalent.

[Zoredache]

If you can install dd-wrt you can use knockd (dd-wrt.com/wiki/index.php/Knockd)

[baudtack]

@Zoredache True, but this is at a remote location. I have no access to this router and I'd shudder at the thought of trying to walk a user through a dd-wrt install.

[baudtack]

It has less to do with being concerned with a port being open and more to do with not wanting to walk a user though the process of opening up a port. I don't have any access to this router at all unfortunately.

[baudtack]

I do agree that this is probably the Right Way to set this up, providing that I had physical access to the router to install dd-wrt.

[baudtack]

Unless I am mistaken, I'd have to forward all the knock ports as well right? Wouldn't that be obvious when someone scanned the router? They wouldn't know the order but dropping the possible combinations to 6, if I remember my how to do permutations correctly, gives them a huge head start. Or am I thinking about this wrong?

[Zoredache]

While the ports used for knocking would need to be forwarded, the host running knockd doesn't actually need to reply to the source of the knocking in any way.

[Dave Cheney]

I understand and sympathize with your pain.

[bmb]

Hamachi, since being acquired by LogMeIn, has shown abysmal consideration to Linux users. I find the product unreliable when Linux machines are part of my hamachi network.

[hayalci]

The first step in this solution would be to configure sshd to run on a non standard port. There are lots of bots knocking on port 22 out there. Choose a port that does not appear on /etc/services and "nmap HOST" does not find it.

[phirschybar]

correct - the ports open on the first firewall will not be open on the 2nd, so to the scanner they all appear closed. No way to distinguish knocking ports from non-knocking.

[David Z]

+1 nice summary, and interesting idea about the multiple-attempts trick.