Suppose your remote username on shell.isp.com is pat. To connect to your remote account from your friend’s account on local.university.edu, you type:
$ ssh -l pat shell.isp.com
pat's password: ******
Last login: Mon Aug 16 19:32:51 2004 from quondam.nefertiti.org
You have new mail.
shell.isp.com>This leads to the situation shown in Figure 2-1. The ssh command runs a client that contacts the SSH server on shell.isp.com over the Internet, asking to be logged into the remote account with username pat.[5] You can also provide user@host syntax instead of the -l option to accomplish the same thing:
$ ssh pat@shell.isp.com
On first contact, SSH establishes a secure channel between the client and the server so that all transmissions between them are encrypted. The client then prompts for your password, which it supplies to the server over the secure channel. The server authenticates you by checking that the password is correct and permits the login. All subsequent client/server exchanges are protected by that secure channel, including everything you type into the SSH application and everything it displays to you from shell.isp.com.
It’s important to remember that the secure channel exists only between the SSH client and server machines. After logging into shell.isp.com via ssh, if you then telnet or ftp to a third machine, insecure.isp.com, the connection between shell.isp.com and insecure.isp.com is not secure. However, you can run another ssh client from shell.isp.com to insecure.isp.com, creating another secure channel, which keeps the chain of connections secure.
We’ve covered only the simplest use of ssh. Chapter 7 goes into far greater depth about its many features and options.
Continuing the story, suppose that while browsing your files, you encounter a PDF file you’d like to print. In order to send the file to a local printer at the university, you must first transfer the file to local.university.edu. Once again, you reject as insecure the traditional file-transfer programs, such as ftp. Instead, you use another SSH client program, scp, to copy the file across the network via a secure channel.
First, you write the attachment to a file in your home directory on shell.isp.com using your mail client, naming the file printme.pdf. When you’ve finished reading your other email messages, log out of shell.isp.com, ending the SSH session and returning to the shell prompt on local.university.edu. You’re now ready to copy the file securely.
The scp program has syntax much like the traditional Unix cp program for copying files.[6] It is roughly:
scpname-of-sourcename-of-destination
In this example, scp copies the file printme.pdf on shell.isp.com over the network to a local file in your friend’s account on local.university.edu, also called printme.pdf :
$ scp pat@shell.isp.com:printme.pdf printme.pdf
The file is transferred over an SSH-secured connection. The source and destination files may be specified not only by filename, but also by username (“pat” in our example) and hostname (shell.isp.com), indicating the location of the file on the network. Depending on your needs, various parts of the source or destination name can be omitted, and default values used. For example, omitting the username and the at sign (pat@) makes scp assume that the remote username is the same as the local one.
Like ssh, scp prompts for your remote password and passes it to the SSH server for verification. If successful, scp logs into the pat account on shell.isp.com, copies your remote file printme.pdf to the local file printme.pdf, and logs out of shell.isp.com. The local file printme.pdf may now be sent to a printer.
The destination filename need not be the same as the remote one. For example, if you’re feeling French, you could call the local file imprime-moi.pdf :
$ scp pat@shell.isp.com:printme.pdf imprime-moi.pdf
The full syntax of scp can represent local and remote files in powerful ways, and the program also has numerous command-line options. [7.5]