It seems that every time I am setting up a new bank of servers or a new rsync process I develop an acute case of Alzheimer’s. Whatever the reason be it the infrequency that I do these sorts of tasks or that I am actually just getting old I just can not seem to get it right on the first go. Initially I thought it was just me but after recently seeing this pop up in the FreeBSD questions list a few times I realized I may not be ‘that’ old.
First thing we need to do inorder to setup passwordless authentication is to generate a private and public key pair. How you do this on your system will largely depend on your system’s implementation of ssh. Fortunately ALL of my systems have one version of OpenSSH or another preinstalled so we will discuss how to do this using this system. OpenSSH is a child project of the OpenBSD project that was spawned out to be a separate entity for numerous reasons that really do not matter to the scope of this discussion. The important thing to note it that there is a version of OpenSSH available for just about every production operating system available at the time of this draft. It comes installed by default on every version of BSD including Mac OS X, but not iOS. Although it is available as an add-on for jailbroken iOS devices via the cydia project that too is entirely outside of the scope of this discussion.
In a terminal type the following command and peruse the documentation for a moment.
$ man ssh
You should note that there is a wealth of information about the various options and parameters available to you via the command line. The part you should focus your attention on is the ssh-key sections. In particular we will start with generating our ssh key. For this we need to execute the ssh-keygen command. However before we do we should determine a few basic parameters. In this case we will generate a 4096 bit key in lieu of the default 1024 bit key. While we do have the option of other encryption algorithms I am going to use the default RSA version for this example. Let’s take a brief moment to deconstruct the following command and it’s subsequent output.
$ ssh-keygen -b 4096 -C “mikel.king@olivent.com” -f test-id_rsa.key
The first thing to note is the -b option and it’s argument of 2048 it should be fairly self explanatory that this is where we set the bit count of out key. The next option is the -C and is used to set a comment which is absolutely a discretionary option. I personally require this on all of my systems so that I can easily identify which system the key is from. The last option is the output file name and I am overriding the default by adding the prefix ‘test-‘ to the file name. The Default would be id_rsa.key & id_rsa.key.pub for this sort of key and I only selected this to demonstrate the possibility. In addition I did not want risk clobbering any of my existing ‘real’ keys. Honestly you could rename the key to anything you’d like but it is really not worth defining your own obscure naming convention.
If you proceed with the default and you have used ssh in the past then you will already have the requisite .ssh directory in your home folder. If you have not used ssh under this account then ssh-keygen will alert you and offer to create it for you during the generation process.
Let’s take a short ride on the tangent train for a moment and note that since we are creating a passwordless authentication scheme I am not entering anything in the passphrase field. This is not the most secure way to accomplish this and there is a method using ssh-agent to hold your private keys and pass phrases to facilitate a much more secure version of what we are implementing in this article. That is a discussion for another time, and fortunately builds upon what we are doing here.
Very well returning to our original discussion let’s take a quick look at what has happend. At this point we have only generated the key pair for the user idea on this side of the server equation. Assuming that we are just trying to setup a oneway line of communication we will be fine. You should be keen to note the permissions assign to each file during this process.
$ ls -al
total 6
drwxr-xr-x 3 mikel.king mikel.king 512 Dec 6 12:01 .
drwxr-xr-x 4 root wheel 512 Dec 6 11:52 ..
drwx—— 2 mikel.king mikel.king 512 Dec 6 11:53 .ssh
$ ls -al .ssh
.ssh:
total 8
drwx—— 2 mikel.king mikel.king 512 Dec 6 11:53 .
drwxr-xr-x 3 mike.lking mikel.king 512 Dec 6 12:01 ..
-rw——- 1 mikel.king mikel.king 1675 Dec 6 11:53 id_rsa
-rw-r–r– 1 mikel.king mikel.king 401 Dec 6 11:53 id_rsa.pub
As previously mentioned this is on the initiating side of the connection and we still need to address the responding side. Although not absolutely necessary ultimately it is best to keep things simple by creating matching user IDs on both systems. Assuming that this is the case let us proceed with the discussion.
$ cat .ssh/id_rsa.pub |ssh mikel.king@olivent.com “cat > .ssh/authorized_keys”
Next simple attempt to ssh into the server in question. If you are prompted for a password then something when wrong. The likely culprit is going to be file permissions. Permissions requirement may vary from operating system to operating system. For instance on some systems a permissions setting of 644 may work as it did on this FreeBSD 8.x server I am experimenting on. Other have reported to me that this file must be set to 600 and on RHEL 5 I have observed that 640 is the magick number for the correct permissions. All that I am saying is that you may need to experiment a little before you get things working correctly. Another key issue (no pun intended) is the .ssh directory itself. I have yet to find a system that allows anything more liberal than 700. Honestly I can not imagine why you would even entertain considering anything less restrictive, but I mention it just in case you are the manual mkdir kind of admin.
Finally assuming that you managed to properly set the permissions and you have the private key safely tucked away in the .ssh folder of the initiating machine then you will be able to connect without being prompted for a password on the target system. While this is all well and dandy there is actually a purpose to this other than enabling an epic level of laziness. If you are an admin of the scripting wizard variety then it is likely you will want to move information form one machine to another. Once you have setup the passwordless authentication you are able to craft scripts allowing you to automate this tasks. The file mover rsync is a perfect example.
Remember the key (pun absolutely intended this time ;-P) to successfully accomplishing passwordless authentication is paying careful attention to the little details of permissions on each file that is part of the equation. Ok now that we have accomplished this your assignment is to make this a bidirectional flow. What I mean is that you are able to ssh into the target server from a particular host and back into that host from said server using ssh key based authentication.
ABOUT THE AUTHOR: Mikel King has been a leader in the Information Technology Services field for over 20 years. He is currently the CEO of Olivent Technologies, a professional creative services partnership in NY. Additionally he is currently serving as the Secretary of the BSD Certification group as well as a Senior Editor for the BSD News Network.
