| Charles Curley - Software Engineer, Writer
| << | < | > | >>
+ Larger Font | - Smaller Font

Charles Curley

Notes on OpenSSH

This article is old, but still very useful for folks setting up SSH on their own. -- C^2

I now use SSH for almost everything across my network. It saved my bacon when my desktop computer's monitor died recently. I am writing this by executing Emacs on the temporarily headless desktop. I am displaying on my laptop, using SSH to tunnel X. I'll have a more detailed write-up once my replacement monitor arrives. If need be I can log into my firewall from a remote log-in to the desktop. That way I do not have to change the firewall to allow direct log-ins from the laptop. If the laptop were ever stolen, that would be a major security breach.

Shortly, I will remove NFS, telnet and other services from my network.

I installed Openssh-2.1.1p1-1 on two of my machines, with the goals of:

Using SSH version 2 to communicate between the two machines.
Being able to use SSH without having to give a password each time I use it.
Forwarding X through SSH.

I did not find the process well documented, and had to seek help on the ssh list. This article is the results of the effort. My thanks to the list members who patiently answered my questions, David Pick, Markus Friedl and Erick Mechler. And my thanks to Joachim Peeck for commenting on earlier versions of this document.

The client, charlesc, is running Mandrake Linux 6.1. The server, named with great imagination server, is running Red Hat 6.2 The file locations are typical Red Hat. And I installed using RPMs. You may have to adjust the notes below for your computer.

Some General Notes

Watch closely when installing Red Hat 7.0, and possibly other distributions. RH 7.0 generates keys on the first reboot after the installation.

The client generates the authentication keys. You must then transport the public key to the server for it to use in authentication. You can transport it any way you see fit, but I would avoid any open network connection. Sneakernet backed by meatware authentication is far and away the most secure way to do it.

I have also transported a public key to a sever by first logging in on SSH using password authentication, and then scping it over. That works, but meatware authentication seems to me to be inherently more secure.

Authentication key generation and authorization are done on the basis of each user on each machine. That is, foo@bar is considered to be different from foo@baz, and also different from snark@bar.

You can always generate a key pair for one user/machine and then copy it to another user/machine. I see no advantage to doing so, and my paranoia says this is not a good idea.

The other sort of key that is used is a session key, used to encrypt the traffic. This is generated once for each session. That key is handled by the software transparently.

You can configure the client in two places. Global configuration for the machine is done at /etc/ssh/ssh_config. Each user can modify his/her/its configuration at ~/.ssh/config.

In /etc/ssh/ssh_config, the order of the stanzas is important. Put host-specific or network-specific configurations first, then your general stuff. For example,

Host server
        ForwardAgent yes
        ForwardX11 yes
        Protocol 2,1
        PasswordAuthentication yes



# Be paranoid by default

Host *
        ForwardAgent no
        ForwardX11 no
        FallBackToRsh no

This sets up the client so that (server configuration permitting) the server will forward X to the client. But, with the global stanza, no other server will be allowed to forward X to my client.

Selecting an SSH Version

SSH version 2 is more secure and robust than SSH Version 1. So I would prefer to use it. Fortunately, most ssh clients that support SSH Version 2 now also support Version 1. The Open SSH client can be set to try Version 2, and if that fails, then to try Version 1.

To set up my client to do that, I created the file ~/.ssh/config and entered the following:

Protocol 2,1

If the server is set up to use both versions, the client and server will negotiate and agree to use Version 2. (Is this correct?)

SSH Version 1 Key Pairs

Open SSH for SSH version 1 uses a key pair generated for Version 1. The private key is stored in ~/.ssh/identity, and the public in ~/.ssh/identity.pub. To generate a key pair, run ssh-keygen on the client computer with no arguments.

Copy identity.pub to the server (making sure to rename it in the process so you don't overwrite the existing identity.pub), and append it to the server's ~/.ssh/authorized_keys. In the server's ~/.ssh directory, run:

cat user.host.identity.pub >> authorized_keys
rm user.host.identity.pub

Or edit it in with any text editor.

Remember to do this for each account you want the client to be able to log into.

SSH Version 2 Key Pairs

To set things up for Version 2, you do exactly the same steps, but the commands and file names are different. On the client, generate the key pair with the command:

ssh-keygen -d

This produces two files, ~/.ssh/id_dsa for the private key, and ~/.ssh/id_dsa.pub for the public key. Copy the public key to the server and append it to the file ~/.ssh/authorized_keys2. (Note the trailing 2!)

cat user.host.id_dsa.pub >> authorized_keys2
rm user.host.id_dsa.pub

If you want to use Version 2 SSH only, you can transport the Version 2 public key to the server, and ignore the Version 1 public key.

Other Things To Do

Then edit the server's /etc/ssh/sshd_config:

RSAAuthentication yes

On the server, make sure the authorized_key file(s) have the requisite permissions:

chmod 644 ~/.ssh/authorized_keys*

and

chmod 700 ~/.ssh

Here is what my client's .ssh directory looks like (as of April, 2003, to show what a more modern installation looks like):

drwx------    2 phred    phred        4096 Dec 12 12:04 .
drwx--x--x   61 phred    phred        4096 Apr  9 14:04 ..
-rw-r--r--    1 phred    phred         616 Nov 26  2001 authorized_keys2
-rw-r--r--    1 phred    phred         117 Nov 26  2001 config
-rw-r--r--    1 phred    phred          13 Nov 26  2001 config~
-rw-r--r--    1 phred    phred         668 Nov 26  2001 id_dsa
-rw-r--r--    1 phred    phred         616 Nov 26  2001 id_dsa.pub
-rw-r--r--    1 phred    phred        2687 Apr  3 13:06 known_hosts
-rw-r--r--    1 phred    phred        1891 Nov  3  2001 known_hosts2

You may also have to adjust permissions on the client:

chmod 600 /etc/ssh/*

This is what my server's /etc/ssh directory looks like (as of April, 2003, to show what a more modern installation looks like):

drwxr-xr-x    2 root     root         4096 Jan 21 12:19 .
drwxr-xr-x   67 root     root         8192 Apr  6 16:28 ..
-rw-------    1 root     root        88039 Mar  7  2002 moduli
-rw-------    1 root     root         1515 Jan 21 12:19 ssh_config
-rw-------    1 root     root         1515 Dec 14 18:48 ssh_config~
-rw-------    1 root     root         1360 Mar 12  2002 sshd_config
-rw-------    1 root     root         1360 Aug 11  2001 sshd_config~
-rw-------    1 root     root          668 Nov 18  2000 ssh_host_dsa_key
-rw-------    1 root     root          603 Nov 18  2000 ssh_host_dsa_key.pub
-rw-------    1 root     root          528 Nov 18  2000 ssh_host_key
-rw-------    1 root     root          332 Nov 18  2000 ssh_host_key.pub
-rw-------    1 root     root          883 Jul  4  2001 ssh_host_rsa_key
-rw-------    1 root     root          210 Jul  4  2001 ssh_host_rsa_key.pub

Note that while I only have my server set up for SSH version 2, the client is ready for SSH Version 1 as well. That is because I have a customer who uses SSH Version 1, so I still keep those client side files around.

Ah, I hear some bright person in the back of the room muttering, what are those ~/known_hosts* files? The answer is, they are a record of hosts known to the client to be acceptable to log into, one for each SSH version. Want to know if one of your employees has been using SSH to log into some computer or other?

cat known_hosts* | grep -i <hostname> ; cat known_hosts* | grep -i <IP address>

X Forwarding

X forwarding is the process of going to a computer via SSH and launching X clients on it to use your display as their X server. For example, I may log into my server over SSH, and then run, say, emacs or something really important like xpat2. The X display will show up on my client computer. It better not show up on the server because that doesn't even have an X server on it! So far, I am describing standard X behavior. Forwarding the X data through SSH simply means that it is encrypted, and quite likely compressed.

One thing I had to do to get that working correctly was to make sure that none of my startup scripts was setting the DISPLAY environment variable. I had to find and comment out this:

export DISPLAY=`hostname`:0.0

You can force X forwarding with the -X command line option. On the client, run:

ssh -X server emacs

and emacs will pop up on your screen.

However, to automate it, do two things. On the client's side, you need to add to one of the two config files:

        ForwardAgent yes
        ForwardX11 yes

On the server side, in /etc/ssh/sshd_config (note the d in the file name):

X11Forwarding yes

Normally the X11DisplayOffset value is 10, and you should be able to leave it there. If you log in to a system on its physical console, via telnet or rlogin, the DISPLAY value should be something like:

server:0.0

But setting the X11DisplayOffset value to ten bumps the DISPLAY value up ten:

server:10.0

Everything works the same way, and your X display still shows up on the client's X server as it should. The advantage to leaving this at ten is that it allows the native X server to remain at server:0.0. Perhaps other servers like VNC are also active.

Backing up over SSH

To back up to another computer over SSH:

To compress on the machine originating the backup:

root@charlesc # tar -cf - directory.to.be.tarred | bzip2 | ssh server "cat > test.tar.bz2"

To compress on the target:

root@charlesc # tar -cf - directory.to.be.tarred | ssh server "bzip2 > test.tar.bz2"

where server is the name of the target computer.

Normally I would compress on the originating machine, to minimize traffic over the net, usually a consideration. However, if the originating machine is an older, slower machine, it may be faster to compress on the target. Also, zlib compression (used by both gzip and SSH) is much less CPU intensive than bzip2 compression.

Other Advice

David Pick writes: "By the way, to protect my desktop machine, my "Xservers" file has the parameter "-nolisten tcp" appended to the line starting the local server. This stops it listening for TCP connections on port 6000 from anywhere (either local processes or remote ones) and it only talks using the "unix domain" socket usually named ":0.0". SSH forwards this like any other X connection and it all works with less chance of a security hole allowing unauthorized connections to the X display server process."

Other SSH web pages

I have not necessarily used any of the advice in these web pages, so you are on your own.

A good general write-up on SSH
How do I do port-forwarding with ssh?
Top Ten Secure Shell FAQs, from Richard Silverman, coauthor of .
I'll bet you never expected to use SSH to solve hardware problems. "So Your Monitor Died".