SSH Tutorial for Ubuntu Linux

I touched on this topic in my First Day with Ubuntu at the Office post under Accessing Remove File Systems; however, I thought that this deserved its own topic.

For those that don’t know SSH stands for Secure SHell. In very non-technical terms, SSH allows you to access a system running a SSH server over a network. This other system can be another computer in your home or a remote system on the other side of the planet. SSH will allow you to connect to that other system and communicate with it securely. All the data passed back and forth is encrypted, so you don’t have to worry about people sniffing your passwords or valuable data.

You may be asking what all of that means to you. What it means is that you can connect to and control a computer that is somewhere else with the computer that is sitting right in front of you. If you have a remote webserver running Linux, SSH will let you install software, edit files, change the server configuration, access the database, and more. Did you forget a file on your computer at home? No problem, just SSH into your home computer and send the file to your email account or copy it directly to your office computer.

Hopefully those quick examples of what you can do is enough to whet your appetite.

Making SSH Work for You

When working on a Linux system, connecting to other Linux systems via SSH becomes so easy. Everything you need is bundled directly into the OS. All you need to do is load up the Terminal and run something that looks like the following:

After supplying the password, you’re connected.

So, if this is so easy, you might wonder what could make this any simpler. While the process I just described is definitely easy, there is always some server out there that requires a ssh command that is just difficult enough to be annoying. For example, imagine having to type the following each time you wanted to connect:

While it’s possible to remember this, who wants to?

Host-Based Config Options

Fortunately, ssh has a way to store options for each host.

This will load up the config file for editing in Gedit.

The format for setting options is as follows:

Using the config file, you can lose all those additional options and quickly connect by just using the following command:

Doesn’t that look a lot better?

Take the previous nasty example I provided. I can add the following to my config file for that specific host:

Host locutus.borg.domain.com
    User really_long_username
    Port 2222
    Protocol 2
    Cipher blowfish-cbc,aes256-cbc

After adding this to my ~/.ssh/config file, I can now connect with:

Easy cheesy.

There are a large variety of options available for the host-based config. For a full list of these options, run “man ssh_config” from Terminal.

Creating Hostname Aliases

Given the previous example, the hostname is locutus.borg.domain.com. That’s quite a bit to type, and it isn’t easy to remember how to spell locutus properly. Fortunately, the config file comes to the rescue again.

We can update our previous host definition to the following:

Host locutus.borg.domain.com locutus borg loc domain.com 192.168.1.105
    Hostname locutus.borg.domain.com
    User really_long_username
    Port 2222
    Protocol 2
    Cipher blowfish-cbc,aes256-cbc

Now I can easily connect to the system using any of the following commands:

Simply set up all the alias names you’d like to have after “Host” while seperating each one with a space. I always keep the original hostname in the list and add an additional alias to is easy to remember and type.

Keep the Connection Alive

Due to issues either caused by certain routers’ NAT firewalls or due to odd server configurations, I have found that my SSH connections will die if I leave then idle for too long. This is very annoying as it leaves me with a frozen session that I can’t do anything with. Fortunately, config comes to the rescue again. On each and every one of my host options in my config files, I have a ServerAliveInterval option that tells ssh to send a small keep-alive packet to the server at an interval that I specify.

For example:

Host domain.com
    User chris
    ServerAliveInterval 240

This tells ssh to send a keep-alive packet every 240 seconds, or four minutes. Now the only thing that terminates my connection is an actual loss of internet connection.

If you find that your connection still drops when idle, lower the number until it stabilizes. Even though the packet is small, you don’t want to send it too much. So, only lower the value to below a minute if you must.

Using Keypairs to Increase Security

SSH has the ability to use security keypairs to authenticate your session with the server. A security key can replace the need to supply your password when connecting to your server.

If you have access to modify your server’s SSH daemon settings, you can use your authentication key to disable password authentication. This means that an attacker would have to break your key’s encryption in order to connect rather than just having to guess your password.

Another great feature of keys is that you can use the same key for multiple server accounts. Since the private part of your key only resides on your local system, using the same key for multiple systems doesn’t decrease security in the same way that using the same password on multiple servers can. For example, if someone broke into one of your server accounts, they could get your public key, but this key will only give them the ability to give your key the ability to authenticate on other servers rather than giving them the ability to authenticate on the rest of your’s.

What This Means for Shared Servers

If your server is a shared host where you don’t have access to root, you typically can’t disable password authentication; however, keys can still greatly increase your security. Since you won’t need to supply your user’s password each time you connect since the key is doing the authentication, you can change your user’s password to something extremely strong and complex. This will make it very difficult for anyone to break into your account using brute-force methods.

Generating a SSH Authentication Key

Generating a key is extremely simple. Ubuntu, and most major distributions, have all the software you need already installed. Simply run the following command in Terminal:

Accept the defaults for all the options except the password.

Supplying the password is optional. If you simply press enter without supplying a password, your key won’t require a password to use. Let me share some information about what having a password on your key means to you.

• Unlike some password protection methods where the password is easily cracked, your key’s password is an integral part of the key. Without your password, the key is useless.
• If your key does not have a password, anyone who manages to gain access to your private key will have the ability to connect to every server your key is authenticated for without any password or other authentication required.
• On many systems, you will have to supply the password each and every time the key is used. Fortunately, for us Ubuntu users, we can simply opt to have the system remember the password for us as long as we are logged into our desktop. I’m sure that this feature is present on other systems, such as Linux Mint, but I haven’t tested which ones have this feature yet.

As you can see, there are great benefits to using a password on your key. There really aren’t any good reasons to not put a password on the key since Ubuntu will remember it for you.

By now, you should have generated your key. If you accepted the default location, you should have two new files in your ~/.ssh directory: id_dsa and id_dsa.pub.

The ~/.ssh/id_dsa file is your private key. This file should remain safe and secure on your system.

The ~/.ssh/id_dsa.pub file is your public key. The contents of this file will be used to authenticate your key with servers.

The permissions on the ~/.ssh/id_dsa file should be set up correctly by ssh-keygen. I like to make sure however as the wrong permission settings can cause the key to be ignored when authenticating. You can set the correct permissions by running:

Now it’s time to set up the server.

Setting up Your Server

Now you need to log into the server you want to use your key to authenticate with.

You need to create a ~/.ssh folder if one doesn’t already exist:

The -p will prevent an error from being thrown if the folder already exists.

Exit out of your server connection. We’re going to do a slick command from our Ubuntu Terminal to add our public key to the server.

From our desktop’s Terminal (not the server’s command line), run the following:

Replace hostname with the hostname that you use to connect to your server with. I’m assuming that you followed my instructions earlier and set up your ~/.ssh/config file to not require anything more than a hostname to set all the options needed to connect. If you haven’t done this, make sure you specify the port number (if other than 22), username, and any other necessary options to make the connection.

Testing

Now we just need to connect to the server again and see if it asks for the password.

If you are asked for a password, your authentication key was either not recognized, had improper permissions, or was not able to match with the server’s public key setting. A good way of checking on a potential problem is to run:

This will cause a large amount of verbose debug data to be printed during the connection phase. If the key is used properly, you should see the lines listed:

If you don’t see that the server can see the publickey authentication method or if that method isn’t the first one, your server isn’t set up to do key authentication. Contact your hosting provider and ask them if they can add this as it will increase server security.

If you can’t figure out the problem, please let me know. You can send me the output of your “ssh -v hostname” command via the Contact page, and I’ll do my best to help you out.

Conclusion

I hope that I helped you use ssh more efficiently and make your servers more secure at the same time. However, I’ve just scratched the surface on this topic. There are dozens of ways to use SSH in ways that I haven’t touched on.

Here are just a few additional things that you can do with SSH:

• Log into a visual desktop remotely by tunneling X
• Secure FTP alternative: use scp to easily transfer files between systems
• Mount remote file systems as local mount points
• Browse securely on insecure networks or bypass network restrictions to browse freely
• Easily run a command on remote servers directly. This is great for scripting status programs.
• And many more possibilities

I’m sure that I’ll touch on some of these subjects later on. If you’d like me to get to specific ones ASAP, please leave a coment and let me know what you’d like to see.