The Extremely Busy Person's Guide to Secure Shell (SSH)

Secure shell (ssh) was developed to protect communications between hosts on a network from various forms of spoofing, eavesdropping and other attacks.  It is installed on all of the Mobile Agent groups machines and is the recommended means of remote login between machines.  The goal of this guide is to assist you in configuring and using ssh and it's related utilities.

This guide is intended a quick reference.  For more information, see the man pages.
 

Table of Contents

1. Basic Operation
1. Login
2. Copy
3. FTP
2. Advanced Operation
1. Password-less Login
2. Securing Other Services

Basic Operations

A typical ssh login goes something like this:

1004$ ssh agentm
Accepting host agentm key without checking.
arne's password: <fatchance>
Last login: Mon Jul 24 2000 12:00:30 -0400
                                     This message comes from /etc/motd

What it is!

Remember to remount NFS volumes after rebooting a machine!

No mail.
1001$

Here we have used ssh to login to agentm.  What has happened under the hood is:

1.  agentm's host public key has been sent to you,
2.  the host's identity has been verified using an encyphered challenge,
3.  your userid's public key has been looked up and not found,
4.  you've been asked for your Unix password and been authenticated,
5.  forwarding for your X Window session has been setup, and finally
6.  your shell has been started and you're given a command prompt.

To login

• as yourself to a host: ssh <host name or IP address>
• as another user: ssh -l <other user> <host name or IP address>

• a file as yourself: scp /path/filename <host name>:/path/filename
• a directory: scp -r /path/dirname <host name>:/path
• as someone else: scp /path/filename <other user>@<host name>:/path/filename

• use: sftp <host name> <user>

Advanced Operations

Password-less Login

First, we need to generate a public key pair.  This is done using the ssh-keygen program and goes something like this:

1033$ ssh-keygen
Generating 1024-bit dsa key pair
   4 .oOo.oOo.oOo
Key generated.
1024-bit dsa, arne@smersh.cs.dartmouth.edu, Fri Aug 18 2000 14:05:11 -0400
Passphrase : <fatchance>
Again      : <fatchance>
Private key saved to /home/arne/.ssh2/id_dsa_1024_c
Public key saved to /home/arne/.ssh2/id_dsa_1024_c.pub
1034$

By default, a Digital Signature Algorithm (DSA) public key cypher pair using a key length of 1024 bits was generated for you.  When prompted, you entered a passphrase, some text that only you know, which is used when decrypting authentication challenges.  The resulting private and public keys are generated and stored in the files listed.  In this case, the default naming scheme was used which tells us that the DSA was used with a 1024-bit key.  The _c indicates that it is the 3rd key pair we've generated.

Now that we have a key pair, we need to tell ssh about them.  In our configuration, sshd will search for public keys using two files:  authorization and identification.  The authorization file lists all the public keys known and looks like this:

1034$ more authorization
Key id_dsa_1024_a.pub
1035$

Each public key on the host must have an entry in the file.  On each host we wish to use password-less entry, we must copy the .pub file to that machine and add the corresponding line to the .ssh2/authorization file on that machine.

The identification file lists all of the private keys we know.  It looks like:

1035$ more identification
IdKey   id_dsa_1024_a
IdKey   id_dsa_1024_b
1036$

In this case, we've got two private keys listed.  We can use different key pairs with different sets of machines.  This way, if our passphrase gets compromised, the intruder can only have easy access to some of the machines we use and not all of them.

When we try ssh now, we get the following:

1041$ ssh agent1
Passphrase for key "/home/arne/.ssh2/id_dsa_1024_a" with comment "1024-bit dsa,
 arne@smersh.cs.dartmouth.edu, Thu Aug 17 2000 15:12:34 -0400": <fatchance>
Last login: Fri Aug 18 2000 14:27:46 -0400

What it is!

No mail.
1001$

Not exactly password-less!  In order to decrypt the challenge, we need the passphrase for the key pair, but we don't want to be typing it all the time.  There are two ways to address this problem.  The first and less secure way is to generate the key pair without a passphrase.  You can do this by using:

ssh-keygen -P

The second way is to use an agent.  To use an agent, simply add to your profile/.cshrc the following:

eval `ssh-agent2` if you use sh or bash or

eval `ssh-agent2 -c` if you use csh or tcsh

This command will set some environment variable and start the agent.  Once the agent is started and you have a command prompt, enter the command:

1001$ ssh-add <private key filename>

ssh-add will prompt you for the passphrase corresponding to each private key filename on the command line. This way, you only have to type your passphrases once per login session.  After all of this, you no longer need to type passwords as you ssh/scp/sftp between machines.

 Return to Table of Contents
 

Securing Other Services using SSH

You will need two windows on the desktop.  In the first window, type:

ssh -L <port number>:<target host>:<service port> <ssh server>

This command tells ssh to forward the connection on <port number> to <service port> on <target host> using <ssh server> as the intermediary.
So, if you wanted to ftp, you would type in the second window:

ftp -p localhost <port number>

You will then see the normal ftp login prompt, but it will be from the <target host> in the ssh command above.  For ftp, you must use passive mode (the -p option) otherwise, the ftp server will reject any transfer requests.

*** The ftp server on Mayday does not require passive mode and will accept third party transfers. ***

*** Currently our ftp servers won't accept third party (ie. smersh -> agent -> mayday) because they can't set passive mode correctly.  For the time being, you'll have to use your local machine as the <ssh server>. ***

 Return to Table of Contents