The history of Unix has virtually always featured computers connecting to other computers in some fashion, whether they were dumb terminals connecting to a mainframe computer or Unix machines acting as nodes on the fledgling Internet. Because of this, a wide variety of techniques and protocols were invented to allow computers to communicate and log in to each other across networks.
However, while these still work fine over the modern Internet, the Internet presents a new threat to the privacy of your data. In theory, any data transmitted across the Internet can be picked up by individuals at certain key stages along the route. If the data isn't protected in any way, it can be read and privacy breached.
To counter such an occurrence, the ssh suite of programs was created. Although these programs started as open source, they gradually became proprietary. Therefore several newer open-source versions were created, including the one used on the majority of Linux distributions: OpenSSH.
The goal of the ssh program is to let you log in to a remote computer and initiate a shell session, as if you were sitting in front of it. However, it uses various techniques at both ends of the connection to encrypt not only the data passing between the two machines, but also the username and password. This creates a completely secure connection between the two machines.
This chapter refers to remote and local machines. The remote machine is the computer you're connecting to across the network or Internet. The local machine is the one you're actually sitting in front of. These two terms are widely used within documentation describing networking.
Initiating an ssh session with another machine is usually achieved by typing something similar to the following:
In other words, you specify the username you want to log in under, as well as the address of the machine. The example uses an IP address, but if there's a fully qualified domain name (FQDN) for that particular system, you could specify that instead. An FQDN is the portion of a URL that identifies the server it points to; that is, all of the URL, minus the http:// prefix. So if 192.168.0.11 were the IP address of the www.myserver.com server, then the FQDN would be www.myserver.com.
When you log in for the first time, you'll be told that, "The authenticity of the host <host IP address> can't be established," as shown in the example in Figure 34-1. This means that the remote computer's encryption key hasn't yet been added to your PC's store file. However, once you agree to the initial login, the encryption key will be added, and it can be used in the future to confirm that the remote computer you're connecting to is authentic.
Figure 34-1. When logging in via ssh for the first time, you'll need to confirm acceptance of the encryption key.
There's a fine line between security concerns and paranoia. Connecting to a remote machine for the first time and accepting its ssh key is considered insecure by some, because you cannot be 100% sure that the remote machine is the one you want to connect to! It might have been swapped for a different machine by hackers (or some such theory). Because of this, those who are highly security conscious can use the ssh-keygen program to create a key on the remote machine first, and then import it to the local machine before logging in. See the ssh-keygen man page for more details.
After confirming that you want to make the connection, you'll be invited to enter the password for the user account under which you initiated the ssh connection. Once this is done, you should find yourself with a shell login on the remote computer. You can run the same commands as usual and perform identical tasks.
The machine you're logged in to will show no symptoms of being used remotely. This isn't like the movies, where what you type on your local machine is somehow mirrored on the remote machine for all to see. However, obviously, if a user of the remote machine were to view her network connections using something similar to the netstat command, then she would see another computer attached via ssh.
Whenever you open any kind of shell to enter commands and run programs, you might have noticed that any commands you start running last only as long as the shell window is open. When the shell window is closed, any task running within it ends, too. This is because the shell is seen as the "owner" of the process, and when the owner dies, any processes it started also dies.
When using ssh to start a remote shell session, this also applies. Whenever you log out, any tasks you were running are ended. This can be annoying if, for example, you've started a lengthy download on the remote machine. Effectively, you must remain logged in via ssh until the download has finished.
To get around this, you can use the handy screen program. This isn't specifically designed to be an aid to remote logins, but there's no reason why it cannot be used in such a situation.
The screen program effectively starts shell sessions that stick around, even if the shell window is closed or the ssh connection is ended or lost. After logging in to the remote computer via ssh, you can start a screen session by simply typing the program name at the prompt:
Note that, on SUSE Linux at least, there won't be any indication that you're running a screen session, so keep your wits about you.
You can run any commands from within screen. To detach from the screen session, press Ctrl+A and then Ctrl+D. You'll then be returned to the standard shell and can disconnect from your ssh session as usual. However, the screen session will still be running in the background on the remote computer. To prove this, you can log back in, and then type this:
This will resume your screen session, and you should be able to pick up quite literally where you left off; any output from previous commands will be displayed.
To quit a screen session, you can either type exit from within it or press Ctrl+A, and then Ctrl+\ (backslash).
The screen program is very powerful. To learn more about it, read its man page. To see a list of its keyboard commands, press Ctrl+A, and then type a question mark (?) while screen is running.