Security August 17, 2004 at 9:35 am

The Keys to the Door of the SSH Tunnel

Now that you know how to make a SSH tunnel how can you make it work without a password challenge?

Useful for automated processes, and lazy fingers, a public-private key set may be what you are looking for. You can also use keys with a passphrase for even more security.SSH is already pretty secure, but it can be made even more secure with the use of public-private login keys which prevent your password from ever going over the wire. You can also use the keys to allow access without the need for any passphrase at all. This can be dangerous because if someone gets ahold of your private key they will be able to login as you.

Often you might want to allow unchallenged SSH authentication so that automated processes, such as rsyncX, can run in the middle of the night. You can limit what the client is able to do in the session by adding a command="command to execute" statement to the beginning of the key.

When you connect to a SSH host it will request authentication from the client. If you have a key set, your SSH client will generate a temporary key based on your private key. It will then send this key to the server and the server will compare it to the public keys that it has. If your public key there can unlock the temporary key you are authenticated and allowed access. If the keys fail then it drops back to password based authentication.

In my example here I am going to look at doing a passphrase-free key. It’s not as secure, but it’s simple and someone specifically asked how to do it.

How to do it
(This tutorial assumes that you haven’t generated a ssh key or used public/private key authentication before.)

First we need to make a key pair. We are going to use dsa as the key type to insure that we connect via the more secure SSH2 protocol.

ssh-keygen -t dsa

You will be prompted for a filename; just press return to accept the default. You will then be prompted for a key passphrase. If you want unchallenged logins just hit return to set it to a blank. If you want a passphrase, enter it now.

Now you will have your new public-private key set in ~/.ssh. The private key is named id_dsa and the public is id_dsa.pub.

In order for the server to use the key we must copy our public key to it. If you haven’t used keys for authentication before we can just copy the key up and rename it:

scp ~/.ssh/id_dsa.pub user@host:~/.ssh/authorized_keys

(This will create or replace your authorized_keys file on the server. If you have one already you should add to the file like so:

cat ~/.ssh/id_dsa.pub | ssh user@host 'cat - >> ~/.ssh/authorized_keys'

Again, if you haven’t setup an authorized_keys file before then don’t worry about it.)

Now try logging into the SSH server normaly:

ssh host.domain.com -l username

If you specified a passphrase you will be asked for it, otherwise it will just let you in.

Flaunting the obvious

If you are using single sign-on with a Mac OS X Server then all of this will be handled by Kerberos.

Also if you use a keyset without a passphrase you need to make sure no one gets that key. If you even think that it has been compromosed you should destroy it and generate a new one or you might get 0wn3d!

For much more info you should check out man ssh and man ssh-keygen. IBM has a nice page about all this too that was written by the CEO of Gentoo, Daniel Robbins. IBM OpenSSH Resources

Mike Bombich also has a good tutorial that touches on SSH keys on his site www.bomcich.com.

Leave a reply

You must be logged in to post a comment.