Ssh – How to configure ssh tunneling past a firewall

puttysshssh-tunneling

I have a NAS running Linux behind a firewall at home. I want to access it remotely using a few services such as a Transmission GUI (port 9091) and webmin (port 10000), but through an SSH tunnel on port 22.

For simplicity, I wanted to leave as many net-facing ports closed and only opened up port 22 to the NAS.

I tried configuring tunnelling in PuTTY (local port 10000, remote.ip.address:10000), but I believe I'm still hitting a firewall rule after a successful SSH login. Is this the correct use of SSH tunnelling?

Best Answer

You don't need to open tunneled ports on the firewall. You are fine opening only the SSH port.

You may be getting caught by one of a few problems.

The local ports may already be in use. Try using netstat to see if the port is occupied.
When you connect to the tunneled port you will find it a localhost (127.0.0.1) not the remote address. Some software may not like this.
Tunneling can be turned off in the server. In that case your tunnels won't work.
If you are tunneling to another host (remote.ip.address is not on the host you are tunneling through), you may be blocked by the SSH server's AllowTcpForwarding setting.
If you are tunneling to a port on the same host (remote.ip.address is 127.0.0.1, or some other IP on the server) you are tunneling to the destination software may not like it. For example, some VNC servers default to preventing same host connections to prevent looping conditions.

Try connecting with the debug flag enabled.

Related Solutions

SSH – How to Open a Port Early in Boot Process to Unlock LUKS

I got this same problem a few weeks ago (Debian Wheezy 7.6) and after some days of troubleshooting I found out that there was a config file missing which was preventing to the cryptroot script on init-top to run correctly, hence it was not stopping to ask the password via ssh, killing the dropbear at the end of the sequence (init-bottom).

The config file is called cryptroot and should be under /etc/initramfs-tools/conf.d/ If I am not mistaken that config file should have been created automatically during install (I have read just one tutorial talking about that config file) but somehow it did not (tested in a physical server and in a VM, same OS and versions)

It took me a couple of tries to configure it properly, since I could not find the proper syntax at that time. My cryptroot config file is as follows:

target=crypt-root,source=/dev/vg0/root,lvm=root

Once created the config file just update the initramfs and try again:

update-initramfs -u

Ssh – Are there additional ways to protect SSH connections besides firewall and RSA Keys

Your existing configuration seems very secure. However, there are additional things you can use to restrict access.

Port knocking can be used to keep the port closes most of the time. This is implemented using iptables. There are daemons which can be used, or the rules can be implemented entirely in iptables as described in the Shorewall documentation.

If tcp wrappers is enabled. A couple of ruless like the following in /etc/hosts.allow will notify you whenever a remote connection is made to the deamon. The first rule lets local connections work silently, adjust the ip address range as appropriate. The second rule prevents access from addresses which reverse to a number of country TLD, and emails a message for each successful connection. It could be noisy, if you don't use Port Knocking.

sshd :          10.0.0.0/8 192.168.0.0/24 

sshd :          ALL \
            EXCEPT .ar .au .br .by .cl .co .cz .do .eg .gt \
                .id .il .in .jp .ma .mx .nl .pe .pk .pl .pt \
                .ro .rs .ru .sa .sg .tr .tw .ua .vn .za \
                .ae .at .bg .gh .hr .hu .ke .kz .lt .md \
                .my .no .sk .uy .ve : \
            spawn (/bin/echo "SSH connection to %N from %n[%a] allowed" | \
                /usr/bin/mailx -s "SSH Allowed" you@example.com)

fail2ban rules can be used to temporarily blacklist hosts which are trying to brute force your server. I've seen occasional attempts when I have had ssh exposed to the Internet.

Best Answer

Related Solutions

SSH – How to Open a Port Early in Boot Process to Unlock LUKS

Ssh – Are there additional ways to protect SSH connections besides firewall and RSA Keys

Related Question