SSH: Secure Console Access From Afar

There comes a time in every Linux user’s life where it would be quite handy to administer the box remotely. Whether it is to tweak some Linux settings from a Windows box or to fiddle with the Linux server in the basement from the comfort of your desktop system upstairs, SSH (Secure SHell) can make your dreams come true. Today, we are going to talk about some of the tricks this protocol can do and how to best secure it. Click on for more.

A Brief History

A Brief History

Back in the day, if you wanted to remotely connect to a *nix computer you used a protocol called "telnet".  It provided a command prompt after the user properly authenticated with a login and password.  However, all the traffic between the server and remote client was sent unencrypted including the login name and password.  Fortunately, those were the days when people could be trusted, and networks were rarely attacked.  As people with the capability to "sniff" network traffic became more common, the need to keep such information from them increased.  Thus, from this need the SSH protocol was born.  SSH still provides a remote command prompt, but it encrypts everything including the initial login and password exchange.  A third party can capture all the session packets and still not be able to determine a user’s credentials.

Now, I can hear you saying, "But John, why would I deploy this in my own home where I’m the only user and I have a firewall to keep the riff-raff out?"  Actually, most Linux distributions come with the SSH service already configured and running on the server, so that takes care of half of the "deploy" part.  Second, there are some rather cool tricks that can be done with SSH once a connection has been established, but more on that later.

Simple Install And Configuration

Simple Install And Configuration

Let’s start off with a common scenario.  A Linux distribution (CentOS/Fedora in this case) was just installed on a PC, but it’s in a rather unhandy location of the house and the user would rather sit at their Windows PC upstairs to finish tweaking the install.  Before moving upstairs to the easy chair, do a couple quick checks on the Linux box.  As root, run:

netstat -n -a -A inet

Look for the line:

tcp        0      0 0.0.0.0:22         0.0.0.0:*        LISTEN

This means that the SSH service is up and running and listening for a connection.  If nothing is listening on port 22, then perhaps the service just needs to be started:

/etc/init.d/sshd start

After that, re-run the "netstat" command above and verify the above response.  Now it’s time to determine what IP address the server has acquired by running:

ifconfig

There will be a listing of various network devices.  If your network card has been configured properly, "eth0" should be one of those listed.  Within that block of info should be a string like:

inet addr:192.168.10.1

In your case, the IP will be a different number, but in any case, write that number down as that’s what will be needed to connect remotely.  If there are multiple "eth" devices, then you have a more complicated setup.  But I’m guessing if you knew enough to get that working, then you are sharp enough to figure out which IP to use.

Now we are ready to move to the remote PC to set up the client side of the connection.  As mentioned above, in this case the client PC will be Windows based, so we need to find a suitable SSH client.  While there are several commercial applications available, I have used PuTTY for some time now.  Why?  Because it is free, fast, and has all the functionality that I require.  So, go over to the download page and grab putty.exe.  There is no install as everything is contained within that executable.  Go ahead and launch PuTTY.  The first screen you come to will ask for a "Host Name".  Just type in the Linux server’s IP that was found above.  Leave the port at "22" and leave "SSH" selected as the connection type and click "Open".  PuTTY will likely show a "Security Alert" stating the server’s RSA2 key fingerprint and asking if you want to trust this server.  Go ahead and click "Yes" and there will be a login prompt presented.  Enter your user name and password.  Once the credentials are accepted, a shell prompt is provided and you are good to go.  Everything that is typed is encrypted, and the user has the luxury of not having to be in front of the Linux box. 

Pump Up The Security

Pump Up The Security 

Assume that the user is no longer within their own network, but instead has their laptop at work or at a friend’s house.  For some reason they suddenly have a need to connect to their home server.  No problem.  Just configure the router/firewall to forward TCP port 22 traffic to the Linux server.  Next, you need to determine what your public IP address is on the router/firewall, so you know what IP to connect to.  Some ISPs change the IPs regularly, so it may be handy to utilize the services of DDNS which makes life easier.  Now, it is possible to access your Linux server from anywhere on the planet.  This can be pretty useful at times.  It can also be very useful for those looking to crack a server for their own purposes, so let’s harden this up a bit.

Some Linux distributions come pre-configured to allow root to login remotely over SSH.  Why is this bad you ask?  Usually a potential cracker has two pieces of information that they need to acquire a SSH connection; login name and password.  In the case of the root account, they already know the name as it is universal.  They only need to guess at the password and they are in.  I have seen hundreds of attempts in a day to get in via this method.  There are software programs which are designed to do dictionary attacks on the root account via SSH.  Eventually, if your password is weak enough, they will get in.  Let’s close this hole by disabling the SSH root login.

First, make sure you have remembered to create a non-root user.  If you haven’t, then do that now (without the brackets):

adduser <username>
passwd <username>

Start up a new PuTTY SSH connection and use the new user credentials to login verifying that everything works as advertised.  It’s quite simple to get root privileges from this user account by typing:

su –

You will be asked for the root password and then given a root shell prompt.  Now, that you can get in as a non-root user, let’s lock down the SSH service to deny root access.

nano -w /etc/ssh/sshd_config

Scroll down until you see the line:

#PermitRootLogin yes

Remove the "#" to uncomment it and change the "yes" to a "no".  Save the changes by pressing Control-x, "y" to confirm the changes, and <enter> to confirm the file name.  Now restart the SSH service by typing:

/etc/init.d/sshd restart

At this point, verify that it is still possible to login giving the non-root user credentials, and that giving root credentials fails.  Congratulations, you are now slightly more secure.  Any hopeful cracker now has to determine your non-root user name and its password to successfully login.  A daunting task, but still possible if given enough time.  What else can be done?  Well, it is possible to run the SSH service on a non-standard port other than 22.  Re-open the sshd_config file using the command above and uncomment and change the following to a different port number:

#Port 22

Save the file and restart the service and it should now be listening on the new port.  Remember to change to the same port on the client side or you won’t connect.  Also, the route/firewall forwarding rules will need to be updated to match this change.  This is a nice "security through obscurity" trick, but anyone with a port scanner can make short work of this.  What we need is a way to automatically authenticate our identity, but at the same time use ridiculously long keys that we don’t have to remember.

Break Out The Keys

Break Out The Keys

What we are describing is public/private key authentication.  It is a way of distributing a "public" key to a SSH server you wish to connect and a "private" key which is kept secret on the client PC.  During the login process, both keys are compared to determine if they are correct.  If they are OK, then the server allows the client to connect.  Once this is configured and working, the old method of user names and passwords can be disabled forever blocking those looking to dictionary guess their way into your server.

First, download the puttygen.exe program which is used to create the key pair.  Like the main PuTTY application, this does not need to be installed.  After launching the PuTTY key generator, click on the "Generate" button.  The application needs a source of "random" data to ensure that the keys are strong.  There are several ways to go about this, but in this case it uses input from your mouse, so move the mouse pointer around the window until the progress bar fills completely.  Once that is complete, it will run the progress bar one more time while it completes the key creation process.

Once the keys are created, launch PuTTY, connect to your Linux server as the non-root user, and type the following commands:

mkdir -p ~/.ssh
chmod 700 ~/.ssh
nano -w ~/.ssh/authorized_keys

At this point, copy/paste the contents of the "Public key for pasting into OpenSSH authorized_keys file" window in the PuTTY key gen software into the authorized_keys file that is open in the PuTTY client.  This should be a bunch of random characters which starts with "ssh-rsa".  In the PuTTY client, save the file and exit the nano editor.  In the PuTTY key gen, press the "Save private key" button and save this key somewhere safe.  Remember, this is your private key which grants you access to your server.  Whoever holds it can get in.

Close out the PuTTY key generator and launch a new instance of PuTTY and fill in the appropriate IP address and port number for the Linux server.  On the left in the "Category" tree menu, expand "Connection" then "SSH" and finally select "Auth".  Click the "Browse…" button and find the private key file that was just saved.  Click "Open" and type in the name of the non-root user when prompted.  If all went well, it should not ask for a password, but instead exchange keys and automatically log you in.

Once things are connecting smoothly by using keys, let’s configure the SSH service to refuse password authentication.

nano -w /etc/ssh/sshd_config

Scroll down until you find "PasswordAuthentication yes" and change that to "no".  Exit nano and save the file.  Restart the SSH service by running:

/etc/init.d/sshd restart

The SSH service should now refuse any password style authentication, but continue to accept key authentication.  At this point, SSH is locked down pretty tight.  There are other things which can increase security further, but at the expense of increased aggravation for the end user.

Tunnel Me This

Tunnel Me This

So, what tricks can this SSH protocol do for us?  Let’s consider this scenario:  Your Linux server has been configured as a MythTV appliance complete with a web interface which can be used to schedule recordings amongst other things.  You’ve gone to work only to discover that you forgot to schedule a show which will air while you are still at work.  You don’t want to forward web connections on your router/firewall to your MythTV server because then anyone could change your recordings.  However, this kind of remote access would be extremely handy at times like this.  What is one to do?  SSH tunnels to the rescue!

A SSH tunnel is a way of routing traffic through the encrypted connection between your PuTTY client and the remote Linux server.  To configure a tunnel to handle the proposed scenario, launch PuTTY and fill in the IP and port number.  On the left, expand "Connection" then "SSH" and finally select "Tunnels".  Type "80" in the "Source port" field, "localhost:80" in the "Destination" field, and ensure that "Local" and "Auto" are selected.  Now click the "Add" button to lock in these options.  Port 80 is the port which is used to access web content (HTTP), so this in effect sets up a tunnel from port 80 on the client PC which will come out at port 80 on the Linux server.  Click "Open" and proceed to log into the Linux server.  Launch a web browser and type "localhost" into the web page address field.  If all went well, it should display the web page from the Linux server.  Remember, this will only work while PuTTY is connected to the Linux server.  If PuTTY is closed, then the SSH tunnel is broken.

SSH tunneling can be used for almost any application which communicates via the network.  Some of the more popular choices are VNC, MySQL database administration, NFS shares, Samba Windows shares, and POP3/IMAP/SMTP email traffic to name a few.  In fact, the remote destination doesn’t need to be the Linux server at all.  In a pinch, it can be used to remotely administer your home router/firewall.  Just change the ports to be the same as those used to administer the router/firewall locally and change the destination to be the internal IP of the router/firewall.  A single SSH session can support many simultaneous tunnels.  In fact, it is mainly limited to the bandwidth of the connection between the client and the server.  This can be improved upon by enabling SSH compression under "Connection" and "SSH".  Some CPU power is used on both ends, but it can improve transfer rates.

SCP/FTP To The Rescue

 

SCP/FTP To The Rescue

One last capability of the SSH protocol is to transfer files between the connected computers.  There are two methods to accomplish this: SCP and SFTP.  SCP is a encrypted version of the insecure *NIX remote copy command "rcp".  As you might guess, SFTP is an encrypted FTP session.  Both transfer files, but SCP seems to transfer faster over a given network link due to its smaller protocol overhead, while SFTP supports all of the typical directory listing commands.  Some SCP clients get around this limitation by gathering the extra information via a shell account.

The remote Linux server should be configured to accept either transfer protocol by default, so we only need to find a Windows client.  Going on the fast, functional, and free method of software selection, we come across WinSCP.  Download the latest version and install it.  When you launch WinSCP, it will prompt for an IP, username, password, and port.  If you are using private/public keys for authentication in PuTTY, then simply point WinSCP to the same private key file.  WinSCP uses PuTTY in the background to perform encryption and authentication, so both packages naturally work well together.

Once you have connected using WinSCP, it will present a directory listing of the remote folder.  Moving around the folders is similar to navigating in Windows Explorer.  WinSCP also supports full drag and drop features.  Keep in mind that you have logged in with your non-root user account meaning that you will be limited to what that user is allowed to view, copy, and write.

Conclusion

 

Conclusion

I hope that this has provided a good overview of all the features and benefits of the SSH protocol.  Its various levels of security give the user the flexibility to choose the correct balance of user convenience and piece of mind for any application.  SSH tunnels provide a mechanism for a poor man’s VPN access enabling functionality which is usually only available locally.  The SCP & SFTP protocols give a handy means for transferring files without the complicated configuration or security issues of the more popular FTP, NFS, or Samba protocols.

Perhaps you’ve used SSH in another way than what is mentioned above.  If so, give us shout in the forums.  Maybe you are having issues with an aspect of its configuration.  Your questions are of course welcome as well.