This file is ~avg/.html/ssh-cookbook author: Allen Van Gelder
Because the School of Engineering (soe) is phasing out rlogin and telnet,
and a lot of people have home computers, here is a ``cookbook''
for setting up your soe files needed for ssh.
We are using ssh2, but ssh commands without the ``2'' are linked to
those with the ``2'' as needed, so the ``2'' can be omitted, at least at soe.
All the needed ssh commands are in /usr/local/bin/, which should be
in everyone's path.
This cookbook does not attempt to tell you how to set up your home
computer because that is too wide-ranging a topic.
Neither does this cookbook attempt to cover all of the options and
features. Instead, it presents as FEW choices as possible so you
can just march through it.
If you are satisfied to type your password for every ssh or scp operation
you do, you can probably skip this cookbook. Its goal is to free
you from that requirement in some situations.
All your ssh files will live in ~/.ssh2, i.e., the .ssh2 subdirectory
of your home directory. (Remember to do ``ls -a'' to see file names
beginning with a dot.)
We'll assume you have done nothing yet, and this directory doesn't exist.
1. Start in your home directory. Type ``ssh-keygen''. (Throughout,
you never type the quotes, just what's between them.)
You will be asked for a ``pass-phrase'', which is different from
a ``password''. A pass-phrase can include spaces, and the suggested
length is 12-20 characters. I have never had to use my pass-phrase,
so I'm not sure what it is for; but that's true for a lot of ssh stuff.
ssh-keygen creates the directory .ssh2 if necessary and creates the files
random_seed, id_dsa_1024_a, and id_dsa_1024_a.pub inside .ssh2.
The permissions will be appropriate for these files; don't change them!
2. ``cd .ssh2''.
For all the files you create in steps 2-7 the permissions are
not a security issue. Privacy is up to your taste.
3. Create a file named ``authorization'' with one line. E.g., type
``echo KEY id_dsa_1024_a.pub > authorization''.
Or use your editor and type the line ``KEY id_dsa_1024_a.pub''.
4. Create a file named ``identification'' with one line. E.g., type
``echo IdKey id_dsa_1024_a > identification''.
Or use your editor and type the line ``IdKey id_dsa_1024_a''.
5. ``mkdir knownhosts'', then ``cd knownhosts''.
You want to put files in this directory that contain public keys
of computers outside the soe-maintained domain with which you
want to communicate via ssh. Step 6 will give one example that
serves as a pattern.
For the remaining steps we assume you have a computer known
as ``myc.cse.ucsc.edu''. Being in the cse (or soe) domain means
you can probably abbreviate the name to ``myc'' in many cases.
However, we show the full name in examples so they will work
when myc is in a different domain.
We assume your login name on myc is ``mylogin'' (how imaginative).
6. Assume you want to use ssh with ``myc.cse.ucsc.edu'' and that
you have installed the ssh package on myc.cse.ucsc.edu somehow
(we don't cover that topic here). You need to retrieve the host
public key from myc. If myc is connected to soe through
slip or ppp or something similar, type
``scp -p myc.cse.ucsc.edu:/etc/ssh2/hostkey.pub myc.cse.ucsc.edu.ssh-dss.pub''
Alternatively use ftp or rcp or email to transfer hostkey.pub
verbatim from myc to this directory. On unix systems hostkey.pub
is normally in /etc/ssh2/ but I don't know about PCs and Macs.
You should know where it is if myc is your home computer.
7. Type ``cat myc.cse.ucsc.edu.ssh-dss.pub''. This should print 13
lines on your screen, beginning with
---- BEGIN SSH2 PUBLIC KEY ----
Subject: root
Comment: "1024-bit dsa hostkey"
and ending with ``---- END SSH2 PUBLIC KEY ----''.
The lines between are the actual public key.
Double check that the word ``dsa'' appears in the comment.
If not, then then the file name might be wrong. The alternative name is
``myc.cse.ucsc.edu.ssh-rsa.pub'' but I don't have an example
of how the comment will read in this case. Hopefully it will be
obvious, or the situation will not come up.
8. ``cd'' to your home directory and create the file ``.shosts''.
It should have a line of this form for each computer that you
want to ssh and/or scp FROM without typing your password.
myc.cse.ucsc.edu mylogin
where ``mylogin'' is your login name on myc (NOT necessarily your
soe login). If your .rhosts file is OK, you can do
``cp -p .rhosts .shosts''.
9. ``chmod go-rwx .shosts''. This ensures the permissions are appropriate,
namely -rw-------. .rhosts should have these permissions also, if
it exists.
There are arguments for and against being able to do ssh and scp
without typing a password or pass-phrase. If someone breaks into your
account on myc they will be able to get to your soe account too,
simply by doing ``ssh sundance'' or something like that.
On the other hand, if you repeatedly type your password in a semi-public
place, there is some risk it will be observed by spying.
If you do scp a lot, you will probably get tired of typing a password
each time. (ssh is slow enough already on start-up!)
If you want to learn about ``agents'', I have been told that they allow
you to type your pass-phrase once per ``session'', providing a middle ground.
A few final notes:
If you are on an soe computer and have gone through the above steps,
and you type ``ssh myc.cse.ucsc.edu'' for the first time, you will get
a scary looking message that asks if you want to continue trying to
connect. You need to respond ``yes'', not merely ``y''.
Assuming connection is successful, ssh will create a subdirectory
named hostkeys inside your .ssh2 directory and ssh will create a file
named key_22_myc.pub inside hostkeys.
Thereafter you will not get this question.
Soe maintains a central list of hostkeys and knownhosts for the
computers it maintains, so these computers need not have entries
in your personal files. However, you do need to list them in .shosts
if you want to be able to ssh and scp among them without typing
passwords.
In setting up your home computer, the above steps might provide some
sort of guide, but probably you will be playing system admin and
setting up the global files too.
You can crib the public-key files of soe hosts that you want to
ssh into from /usr/local/share/ssh/{hostkeys,knownhosts}/ but I
wouldn't download the whole directories!
You might want to make a file .ssh2/ssh2_config to personalize some
configurations. There are a zillion options. For example, my
ssh2_config has ``ForwardX11 no'' because I NEVER transmit
anything secret through a remote X window, but I often display images
through remote X windows. I don't want to pay for the encryption
and decryption of a picture, particularly in an animation!
However, many people use remote X windows for all kinds of stuff,
including passwords, and for them it would be a serious burden on their
memory to keep track of which windows are safe and which aren't.
The simple course is to make them all safe. ``X11 forwarding''
means that all traffic related to remote X windows is encrypted,
and is the soe default.