UCLA-Math/PIC uses OpenSSH v3.9p1 on Linux (currently) and OpenSSH v3.2.3p1 on Solaris. Here's a brief overview of how to get started using SSH. You should also review the man page for ssh, though it's not as warm and fuzzy as this document :-)
What you get from SSH: Data transmitted over the encrypted connection is essentially invulnerable to prying eyes. This means that when you give your password to the remote system, various lowlife who snoop your packets will not be able to steal it. You can then get a remote shell session (command line), and you can forward X-Windows and other ports over the encrypted channel.
Essentially invulnerable
means that it's comonly believed that if
they were really, really motivated, the National Security Agency could crack a
SSH session key within a year, if they didn't do any other cryptographic
cracking during that time, devoting all resources to you. This would
give them access to up to an hour of one of your sessions, provided all packets
were recorded. The exact number of CPUs, hours and dollars required is hard
to estimate, but is outrageously in excess of any credible threat to you.
Mathnet would like all passwords, or other sensitive data such as student records, to be sent from off-campus over an encrypted channel. It is reasonable and not burdensome to the computers if communications within Mathnet are also encrypted. In other words, you can set up and learn one set of procedures which you use both at home and at work.
You can install
the software and use it just like Windows Terminal or UNIX Telnet, giving
your password each time you connect, and most users will choose this mode
of operation. However, power users
will want to set up the single
sign-on
paradigm of SSH, in which you unlock your secret key once, and
all remote systems can then be assured that you are really you, without
further password entry.
To set up SSH on UNIX/Linux: This is the simplest case to describe. The examples are phrased assuming you are originating the SSH connection from a home Linux box into Mathnet.
First determine a pass phrase for your secret key. Anyone who can guess
this phrase can log in to your remote accounts, so choose a good one. Mathnet
recommends at least 64 bits of entropy, which requires 11 truly random bytes
chosen from upper and lower case letters, digits and punctuation; or 22 bytes
of running text. But use only obscure texts; hackers use Bartlett's
Familiar Quotations
, for example, to crack pass phrases. See Mathnet's
password policy document for some more guidelines for passwords and
phrases. In a national security context you would be expected to have a
separate pass phrase for each purpose, but at the threat level expected in the
Math Department it's considered acceptable if you use your UNIX password,
provided that it has sufficient entropy and follows the guessability
guidelines. And if it doesn't, you should fix it.
On the UNIX system from which you will be originating connections, create a secret and public key pair using this command:
mkdir $HOME/.ssh #if you don't have this directory already
ssh-keygen -t rsa -b 1024 -f $HOME/.ssh/id_rsa
-t rsa
selects a key for the RSA verification algorithm; Mathnet can
also do DSA keys. -b 1024
specifies the number of bits in the key.
If you're really paranoid you could use a 2048-bit key (please not on Solaris
for which it would be too slow). -f filename
tells where to put the
keys (the public key gets .pub appended). If you have several keys, you can
use a more descriptive filename. You will be asked to type in the
passphrase, twice.
The keys will be created with the correct modes, but for reference, the secret key should be owned by and readable only by you, and the public key may be given to and read by the general public.
(Likely you will want to originate connections from both home and work,
and therefore you will want to use the scp
command to copy your secret
and public key to the other end, using the encrypted channel. Mind the file
permissions: secret key readable only by you. You
are also permitted to have separate keys at each origin system.)
Now you need to run the ssh-agent process, which keeps your secret key
in memory for use in making connections, and the ssh-add program, which
decrypts your secret key (using the passphrase) and sends it to ssh-agent. On
Linux, Mathnet's X-Windows startup scripts will automatically start and load
the agent if you have any SSH keys [note: tested for fvwm; supposed to work for
kde also]. The startup script also automatically and reliably gets rid of your
agent when you log out (so hackers can't borrow
it while your back is
turned). Some distros such as SuSE 9.3 also automatically start the ssh-agent
when you log in. So if you're on a Linux workstation at Mathnet, or if your
distro has the feature, your simplest procedure is to log out and log in again,
giving your passphrase to the ssh-add dialog box that will appear. If you use
your own custom .xsession, read the man pages for these two programs and review
Mathnet's /etc/X11/xdm/sys.xsession for usage hints.
At Mathnet, your secret key is in your UNIX home directory, which is made available to Mathnet hosts (only) including your Linux workstation by NFS. This is not an encrypted protocol, meaning that hackers who perpetrate certain classes of exploits can steal your secret key. However, the key is encrypted with your passphrase. Assuming the hacker cannot guess the passphrase, the key is useless to him.
Copy your public key to the destination system, calling it by some other
name not ending in .pub
. (For Mathnet to Mathnet encrypted
communication it's already on the destination system; omit copying.) Append
the public key to the file $HOME/.ssh/authorized_keys. Or if you don't have
that file already, just copy the public key. The authorized_keys file should
have mode 600, i.e. readable only by you. the public key is one very long line
of text, so this command can be used to automate the appending procedure:
cd .ssh
cat pubkey.fromhome >> authorized_keys
Now you should be able to originate a SSH connection from the origin system, and the destination system will believe in your identity and let you on without a password. Here is a summary of commands to try, executing on the origin system (e.g. home):
Destinationrepresents the host you want to log in to, e.g. tupelo.math.ucla.edu.
-X(upper case) says to forward the X-Windows port. Xlogo is a simple demo so you can see that it works. Control-C to kill it. You can run more productive programs such as Matlab. However, X-Windows over DSL is very sluggish, and over a dialup line it's impossible. It would be better to
sloginand run the text version of Matlab.
cpuses. To expand a glob pattern on the remote host, quote it.
power usersonly.
-Apropagates your ssh-agent to the destination host, and you will be able to originate connections from there, where each system trusts the previous one in catenative assemblage. But this exposes your agent to hackers on the intermediate system(s). It's better to originate the connection from your own origin system. But for Mathematics Computing Group programmers, certain system administration tasks have to be done in this way from the master site (Sunset), which is specially secure.