By Bri Hatch.
Summary: How to create passwordless logins to allow remote administration tasks securely with SSH - setting up your SSH identities.
Setting up your accounts to allow identity-based authentication gives you several new options to allow passwordless access to those accounts. The end goal is to allow passwordless access that can only run specific commands, rather than full fettered login ability, but we'll start with the more general solution as our first step.
To enable identity-based authentication, you must first create an SSH identity. An SSH identity is simply a private/public key pair, which are similar in functionality to to PGP keys, or SSL keys and SSL certificates. You place a copy of the identity public key into the file $HOME/.ssh/authorized_keys on any account you wish to enable access using this key. You keep the private key on the SSH client machine - your laptop, personal workstation, etc. When you connect from your client, the ssh program will offer to use identity-based authentication for each key it has available. If the server sees the public key in $HOME/.ssh/authorized_keys, it tells the SSH client to prove that it has the private key and if the client can meet the challenge, the access is granted.
For the remainder of these articles, I'll assume you are using a recent version of OpenSSH, 3.4p1 or better. So, let's make a test key:
$ cd $HOME $ mkdir identity-test $ cd identity-test $ ssh-keygen -f id_rsa -t rsa Generating public/private rsa key pair. Enter passphrase (empty for no passphrase): <enter> Enter same passphrase again: <enter> Your identification has been saved in id_rsa. Your public key has been saved in id_rsa.pub. The key fingerprint is: c3:af:e9:6c:2f:19:4d:b5:1a:a9:40:06:54:e6:60:08 jdoe@localhost $ ls id_rsa id_rsa.pub
There are two major versions of the SSH protocol, SSH1 and SSH2.
An SSH identity is tied to a specific SSH protocol version,
so you need to decide on which protocol to use and pick an appropriate
identity format from that. Most clients default to using the SSH2
protocol, however you can explicitly pick which protocol to use by
An SSH identity comes in three formats:
For sake of argument, I'll assume we're using
the SSH2 protocol, and include
So, now it is time to tell the remote account that we trust this test key. You need to include the public key (id_rsa.pub) in the file $HOME/.ssh/authorized_keys on the remote account. You can do this in several ways.
username@server$ cd $HOME username@server$ chmod go-w . username@server$ cd $HOME/.ssh username@server$ chmod 700 . username@server$ chmod 600 *
So, let's test logging in with this key. Since we have put the test key in a non-standard place, we will need to reference it explicitly on the command line:
local$ ssh username@server -i $HOME/identity_test/id_rsa username@server$ hostname server username@server$ exit local$ ssh username@server -i $HOME/identity_test/id_rsa "echo Success!" Success! local$
In the first example we logged into the server interactively,
while in the second we ran the
If you're having trouble getting this to work, you should check the
server logs and see if it provides any insight, as well as running
# Allow Identity Auth for SSH1? RSAAuthentication yes # Allow Identity Auth for SSH2? PubkeyAuthentication yes
When you're done testing this, you should delete the entry from ~/.ssh/authorized_keys on the server. Next week we'll set it up to be usable only from your designated machines, and only be able to run authorized commands.
If you're interested in setting up seamless identity authentication without the limits we'll be setting up, you may want to check out two pieces of software:
 The server and client go through a bit of mathematical rigamarole to prove that the client possess the secret key. The specifics aren't material to this discussion, If you want more information, check the SSH man pages, RFC, or the SSH book by O'Reilly.
 Earlier versions of OpenSSH required you distinguish between SSH1 and SSH2 protocols (the latter needed to have keys placed in $HOME/.ssh/authorized_keys2.) SSH.com's version of the SSH server and client have the same functionality as OpenSSH, but implements things in a very different way.
 vim, naturally.
Bri Hatch is Chief Hacker at Onsight, Inc and author of Hacking Linux Exposed and Building Linux VPNs. He's been using SSH to secure his remote logins since Tatu posted the first version of the code - even if the administrators of those machines refused to install it for him. Bri can be reached at email@example.com.
Copyright Bri Hatch, 2002
This is the December 26, 2002 issue of the Linux Security: Tips, Tricks, and Hackery newsletter. If you wish to subscribe, visit http://lists.onsight.com/ or send email to Linux_Securityfirstname.lastname@example.org.