< Previous | Contents | Next >
Mind that displaying a terminal window from the remote machine is also considered to be a display of an image.
10.4.4. The SSH suite
10.4.4.1. Introduction
Most UNIX and Linux systems now run Secure SHell in order to leave out the security risks that came with telnet. Most Linux systems will run a version of OpenSSH, an Open Source implementation of the SSH protocol, providing secure encrypted communications between untrusted hosts over an untrusted network. In the standard setup X connections are automatically forwarded, but arbitrary TCP/IP ports may also be forwarded using a secure channel.
The ssh client connects and logs into the specified host name. The user must provide his identity to the remote machine as specified in the sshd_config file, which can usually be found in /etc/ssh. The configuration file is rather self-explanatory and by defaults enables most common features. Should you need help, you can find it in the sshd man pages.
When the user's identity has been accepted by the server, the server either executes the given command, or logs into the machine and gives the user a normal shell on the remote machine. All communication with the remote command or shell will be automatically encrypted.
The session terminates when the command or shell on the remote machine exits and all X11 and TCP/IP connections have been closed.
When connecting to a host for the first time, using any of the programs that are included in the SSH collection, you need to establish the authenticity of that host and acknowledge that you want to connect:
lenny ~> ssh blob
The authenticity of host 'blob (10.0.0.1)' can't be established. RSA fingerprint is 18:30:50:46:ac:98:3c:93:1a:56:35:09:8d:97:e3:1d. Are you sure you want to continue connecting (yes/no)? yes
Warning: Permanently added 'blob,192.168.30.2' (RSA) to the list of known hosts.
Last login: Sat Dec 28 13:29:19 2002 from octarine This space for rent.
lenny is in ~
lenny ~> ssh blob
The authenticity of host 'blob (10.0.0.1)' can't be established. RSA fingerprint is 18:30:50:46:ac:98:3c:93:1a:56:35:09:8d:97:e3:1d. Are you sure you want to continue connecting (yes/no)? yes
Warning: Permanently added 'blob,192.168.30.2' (RSA) to the list of known hosts.
Last login: Sat Dec 28 13:29:19 2002 from octarine This space for rent.
lenny is in ~
It is important that you type "yes", in three characters, not just "y". This edits your ~/.ssh/known_hosts
file, see Section 10.4.4.3.
If you just want to check something on a remote machine and then get your prompt back on the local host, you can give the commands that you want to execute remotely as arguments to ssh:
lenny ~> ssh blob who
jenny@blob's password:
root | tty2 | Jul | 24 | 07:19 |
lena | tty3 | Jul | 23 | 22:24 |
lena | 0: | Jul | 25 | 22:03 |
lenny ~> uname -n
magrat.example.com
10.4.4.2. X11 and TCP forwarding
If the X11Forwarding entry is set to yes on the target machine and the user is using X applications, the DISPLAY environment variable is set, the connection to the X11 display is automatically forwarded to the remote side in such a way that any X11 programs started from the shell will go through the encrypted channel, and the connection to the real X server will be made from the local machine. The user should not manually set DISPLAY. Forwarding of X11 connections can be configured on the command line or in the sshd configuration file.
The value for DISPLAY set by ssh will point to the server machine, but with a display number greater than zero. This is normal, and happens because ssh creates a proxy X server on the server machine (that runs the X client application) for forwarding the connections over the encrypted channel.
This is all done automatically, so when you type in the name of a graphical application, it is displayed on your local machine and not on the remote host. We use xclock in the example, since it is a small program which is generally installed and ideal for testing:
Figure 10-3. SSH X11 forwarding
SSH will also automatically set up Xauthority data on the server machine. For this purpose, it will generate a random authorization cookie, store it in Xauthority on the server, and verify that any forwarded connections carry this cookie and replace it by the real cookie when the connection is opened. The real authentication cookie is never sent to the server machine (and no cookies are sent in the plain).
Forwarding of arbitrary TCP/IP connections over the secure channel can be specified either on the command line or in a configuration file.
This procedure assumes that you have a running X server on the client where you want to display the application from the remote host. The client may be of different architecture and operating system than the remote host, as long as it can run an X server, such as Cygwin (which implements an X.org server for MS Windows clients and others) or Exceed, it should be possible to set up a remote connection with any Linux or UNIX machine.
10.4.4.3. Server authentication
The ssh client/server system automatically maintains and checks a database containing identifications for all hosts it has ever been used with. Host keys are stored in $HOME/.ssh/known_hosts in the user's home directory. Additionally, the file /etc/ssh/ssh_known_hosts is automatically checked for known hosts. Any new hosts are automatically added to the user's file. If a host's identification ever changes, ssh warns about this and disables password authentication to prevent a Trojan horse from getting the user's password.
Another purpose of this mechanism is to prevent man-in-the-middle attacks which could otherwise be used to circumvent the encryption. In environments where high security is needed, sshd can even be configured to prevent logins to machines whose host keys have changed or are unknown.
10.4.4.4. Secure remote copying
The SSH suite provides scp as a secure alternative to the rcp command that used to be popular when only rsh
existed. scp uses ssh for data transfer, uses the same authentication and provides the same security as ssh. Unlike rcp, scp will ask for passwords or passphrases if they are needed for authentication:
lenny /var/tmp> scp Schedule.sdc.gz blob:/var/tmp/
lenny@blob's password:
Schedule.sdc.gz 100% |*****************************| 100 KB 00:00
lenny /var/tmp>
lenny /var/tmp> scp Schedule.sdc.gz blob:/var/tmp/
lenny@blob's password:
Schedule.sdc.gz 100% |*****************************| 100 KB 00:00
lenny /var/tmp>
Any file name may contain a host and user specification to indicate that the file is to be copied to/from that host. Copies between two remote hosts are permitted. See the Info pages for more information.
If you would rather use an FTP-like interface, use sftp:
lenny /var/tmp> sftp blob Connecting to blob... lenny@blob's password:
sftp> cd /var/tmp
sftp> get Sch*
Fetching /var/tmp/Schedule.sdc.gz to Schedule.sdc.gz sftp> bye
lenny /var/tmp>
lenny /var/tmp> sftp blob Connecting to blob... lenny@blob's password:
sftp> cd /var/tmp
sftp> get Sch*
Fetching /var/tmp/Schedule.sdc.gz to Schedule.sdc.gz sftp> bye
lenny /var/tmp>
Don't feel comfortable with the command line yet? Try Konqueror's capabilities for secure remote copy, or install Putty.
10.4.4.5. Authentication keys
The ssh-keygen command generates, manages and converts authentication keys for ssh. It can create RSA keys for use by SSH protocol version 1 and RSA or DSA keys for use by SSH protocol version 2.
Normally each user wishing to use SSH with RSA or DSA authentication runs this once to create the authentication key in $HOME/.ssh/identity, id_dsa or id_rsa. Additionally, the system administrator may use this to generate host keys for the system.
Normally this program generates the key and asks for a file in which to store the private key. The public key is stored in a file with the same name but .pub appended. The program also asks for a passphrase. The passphrase may be empty to indicate no passphrase (host keys must have an empty passphrase), or it may be a string of arbitrary length.
There is no way to recover a lost passphrase. If the passphrase is lost or forgotten, a new key must be generated and copied to the corresponding public keys.
We will study SSH keys in the exercises. All information can be found in the man or Info pages.