I would appreciate comments n this writeup. I'm not sure what to do with
it. Perhaps Anne can use portions of it in the FAQ. Maybe I'll do a longer
article on SSH for Linux Journal.
Draft Notes on OpenSSH
Charles Curley
Time-stamp: <2000-11-03 09:24:23 ccurley>
I recently installed Openssh-2.1.1p1-1 on two of my machines, with the
goal of:
1) Using SSH version 2 to communicate between the two machines.
2) Being able to use SSH without having to give a password each time I
used it.
3) Forwarding X through SSH.
I did not find the process well documented, and had to seek help on the
ssh list ([EMAIL PROTECTED]). 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.
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
The client generates the encryption keys. The public key must then be
transported to the server for 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.
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.
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 authorized_keys*
This is what my server's /etc/ssh directory looks like:
drwxr-xr-- 2 root root 1024 Oct 30 10:50 .
drwxr-x--- 7 root root 1024 Oct 30 10:47 ..
-rw-r--r-- 1 root root 603 Oct 30 10:20 authorized_keys2
You may also have to adjust permissions on the client:
chmod 600 *
Here is what my client's .ssh directory looks like:
total 12
drwxr-xr-- 2 root root 1024 Oct 30 10:56 .
drwxr-x--- 32 root root 4096 Nov 1 10:41 ..
-rw------- 1 root root 13 Oct 27 08:03 config
-rw------- 1 root root 668 Oct 29 12:40 id_dsa
-rw------- 1 root root 603 Oct 29 12:40 id_dsa.pub
-rw------- 1 root root 528 Oct 27 08:21 identity
-rw------- 1 root root 332 Oct 27 08:21 identity.pub
-rw------- 1 root root 669 Oct 28 21:00 known_hosts
-rw------- 1 root root 609 Oct 27 08:04 known_hosts2
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.
BTW, 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."
I have not done this, but it is probably a good idea if your entire local
network uses SSH.
--
-- C^2
No windows were crashed in the making of this email.
Looking for fine software and/or web pages?
http://w3.trib.com/~ccurley
PGP signature
