Even though this isn’t anything new, it’s always something good to know, and have a reference in case you forget how to set it up. I use it with the utmost sense of security. I will use it for scheduled backups, and the keys always hidden, with root online having access to it. This method works on Linux, all BSD distributions, and MacOS X (And of course Cygwin on Windows).
First off, let’s explain the scenario. You have two systems. One we will call the client, and one the server. The client is the one SSHing into the server, and the server being the one holding the ability to connect with the key.
To start, we need the client to create the key pairs, and hold the key information to login with. The server holds the ID key to compare. As we go through the setup, we will also lock down the access to this key, since anyone with access could log into the server with it as long as they have access. So, let’s start.
On the client, we want to create the keys. Whatever user you want to login as without a password, be sure to put the keys in its SSH folder.
$ cd /home/myuser/.ssh ~/.ssh$ ssh-keygen -t rsa -f remote Generating public/private rsa key pair. Enter passphrase (empty for no passphrase): Enter same passphrase again: Your identification has been saved in remote. Your public key has been saved in remote.pub. The key fingerprint is: c4:f8:6f:ef:0e:96:5b:7c:ad:fb:c9:75:c8:7d:17:53 firstname.lastname@example.org ~/.ssh #
Since around 2005, distributions of all kind started making /root accessible by various users. So with that, we need to lock down the SSH directory.
~/.ssh$ mkdir keys ~/.ssh$ mv remote* keys ~/.ssh$ chown myuser:root /home/myuser/.ssh ~/.ssh$ chmod 700 /home/myuser/.ssh ~/.ssh$
There we go. Now we need to get the public key to the server. To do this, we’re going to use SFTP, something everyone should use, especially ones using FTP. I’m using the port option in the example, just so people who don’t know how to use a different port will know after this. Also, I set the group to root, since that goes across all the distributions, but doesn’t matter since the group doesn’t have permission.
~/.ssh$ cd keys ~/.ssh$ -oPort=8022 sftp remoteuser@server Connecting to server... Password: sftp> put remote.pub Uploading remote.pub to /home/remoteuser/remote remote.pub 100% 1675 1.6KB/s 00:00 sftp> exit ~/.ssh$
Next, we want to put the key into a SSH file that allows the server to recognize any ID key that comes through. We will be using the file authorized_keys2 in the .ssh directory on the server. If if does not exist, create it. I will continue as if it does not exist.
~/.ssh$ ssh -l myuser server Password: @server$ cd .ssh ~/.ssh@server$ touch authorized_keys ~/.ssh@server$ cat /home/remoteuser/remote.pub >> authorized_keys ~/.ssh@server$ chmod 600 authorized_keys ~/.ssh@server$
Of course, we could have just used cat to created the authorized_keys file, but it’s always good to get in the habit of touching new files. Second, being a new file, we didn’t need to use “>>” to append to the file, but if you make more, using one is going to wipe out anything else. You might as well use two out of habit.
NOTE: authorized_keys, and the keys must be set to 600 or less, and must be owned by the user who owns the home directory they reside in. Not doing so will cause this to not work.
Now that we have the public key in place on the server, now it’s time to test the keys.
~/.ssh$ ssh -l remoteuser -i keys/remote server
IF this worked, then you are all set to use the keys as a way to login without a password. The most reasonable usage of this, and only real reason to be, due to security; is using for scheduled services to backup files, or anything else needing a login on the other side. For instance, here is a snippet of my rsync script used to backup some of the servers at Network Synapse.
Of course, this is set as a cronjob to be done every night, and without needing to enter a password.
One of the best things you can do, is restrict the program that can use the key. If we use command=”” ‘ at the beginning of the key in the authorized_keys file, that program, and ONLY that program can use that key. Pretty neat huh? I strongly urge you to use this, otherwise, anyone with access to that key can simply use it to get into your server.
For the sake of being complete, here is how you can make it to where you can make it to where you don’t have to use a password at all, at any time.
~/.ssh$ cp remote id_rsa ~/.ssh$ cp remote.pub id_rsa.pub ~/.ssh$ ssh -l remoteuser server ~/.ssh@server$
So, now you know how to setup SSH to login to other systems without a password, and also know the risks involved. Se safe and enjoy!
Over time, I’ve run across a few issues that don’t exactly stick.
1. If the remote host isn’t in the known_hosts from the host using the ID key, you will still be asked for a password.
2. not chmod’ing authorized_keys to 600 will cause a password to be asked for.