Skip over navigation

The Lost continent of

You've found a bug on my site!

Computer Science is no more about computers than astronomy is about telescopes.

E.W. Dijkstra

SSH... Secret Squirrel!

Safe, Secure, Happy Remote shells

The only thing better than being at the command prompt of a system, is being at the command prompt of a bunch of systems!

Who, what, why?

Who?

The good folks of the OpenSSH project.

What?

SSH is a drop in, secure, replacement for Telnet — and much besides. With it, I can sit at my home PC, copy files securely to my company's webserver at the other side of town, login to it, and start checking out log-files, etc...

Why?

SSH provides two things: The ability to communicate and control computers from anywhere on the Internet, and the security to ensure that you're the only one who can. Why? Because that's incredibly useful, and the old remote tools where serious security risks.

Example

If my web server's name were www.yahoo.com, then to log in to that system I'd type: 

~$ ssh www.yahoo.com
leon@www.yahoo.com's password: xxxxxxx
Last login: Sun Oct  6 21:00:01 2002 from 192.168.0.147
$ su -
Password: xxxxxxxx
/home/leon #

I'm now logged in as root on the webserver!

For this to work, you must know the account and password (obviously!), and SSH must be running in server mode on the remote system. It's dead easy to setup — often it just a matter of enabling it. Almost every Linux and BSD system has it pre-installed, as does Mac OS X.

Public key Cryptography — Stop typing passwords!

I use SSH to login to the nodes of my Beowulf system, and to start programs on those nodes. It would be more than just a pain to have to type passwords for every node every time I wanted to run a single parallel program! Fortunately SSH supports a number of alternate authentication schemes.

What is this 'Public Key' of which you speak?

If you have ever used PGP (or it's more modern incarnation, GnuPG) to encode your email, or files, you will be familiar with Public key cryptographic systems.

How public and private keys are used

To over-simplify, instead of using the same password (or key) to both encode and decode a message, one key encodes the message, and another decodes it. You keep the key that decodes messages safe (your 'private key'), but let everybody use the other key that encodes messages:

Login without a password

To login to a remote system without needing to type your password every time you need to do the following.

  1. Generate, on your machine, a public/private key pair for your local account. 
    $ ssh-keygen -t dsa
    This creates two key files in my home directory, in the folder .ssh/:
    The public key: id_dsa.pub and private key id_dsa.

  2. Copy your public key to the file $HOME/.ssh/authorised_keys on the remote server. There are a number of ways to do this. If your distribution supports it, the ssh-copy-id script is the easiest: 
    ssh-copy-id -i id_dsa.pub www.yahoo.com

Next time, I can run programs, or log on without having to type my password explicitly. I must, of course, keep my private key file safe. Let's test it on my local network: 

head:/home/leonov$ ssh node01 date
Sun Oct  6 21:52:57 NZDT 2002
head:/home/leonov$ scp node01:/home/leonov/test.jpg /tmp
test.jpg   100% |*******************| 98304   00:01
head:/home/leonov$ ls
test.jpg
head:/home/leonov$ ssh node01
node01:~ $

Look ma! No passwords!

The first command started SSH, authenticated you using your DSA public/private key pair, ran the date command on the computer 'node01', and displayed the result on my local terminal. The second copied a test file from 'node01' to the local system 'head' using scp the SSH file copy utility - see man scp (1). Finally we actually logged onto node01.

Tip for experts - Symlink invocation of SSH.

Older versions of SSH used an old UNIX trick whereby the name that the command was invoked under was used as the host name of the remote system. Using the example above, I could have just typed node01 date instead of ssh node01 date, if I had setup a symlink to the ssh executable called node01.

A small thing, but convenient. This feature has been deliberately removed, presumably for security reasons. A nice way to get that functionality back, without patching the ssh program is to write a script and point your symlinks to that. The code below is a slightly modified version of a shell script that I found on a mailing list somewhere 

#! /bin/sh -e
# --------------------------------------------------------
# ssh-argv0
# --------------------------------------------------------
# This script can be used to conveniently invoke SSH using
# just the name of the target system, eg, running:
# webserver w
# can quickly check how overloaded your server is.
# --------------------------------------------------------
if [ "${0##*/}" == "ssh-argv0" ]
then
  echo 'This script should be called from a symlink' 1>&2;
  exit 1;
fi
ssh "${0##*/}" "$@"

I've created a link to this script for each of the nodes on my Beowulf, node01 through nodexx. After all this setting up I can now run a commands on any machine with ease. For example, I can see what the time is set for on the head, and the first three nodes: 

head:/etc# date; node01 date; node02 date; node03 date
Sun Oct  6 22:11:33 NZDT 2002
Sun Oct  6 22:11:31 NZDT 2002
Sun Oct  6 22:11:31 NZDT 2002
Sun Oct  6 22:11:35 NZDT 2002
head:/etc#

Well... Pretty close, but no cigar Maybe I should run an NTP service on the head node?

Anyway, that's the wonderful world of SSH for today. I hope you find it as useful as I do...