The first time an SSH client encounters a new remote machine, it may report that it’s never seen the machine before, printing a message like the following:

    $ ssh -l pat shell.isp.com
    The authenticity of host 'shell.isp.com (192.168.0.2)' can't be established.
    RSA key fingerprint is 77:a5:69:81:9b:eb:40:76:7b:13:04:a9:6c:f4:9c:5d.
    Are you sure you want to continue connecting (yes/no)?

Assuming you respond yes (the most common response), the client continues:

    Warning: Permanently added 'shell.isp.com,192.168.0.2' (RSA) to the list of known hosts
               .

This message appears only the first time you contact a particular remote host. The message is a security feature related to SSH’s concept of known hosts.^[7]

Suppose an adversary wants to obtain your password. He knows you are using SSH, and so he can’t monitor your connection by eavesdropping on the network. Instead, he subverts the naming service used by your local host so that the name of your intended remote host, shell.isp.com, translates falsely to the IP address of a computer run by him! He then installs an altered SSH server on the phony remote host and waits. When you log in via your trusty SSH client, the altered SSH server records your password for the adversary’s later use (or misuse, more likely). The bogus server can then disconnect with a preplanned error message such as “System down for maintenance—please try again after 4:00 p.m.” Even worse, it can fool you completely by using your password to log into the real shell.isp.com and transparently pass information back and forth between you and the server, monitoring your entire session. This hostile strategy is called a man-in-the-middle attack. [3.9.4] Unless you think to check the originating IP address of your session on the server, you might never notice the deception.

The SSH known-host mechanism prevents such attacks. When an SSH client and server make a connection, each of them proves its identity to the other. Yes, not only does the server authenticate the client, as we saw earlier when the server checked Pat’s password, but the client also authenticates the server by public-key cryptography. [3.4.3.6] In short, each SSH server has a secret, unique ID, called a host key, to identify itself to clients. The first time you connect to a remote host, a public counterpart of the host key gets copied and stored in your local account (assuming you responded “yes” to the client’s prompt about host keys , earlier). Each time you reconnect to that remote host, the SSH client checks the remote host’s identity using this public key.

Of course, it’s better to have recorded the server’s public host key before connecting to it the first time, since otherwise you are technically open to a man-in-the-middle attack that first time. Administrators can maintain systemwide known-hosts lists for given sets of hosts, but this doesn’t do much good for connecting to random new hosts around the world. Until a reliable, widely deployed method of verifying such keys securely exists (such as secure DNS, or X.509-based public-key infrastructure), this record-on-first-use mechanism is an acceptable compromise.

If authentication of the server fails, various things may happen depending on the reason for failure and the SSH configuration. Typically a warning appears on the screen, ranging from a repeat of the known-hosts message:

    Host key not found from the list of known hosts.
    Are you sure you want to continue connecting (yes/no)?

to more dire words:

    @@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@
    @    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
    77:a5:69:81:9b:eb:40:76:7b:13:04:a9:6c:f4:9c:5d.
    Please contact your system administrator.
    Add correct host key in /home/smith/.ssh/known_hosts to get rid of this message.
    Offending key in /home/smith/.ssh/known_hosts:36

If you answer yes, ssh allows the connection, but disables various features as a security precaution and doesn’t update your personal known-hosts database with the new key; you must do that yourself to make this message go away.

As the text of the message says, if you see this warning, you aren’t necessarily being hacked: for example, the remote host key may have legitimately changed for some reason. In some cases, even after reading this book, you won’t know the cause of these messages. If you need assistance, contact your system administrator or a knowledgeable friend, rather than take a chance and possibly compromise your password. We’ll cover these issues further when we discuss personal known hosts databases and how to alter the behavior of SSH clients with respect to host keys.[7.4.3]

Let us return to the shell.isp.com example, just after you’d discovered the attachment in your remote email message and saved it to the remote file printme.pdf. In our original example, you then logged out of shell.isp.com and ran scp to transfer the file. But what if you don’t want to log out? If you’re using a workstation running a window system, you can open a new window and run scp. But if you’re using a lowly text terminal, or you’re not familiar with the window system running on your friend’s computer, there is an alternative. You can temporarily interrupt the SSH connection, transfer the file (and run any other local commands you desire), and then resume the connection.

ssh supports an escape character , a designated character that gets the attention of the SSH client. Normally, ssh sends every character you type to the server, but the escape character is caught by the client, alerting it that special commands may follow. By default, the escape character is the tilde (~), but you can change it. To reduce the chances of sending the escape character unintentionally, that character must be the first character on the command line, i.e., following a newline (Control-J) or return (Control-M) character. If not, the client treats it literally, not as an escape character.

After the escape character gets the client’s attention, the next character entered determines the effect of the escape. For example, the escape character followed by a Control-Z suspends ssh like any other shell job, returning control to the local shell. Such a pair of characters is called an escape sequence. We cover these in detail in a later chapter. [7.4.6.8]

To change the ssh escape character, use the -e command-line option. For example, type the following to make the percent sign (%) the escape character when connecting to shell.isp.com as user pat:

    $ ssh -e "%" -l pat shell.isp.com