2.2. Remote Terminal Sessions with sshSuppose 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:
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. You can also provide user@host syntax instead of the -l option to accomplish the same thing:$ ssh -l pat shell.isp.com pat's password: ****** Last login: Mon May 24 19:32:51 1999 from quondam.nefertiti.org You have new mail. shell.isp.com>
If the local and remote usernames are identical, you can omit the -l option (-l pat) and just type ssh shell.isp.com.
$ ssh firstname.lastname@example.org
Figure 2-1. Our example scenarioOn first contact, SSH establishes a secure channel between the client and the server so 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 the contents of the email you proceed to read using a mail program on 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, "Advanced Client Use" goes into far greater depth about its many features and options.
2.2.1. File Transfer with scpContinuing the story, suppose that while reading your email, you encounter a message with an attached 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 and rcp. 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 print-me. 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 and nearly identical to the insecure rcp program. It is roughly:
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 defaults 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 print-me to the local file print-me, and logs out of shell.isp.com. The local file print-me 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 :$ scp email@example.com:print-me print-me
The full syntax of scp can represent local and remote files in powerful ways, and the program also has numerous command-line options. [Section 7.5, "Secure Copy with scp"]$ scp firstname.lastname@example.org:print-me imprime-moi
Copyright © 2002 O'Reilly & Associates. All rights reserved.