Secure Shell HowTo
1. Introduction
2. User installation
3. Using SSH
4. Sources of more Information

1. Introduction

This section should answer general questions about SSH and what it does and doesn't do.

1.1 What is ssh?

Secure Shell (SSH) is a program to log into another computer over a network, to execute commands in a remote machine, and to move files from one machine to another. It provides strong authentication and secure communications over unsecure channels. It is intended as a replacement for telnet, rlogin, rsh and rcp.

Additionally, SSH provides secure X connections and secure forwarding of arbitrary TCP connections.

1.2 Why should I use it?

The traditional BSD "r"-commmands (rsh, rlogin, rcp) are vulnerable to different kinds of attacks. Somebody who has root access to machines on the network, or physical access to the wire, can gain unauthorized access to systems in a variety of ways. It is also possible for such a person to log all the traffic to and from your system, including passwords (which ssh never sends in the clear).

The X Window System also has a number of severe vulnerabilities. With SSH, you can create secure remote X sessions which are transparent to the user. As a side effect, using remote X clients with SSH is more convenient for users.

Users can continue to use old .rhosts and /etc/hosts.equiv files; changing over to SSH is mostly transparent for them. If a remote site does not support SSH, a fallback mechanism to rsh is included.

SSH protects against:

  • IP spoofing, where a remote host sends out packets which pretend to come from another, trusted host. SSH even protects against a spoofer on the local network, who can pretend he is your router to the outside.
  • IP source routing, where a host can pretend that an IP packet comes from another, trusted host.
  • DNS spoofing, where an attacker forges name server records.
  • Interception of cleartext passwords and other data by intermediate hosts.
  • Manipulation of data by people in control of intermediate hosts attacks based on listening to X authentication data and spoofed connection to the X11 server.

In other words, SSH never trusts the net; somebody hostile who has taken over the network can only force SSH to disconnect, but cannot decrypt or play back the traffic, or hijack the connection.

2. User installation

The following sections are a short form of the document Getting started with SSH from Kimmo Suominen.

2.1 Creating your authentication key

The very first step is to use ssh-keygen to create an authentication key for yourself. In most cases the defaults for this command are what you want. SSH needs this pass-phrase to save your personal authentication key in an encrypted format.

Always, always, type in a good pass-phrase when prompted for one. It can be multiple words (i.e. spaces are just fine within the phrase), so you could choose a sentence that you can remember. Changing some of the words by misspelling them or by changing some of the letters into digits is highly recommended to increase the strength of your pass phrase.

Here is a sample session, your input is in bold. Note that the pass-phrase is not echoed back as you type it.

zo1-c705$ ssh-keygen -t rsa
Generating public/private rsa key pair.
Enter file in which to save the key (/u/kim/.ssh/id_rsa): [RETURN]
Enter passphrase (empty for no passphrase): litt1e 1amp jumb3d
Enter same passphrase again: litt1e 1amp jumb3d
Your identification has been saved in /u/kim/.ssh/id_rsa.
Your public key has been saved in /u/kim/guest4/.ssh/id_rsa.pub.
The key fingerprint is:
b0:24:32:35:7d:1b:f0:11:42:8b:a3:f6:5a:9e:49:aa kim@zo1-c705.uibk.ac.at

2.2 Changing your pass-phrase

You can change the pass-phrase at any time by using the -p option of ssh-keygen:

zo1-c705$ ssh-keygen -p
Enter file in which the key is (/u/kim/.ssh/id_rsa): [RETURN]
Enter old passphrase: litt1e 1amp jumb3d
Key has comment '/u/kim/.ssh/id_rsa'
Enter new passphrase (empty for no passphrase): br0wn cow 3ats grass
Enter same passphrase again: br0wn cow 3ats grass
Your identification has been saved with the new passphrase.

The pass-phrases are not echoed as you type them.

2.3 Authorizing access

To allow access to a system for a given identity place the public key in your ~/.ssh/authorized_keys file on that system. All keys listed in that file are allowed access.

Usually you will want to authorize access to the local system using the local key (especially in an environment where multiple systems share the same home directory e.g. using NFS). Thus a good start is to copy the public key for your default identity into the ~/.ssh/authorized_keys file.

zo1-c705$ cd ~/.ssh
zo1-c705$ cp id_rsa.pub authorized_keys

Use a text editor to add more keys to the file. If you use cut and paste to copy the key make sure each key entry is a single line in the file. The keys to add are always the public keys (from files with the .pub extension).

2.4 Directory and file permissions

If access to the remote system is still denied you should check the permissions of the following files on it:

  • the home directory itself
  • the ~/.ssh directory
  • the ~/.ssh/authorized_keys file

If you want to log into a remote system wihtout typing your pass-phrase or password, check also the .shosts file in your home-directory.

The permissions should allow writing only by you (the owner). This example shows the most relaxed permissions you could use.

zo1-c705$ cd
zo1-c705$ ls -ld . .ssh .ssh/authorized_keys .shosts
drwxr-xr-x 36 kim kim 4096 Jul 25 02:24 .
-rw-r--r-- 1 kim kim 54 Apr 10 02:29 .shosts
drwxr-xr-x 2 kim kim 512 Apr 10 02:30 .ssh
-rw-r--r-- 1 kim kim 1674 Apr 10 02:29 .ssh/authorized_keys

To make the remote system allow access you must change the permissions to disallow writing by others than the owner.

zo1-c705$ cd
zo1-c705$ chmod go-w . .ssh .ssh/authorized_keys .shosts

The .shosts file should look like:

zo1-c705.uibk.ac.at
pz-c705.uibk.ac.at
138.232.67.50

Remember to do this on all the systems you want to have access to.

3. Using SSH

3.1 Logging into remote systems

To establish an interactive connection to a remote system you would use either the slogin or the ssh command. The only parameter is the name of the remote system. The pass-phrase is not echoed back to you when you type it.

zo1-c705$ slogin pz-c705
Enter passphrase for RSA key '/u/kim/.ssh/id_rsa': litt1e 1amp jumb3d
Last login: Wed Oct 16 20:37:00 1999 from zo1-c705.uibk.ac.at
[more output from the remote machine]
pz-c705$

If your account name on the remote system differs from the one on the local system (the system you are connecting from) you can use the -l switch to specify the remote account name.

zo1-c705$ slogin -l suominen panix.com
Last login: Sun Oct 13 14:55:17 1996 from idefix.gw.com
[more output from the remote machine]
panix$

3.2 Logging without typing the pass-phrase

You can avoid the pass-phrase prompts by

  • typing in a RETURN when the pass-phrase prompt appears. SSH asks you now for your personal password:

    zo1-c705$ ssh pz-c705
    Enter passphrase for RSA key 'kim@pz-c705.uibk.ac.at': [RETURN]
    Bad passphrase.
    kim@pz-c705's password: xxxxxxx
    Last login: Wed Oct 16 20:37:00 1999 from ito
    [more output from the remote machine]
    pz-c705$

  • creating a .shosts file in your home-directory (see Directory and file permissions for details).
  • keeping the authentication keys in memory. You only need to type the pass-phrase when you add a key into memory (see Getting started with SSH for further explanation).

3.3 Running commands on remote systems

The ssh command can also be used to run commands on remote systems without logging in. The output of the command is displayed and control returns to the local system. Here is an example which will display all the users logged in on the remote system

zo1-c705$ ssh pz-c705 who
kim tty1 Oct 27 08:56
kim ttyp4 Oct 27 10:05 (:0.0)
kim ttyp1 Oct 27 13:30 (:0.0)

If you are using the X Window System you can use this capability to start a terminal window to start an interactive session on the remote system:

zo1-c705$ ssh -n pz-c705 xterm &
[1] 25264

Use the -n to prevent the remote system from trying to read from the terminal starting the xterm and put the process in the background. A new window from the remote system should appear shortly on your display.

Remark: It is not necessary to set the DISPLAY environment variable when you use SSH. But you may have to allow the remote host to open a X-window on your system (using "xhost +hostname").

3.4 Copying files between systems

You can copy files from the local system to a remote system or vice versa, or even between two remote systems using the scp command. To specify a file on a remote system simply prefix it with the name of the remote host followed by a colon.

If you leave off the filename of the copy or specify a directory only the name of the source file will be used. An easy way of retrieving a copy of a remote file into the current directory while keeping the name of the source file is to use a single dot as the destination.

zo1-c705$ scp -p pz-c705:aliases .
zo1-c705$

The -p option is not required. It indicates that the modification and access times as well as modes of the source file should be preserved on the copy. This is usually desirable.

You can copy several files in a single command if the destination is a directory.

zo1-c705$ scp -p hrothgar:.login hrothgar:.logout panix.com:.
zo1-c705$

Relative filenames resolve differently on the local system than on the remote system. On the local system the current directory is assumed (as usual with all commands). On the remote system the command runs in the home directory! Thus relative filenames will be relative to the home directory of the remote account.

NOTE: When you specify remote machines in both the source and the destination the connection to copy the files is made directly between those hosts. The files are not copied through the local system. Sometimes this makes a difference in a firewalled or otherwise restricted environment.

4. Sources of more Information

Nach oben scrollen