Documentation< Previous | Contents | Next >
ssh
To address this problem, a new protocol called SSH (Secure Shell) was developed. SSH solves the two basic problems of secure communication with a remote host. First, it au- thenticates that the remote host is who it says it is (thus preventing so-called “man in the middle” attacks), and second, it encrypts all of the communications between the local and remote hosts.
SSH consists of two parts. An SSH server runs on the remote host, listening for incoming connections on port 22, while an SSH client is used on the local system to communicate with the remote server.
Most Linux distributions ship an implementation of SSH called OpenSSH from the OpenBSD project. Some distributions include both the client and the server packages by default (for example, Red Hat), while others (such as Ubuntu) only supply the client. To
enable a system to receive remote connections, it must have the OpenSSH-server package installed, configured and running, and (if the system is either running or is be- hind a firewall) it must allow incoming network connections on TCP port 22.
Tip: If you don’t have a remote system to connect to but want to try these exam- ples, make sure the OpenSSH-server package is installed on your system and use localhost as the name of the remote host. That way, your machine will cre- ate network connections with itself.
The SSH client program used to connect to remote SSH servers is called, appropriately enough, ssh. To connect to a remote host named remote-sys, we would use the ssh client program like so:
[me@linuxbox ~]$ ssh remote-sys
The authenticity of host 'remote-sys (192.168.1.4)' can't be established.
RSA key fingerprint is 41:ed:7a:df:23:19:bf:3c:a5:17:bc:61:b3:7f:d9:bb.
Are you sure you want to continue connecting (yes/no)?
[me@linuxbox ~]$ ssh remote-sys
The authenticity of host 'remote-sys (192.168.1.4)' can't be established.
RSA key fingerprint is 41:ed:7a:df:23:19:bf:3c:a5:17:bc:61:b3:7f:d9:bb.
Are you sure you want to continue connecting (yes/no)?
The first time the connection is attempted, a message is displayed indicating that the au- thenticity of the remote host cannot be established. This is because the client program has never seen this remote host before. To accept the credentials of the remote host, enter “yes” when prompted. Once the connection is established, the user is prompted for his/her password:
Warning: Permanently added 'remote-sys,192.168.1.4' (RSA) to the list of known hosts.
me@remote-sys's password:
Warning: Permanently added 'remote-sys,192.168.1.4' (RSA) to the list of known hosts.
me@remote-sys's password:
After the password is successfully entered, we receive the shell prompt from the remote system:
Last login: Sat Aug 30 13:00:48 2016 [me@remote-sys ~]$
Last login: Sat Aug 30 13:00:48 2016 [me@remote-sys ~]$
The remote shell session continues until the user enters the exit command at the remote shell prompt, thereby closing the remote connection. At this point, the local shell session
resumes and the local shell prompt reappears.
It is also possible to connect to remote systems using a different username. For example, if the local user “me” had an account named “bob” on a remote system, user me could log in to the account bob on the remote system as follows:
[me@linuxbox ~]$ ssh bob@remote-sys
bob@remote-sys's password:
Last login: Sat Aug 30 13:03:21 2016 [bob@remote-sys ~]$
[me@linuxbox ~]$ ssh bob@remote-sys
bob@remote-sys's password:
Last login: Sat Aug 30 13:03:21 2016 [bob@remote-sys ~]$
As stated before, ssh verifies the authenticity of the remote host. If the remote host does not successfully authenticate, the following message appears:
[me@linuxbox ~]$ ssh remote-sys
@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@
@ WARNING: REMOTE HOST IDENTIFICATION HAS CHANGED! @
@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@ IT IS POSSIBLE THAT SOMEONE IS DOING SOMETHING NASTY!
Someone could be eavesdropping on you right now (man-in-the-middle attack)!
It is also possible that the RSA host key has just been changed. The fingerprint for the RSA key sent by the remote host is 41:ed:7a:df:23:19:bf:3c:a5:17:bc:61:b3:7f:d9:bb.
Please contact your system administrator.
Add correct host key in /home/me/.ssh/known_hosts to get rid of this message.
Offending key in /home/me/.ssh/known_hosts:1
RSA host key for remote-sys has changed and you have requested strict checking.
Host key verification failed.
[me@linuxbox ~]$ ssh remote-sys
@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@
@ WARNING: REMOTE HOST IDENTIFICATION HAS CHANGED! @
@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@ IT IS POSSIBLE THAT SOMEONE IS DOING SOMETHING NASTY!
Someone could be eavesdropping on you right now (man-in-the-middle attack)!
It is also possible that the RSA host key has just been changed. The fingerprint for the RSA key sent by the remote host is 41:ed:7a:df:23:19:bf:3c:a5:17:bc:61:b3:7f:d9:bb.
Please contact your system administrator.
Add correct host key in /home/me/.ssh/known_hosts to get rid of this message.
Offending key in /home/me/.ssh/known_hosts:1
RSA host key for remote-sys has changed and you have requested strict checking.
Host key verification failed.
This message is caused by one of two possible situations. First, an attacker may be at- tempting a “man-in-the-middle” attack. This is rare, since everybody knows that ssh alerts the user to this. The more likely culprit is that the remote system has been changed somehow; for example, its operating system or SSH server has been reinstalled. In the in- terests of security and safety however, the first possibility should not be dismissed out of hand. Always check with the administrator of the remote system when this message oc- curs.
After it has been determined that the message is due to a benign cause, it is safe to correct the problem on the client side. This is done by using a text editor (vim perhaps) to re- move the obsolete key from the ~/.ssh/known_hosts file. In the example message above, we see this:
Offending key in /home/me/.ssh/known_hosts:1
Offending key in /home/me/.ssh/known_hosts:1
This means that line one of the known_hosts file contains the offending key. Delete this line from the file, and the ssh program will be able to accept new authentication cre- dentials from the remote system.
Besides opening a shell session on a remote system, ssh also allows us to execute a sin- gle command on a remote system. For example, to execute the free command on a re- mote host named remote-sys and have the results displayed on the local system:
[me@linuxbox ~]$ ssh remote-sys free
me@twin4's password:
total used free
shared
buffers
cached
[me@linuxbox ~]$ ssh remote-sys free
me@twin4's password:
total used free
Mem:
775536 507184 268352
0
110068
154596
Mem:
-/+ buffers/cache:
Swap:
242520 533016
0 1572856
-/+ buffers/cache:
Swap:
[me@linuxbox ~]$
[me@linuxbox ~]$
1572856
1572856
It’s possible to use this technique in more interesting ways, such as this example in which we perform an ls on the remote system and redirect the output to a file on the local sys- tem:
[me@linuxbox ~]$ ssh remote-sys 'ls *' > dirlist.txt
me@twin4's password: [me@linuxbox ~]$
[me@linuxbox ~]$ ssh remote-sys 'ls *' > dirlist.txt
me@twin4's password: [me@linuxbox ~]$
Notice the use of the single quotes in the command above. This is done because we do not want the pathname expansion performed on the local machine; rather, we want it to be performed on the remote system. Likewise, if we had wanted the output redirected to a file on the remote machine, we could have placed the redirection operator and the file- name within the single quotes:
[me@linuxbox ~]$ ssh remote-sys 'ls * > dirlist.txt'
[me@linuxbox ~]$ ssh remote-sys 'ls * > dirlist.txt'
Tunneling With SSH
Part of what happens when you establish a connection with a remote host via SSH is that an encrypted tunnel is created between the local and remote systems. Nor- mally, this tunnel is used to allow commands typed at the local system to be trans- mitted safely to the remote system, and for the results to be transmitted safely back. In addition to this basic function, the SSH protocol allows most types of network traffic to be sent through the encrypted tunnel, creating a sort of VPN (Virtual Private Network) between the local and remote systems.
Perhaps the most common use of this feature is to allow X Window system traffic to be transmitted. On a system running an X server (that is, a machine displaying a GUI), it is possible to launch and run an X client program (a graphical applica- tion) on a remote system and have its display appear on the local system. It’s easy to do; here’s an example: Let’s say we are sitting at a Linux system called lin- uxbox which is running an X server, and we want to run the xload program on a remote system named remote-sys and see the program’s graphical output on our local system. We could do this:
[me@linuxbox ~]$ ssh -X remote-sys
me@remote-sys's password:
Last login: Mon Sep 08 13:23:11 2016 [me@remote-sys ~]$ xload
After the xload command is executed on the remote system, its window appears on the local system. On some systems, you may need to use the “-Y” option rather than the “-X” option to do this.