Securing SSH and tunneling

by Uwe Meding


Today in the Linux (more generally *nix world), secure shell (ssh) access is the most pervasive means of connecting the other systems in the network for command line interactions. Regardless of whether you are accessing systems inside your network or a cloud based system somewhere else in the world. SSH uses two mechanisms to authenticate who has access to a system. By default, password based authentication and public/private key authentication is enabled on the system. The password based authentication offers very little barrier, and gets you going in no time. Just create an account on the remote system, and a

$ ssh username@remotesystem 

gets you onto the remote system in no time.

Typically, this works well in an internal setup or development environment where all the systems are behind a firewall or part of a virtual private network (VPN). In a public setting where communications are established over open and insecure networks you need more save guards.

Securing SSH
While SSH is using encryption to ensure that the stream of data is secure, it is still very vulnerable to brute force attacks. You could simply run a script and try different passwords to gain access to the system. The following simple steps will go a long way to help secure a system that is exposed on the public:

1. disable root access
2. move the SSH port to a different port
3. disable password authentication

Disable root access
This forces any access requests to restricted user accounts. So even if access has been compromised to one account, privileged commands are still not permitted, because you will need the root password to proceed. It also makes sense to disable simple sudo access for regular users
Depending on you system, this is managed in the “sudoers list” or the “wheel” group. Disabling root access in sshd does not change the appearance of the ssh prompts on the outside. Everything looks like a legitimate login attempt, they will fail everytime even if the correct password is provided. In the /etc/ssh/sshd_config add the following line:

PermitRootLogin no

Then restart the sshd server.

Move SSH access to a different port
This falls into the category of “security by obscurity” methods. It does not make your system or access any more secure, but it does seem to keep any more casual hacking attempt at bay. I have seen brute-force attack attempts fall to pretty much zero with this. Obviously, if the new port is discovered this offers absolutely no more protection. The port(s) that SSH uses are defined in the /etc/ssh/sshd_config file.  Usually toward the top of the file you find the “Port” command, change this to a different number, such as:

Port 2020

This will change the access port from 22 (default) to 2020.
Keep in mind, that if this is a system that is exposed to the “internets“, you will most likely have a firewall that manages access to the various systems or services you have. Any port change in the sshd configuration will have to be accommodated in the firewall settings.

Disable password authentication
The ssh server will not prompt you for any password. It will expect the public key of the account you are trying to login to. This is probably the single most important setting to secure the server. The downside of doing this is that you have to find a way to manage the public keys. In the /etc/ssh/sshd_config file add the following lines:

ChallengeResponseAuthentication no
AllowUsers tcs

The first line disables the username/password challenge, the second makes sure that only users that exist will be allowed to access the system.

Pulling it all together


1. Pick an encryption scheme; this will be either RSA or DSA. Either one is great, just be consistent. Edit the /etc/ssh/sshd_config file and verify your setting – RSAAuthentication yes means that the server uses RSA encryption.
2. Create public/private key pair. You can actually have several key pairs that can be used for different purposes.
3. Remember, the private key always stays with you, that is the system you are initiating a connection from.

And now for the fun stuff…

SSH without password

Depending on your sshd encryption settings and preferences, use one of the following set of instructions. Both RSA and DSA methods are very similar, the only difference are subtle naming differences.

That’s it! you’re ready to ssh from ooga to booga without having to enter a password.

SSH local tunnel
This lets you access services on a firewalled remote system. In the most typical setup is to allow secure shell access to a system behind a firewall. For example, if you want to use an web server that you don’t not have access to from the outside (for example, some intranet wiki)

ooga% ssh -f user@booga-server.com -L 2000:booga-server.com:80 -N

Let’s dissect the command line options:
The -f tells ssh to go into the background just before it executes the command. This is followed by the username and server you are logging into. The -L 2000:booga-server.com:80 is in the form of -L local-port:host:remote-port. Finally the -N instructs SSH to not execute a command on the remote system.
Essentially, this forwards the local port 2000 to port 80 on booga-server.com (encrypted by the way). Then simply point your web browser and navigate to http://localhost:2000 and you will see the internal web pages.

SSH remote tunnel
The SSH remote tunnel is very similar to the local tunnel, except that the remote system initiates the tunnel. This “reverse” tunneling is very useful on machines that sit behind firewalls. Use the following command on the remote server:

booga% ssh user@ooga-server.com -R 50000:booga-server.com:22 -N

Let’s dissect the command line options:
The -R 50000:booga-server.com:22 is in the form of -R remote-port:host:local-port. The -N option instructs SSH not to execute a command on the target system (the local workstation in this case). I other words, the remote system allows us back in using the SSH channel it opened. Now we can ssh log-in to the remote server:

ooga% ssh user@localhost -p 50000

The username user is a valid user on the  remote sever, the -p 50000 option tells ssh to use the local port 50000 to connect.

Keep in mind that for the remote tunnel to work it has be established from the remote server. There are two ways to accomplish that:

• have somebody do this for you, if cannot get to the machine at all or
• run a script to do this for you automatically (using cron, watch or something like this)