Hello kind readers, and welcome to by *nix Tip of the Day. It's
finals week, and I'm sort of slacking, so I thought I'd post some of my
accumulated folk wisdom on the Internet, so that it might help others.
Today's topic is SSH Private/Public Keys. If any of you are CS majors,
or go to a tech-heavy school, or generally interact with Linux/OS
X/Solaris/HP-UX/AIX/any other *nix, you've probably used SSH. SSH,
at its most basic, is a replacement for telnet and rlogin; it allows you
to get a shell at a remote machine. However, it does so securely (hence,
Secure SHell) using strong encryption. SSH, particularly modern
implementations like OpenSSH also has other subsystems like scp (a
replacement for rcp, which is in turn a remote version of cp),
sftp (a secure replacement for FTP), and such.
Most people, when using SSH, use password authentication. They type
ssh user@host and, when prompted, type in their login
password to host. This isn't necessarily a bad thing — it's
braindead-easy to set up, generally secure, and works the same way as
remote logins have since the beginning of time.
There are some problems with this setup. One of the most obvious is that
if you offer password authentication, your system's security is only as
good as its worst password. Every user that picks "god" or "password" as
his password paints a giant target on your machine.
Enabling password authentication, even if all of your users have strong
passwords, still makes you a target. There are plenty of botnets out
there that connect to servers and try sshing in with random usernames
(and root, of course, but I assume you have root login
disabled/restricted in SSH. You do, right? If not, go do so.). It's
unlikely that they'll ever break a good password, but that's still
traffic hitting your box. Disable password authentication, though, and
they go away. Botnets (thankfully) never try to connect using anything
else.
So, password authentication isn't great. What should you do instead?
Well, it turns out that SSH supports something called public key
authentication. The basic idea here is that the remote user has a small
file called a private key that they keep with them (on their laptop,
or on a flash drive). This key allows them to access the remote server
(optionally without any password at all, although this is discouraged on
a flash key or laptop) more securely. The authentication is done using
either a DSA or RSA with a key-length of between 768 and 2048
bits, which is all technical stuff that you don't care about. Let's talk
about setup.
The first thing to do is to prepare the client system and generate the
key. The following commands should take care of that:
if [ ! -d ~/.ssh ] then
mkdir ~/.ssh
chmod 700 ~/.ssh
ssh-keygen -t rsa -b 2048 -f ~/.ssh/id_rsa
chmod 600 ~/.ssh/*
fi
When you are prompted for a password by ssh-keygen, you should enter
something long that you will not forget. It should not be your account
password. If you really trust the client system (for example, if it's a
desktop machine with no remote login sitting inside a bank vault that
nobody could ever break into), you can leave this field empty. But I do
not recommend it.
But how do you go about using this key? Note that the keygen will have
created a file called ~/.ssh/id_rsa.pub. This is your public key, and
needs to be uploaded to every machine that you need access to. Let's
call the remote machine remote and the local machine local. The
following code should do what you need:
scp ~/.ssh/id_rsa.pub user@remote:~/local.pub
ssh user@remote
if [ ! -d ~/.ssh ] then
mkdir ~/.ssh
chmod 700 ~/.ssh
fi
cat local.pub >> ~/.ssh/authorized_keys
chmod 600 ~/.ssh/authorized_keys
rm local.pub
exit
If all went well, you should now be able to log into remote using your
public key. If you attempt to ssh user@remote, you should be
prompted "Enter passphrase for key '/home/user/.ssh/id_rsa'". Type in
the passphrase you entered during the key creation step and you're all
set.
If typing in this passphrase all of the time seems like a pain in the
rear to you, you're not alone. Check back later for the next article in
the series, on the use of ssh-agent. It's awesome, I tell you.
Note: I am not responsible for any borkage that these commands might
cause. As far as I know, they're correct, but I still disclaim any and
all liability. Yadda yadda yadda.
Updated 2008-05-13 00:55 to use correct permissions for the contents of
~/.ssh
