Out of all of the utilities available to systems administrators ssh is probably the most useful of them all. Not only does it allow you to log into systems securely, but it can also be used to copy files, tunnel IP traffic and run remote commands on distant servers. It’s truly the Swiss army knife of systems administration. Secure Shell, also known as ssh, was developed in 1995 by Tau Ylonen after the University of Technology in Finland suffered a password sniffing attack. Back then it was common to use tools like rcp, rsh, ftp and telnet to connect to systems and move files across the network. The main problem with these tools is they provide no security and transmitted data in plain text including sensitive login credentials. SSH provides this security by encrypting all traffic transmitted over the wire to protect from password sniffing attacks.

One of the more common use cases involving SSH is found when using scp. Secure Copy (scp) transmits data between hosts using SSH and allows you to easily copy all types of files.

The syntax for the scp command is:

scp /pathlocal/filenamelocal remoteuser@remotehost:/pathremote/filenameremote

In the following simple example, I move a file named myfile from the system test1 to the system test2. I am prompted to provide valid user credentials for the remote host before the transfer will proceed.  If I were only using ftp, this information would be unencrypted as it went across the wire.  However, because scp uses SSH, my user credentials and the file and its contents are confidential and remain secure throughout the transfer. 

[user1@test1 ~]# scp /home/user1/myfile user1@test2:/home/user1
user1@test2's password: 
myfile                                    100%    0     0.0KB/s   00:00

You can also use ssh to send network traffic and utilize the encryption built into ssh to protect traffic over the wire. This is known as an ssh tunnel. In order to utilize this feature, the server that you intend to connect to (the remote system) must have TCP forwarding enabled within the sshd configuraton. To enable TCP forwarding on the remote system, make sure AllowTCPForwarding is set to yes and enabled in the /etc/ssh/sshd_conf file:

AllowTcpForwarding yes

Once you have this configured, you can connect to the server and setup a local port which you can direct traffic to that will go over the secure tunnel. The following command will setup a tunnel on port 8989 on your local system. You can then redirect a web browser to use this local port, allowing the traffic to go through the encrypted tunnel to the remote system. It is important to select a local port that is not being used by a service and is not restricted by firewall rules.  In the following example the -D specifies a local dynamic application level port forwarding and the -N specifies not to execute a remote command.  

ssh –D 8989 [email protected] -N

You can also forward specific ports on both the local and remote host. The following example will setup a port forward on port 8080 and forward it to port 80 on the remote machine.

ssh -L 8080:farwebserver.com:80 [email protected]

You can even run remote commands via ssh which is quite useful for scripting or remote system administration tasks. The following example shows how to  log in remotely and execute the command ls –la in the home directory of the machine. Because ssh encrypts the traffic, the login credentials and output of the command are completely protected while they travel over the wire.

[rchase@test1 ~]$ ssh rchase@test2 'ls -la'
rchase@test2's password: 
total 24
drwx------  2 rchase rchase 4096 Sep  6 15:17 .
drwxr-xr-x. 3 root   root   4096 Sep  6 15:16 ..
-rw-------  1 rchase rchase   12 Sep  6 15:17 .bash_history
-rw-r--r--  1 rchase rchase   18 Dec 20  2012 .bash_logout
-rw-r--r--  1 rchase rchase  176 Dec 20  2012 .bash_profile
-rw-r--r--  1 rchase rchase  124 Dec 20  2012 .bashrc

You can execute any command contained in the quotations marks as long as you have permission with the user account that you are using to log in. This can be very powerful and useful for collecting information for reports, remote controlling systems and performing systems administration tasks using shell scripts.

To make your shell scripts even more useful and to automate logins you can use ssh keys for running commands remotely and securely without the need to enter a password. You can accomplish this with key based authentication. The first step in setting up key based authentication is to generate a public key for the system that you wish to log in from. In the following example you are generating a ssh key on a test system. In case you are wondering, this key was generated on a test VM that was destroyed after this article.

[rchase@test1 .ssh]$ ssh-keygen -t rsa
Generating public/private rsa key pair.
Enter file in which to save the key (/home/rchase/.ssh/id_rsa): 
Enter passphrase (empty for no passphrase): 
Enter same passphrase again: 
Your identification has been saved in /home/rchase/.ssh/id_rsa.
Your public key has been saved in /home/rchase/.ssh/id_rsa.pub.
The key fingerprint is:
7a:8e:86:ef:59:70:ef:43:b7:ee:33:03:6e:6f:69:e8 rchase@test1
The key's randomart image is:
+--[ RSA 2048]----+
|                 |
|  . .            |
|   o .           |
|    . o o        |
|   o o oS+       |
|  +   o.= =      |
|   o ..o.+ =     |
|    . .+. =      |
|     ...Eo       |
+-----------------+

Now that you have the key generated on the local system you should to copy it to the target server into a temporary location. The user’s home directory is fine for this.

[rchase@test1 .ssh]$ scp id_rsa.pub rchase@test2:/home/rchase
rchase@test2's password: 
id_rsa.pub                 

Now that the file has been copied to the server, you need to append it to the authorized_keys file. This should be appended to the end of the file in the event that there are other authorized keys on the system.

[rchase@test2 ~]$ cat id_rsa.pub >> .ssh/authorized_keys

Once the process is complete you are ready to login. Since you are using key based authentication you are not prompted for a password when logging into the system.  

[rchase@test1 ~]$ ssh test2
Last login: Fri Sep  6 17:42:02 2013 from test1

This makes it much easier to run remote commands. Here’s an example of the remote command from earlier. With no password it’s almost as if the command ran locally.

[rchase@test1 ~]$ ssh test2 'ls -la'
total 32
drwx------  3 rchase rchase 4096 Sep  6 17:40 .
drwxr-xr-x. 3 root   root   4096 Sep  6 15:16 ..
-rw-------  1 rchase rchase   12 Sep  6 15:17 .bash_history
-rw-r--r--  1 rchase rchase   18 Dec 20  2012 .bash_logout
-rw-r--r--  1 rchase rchase  176 Dec 20  2012 .bash_profile
-rw-r--r--  1 rchase rchase  124 Dec 20  2012 .bashrc

As a security consideration it's important to note the permissions of .ssh and the authorized_keys file.  .ssh should be 700 and authorized_keys should be set to 600.  This prevents unauthorized access to ssh keys from other users on the system.  

An even easier way to move keys back and forth is to use ssh-copy-id. Instead of copying the file and appending it manually to the authorized_keys file, ssh-copy-id does both steps at once for you.  Here’s an example of moving the same key using ssh-copy-id.The –i in the example is so that we can specify the path to the id file, which in this case is /home/rchase/.ssh/id_rsa.pub

[rchase@test1]$ ssh-copy-id -i /home/rchase/.ssh/id_rsa.pub rchase@test2

One of the last tips that I will cover is the ssh config file. By using the ssh config file you can setup host aliases to make logins to hosts with odd ports or long hostnames much easier and simpler to remember. Here’s an example entry in our .ssh/config file.

Host dev1
Hostname somereallylonghostname.somereallylongdomain.com
Port 28372
User somereallylongusername12345678

Let’s compare the login process between the two. Which would you want to type and remember?

ssh somereallylongusername12345678@ somereallylonghostname.somereallylongdomain.com –p 28372

ssh dev1

I hope you find these tips useful.  There are a number of tools used by system administrators to streamline processes and simplify workflows and whether you are new to Linux or a longtime user, I'm sure you will agree that SSH offers useful features that can be used every day.  Send me your comments and let us know the ways you  use SSH with Linux.  If you have other tools you would like to see covered in a similar post, send in your suggestions.