This is a very generic and basic configuration to setup SSH key authentication for Linux. I will not go into great detail nor do I assume that this configuration is the most secure or practical. I am simply identifying the requirements to configure SSH authentication using public and private key pairs. To start you want to make sure that openSSH is installed on your OS. For Debian based operating systems, this can be as simple as issuing the following command: sudo apt-get update sudo apt-get install openssh-server openssh-client (where openssh-server installs the server and openssh-client installs the client) or review the website for details on installing it. http://www.openssh.org/once the server is installed, you will want to configure it to use public key authentication as by default it is disabled. This can be done by editing 2 files /etc/ssh/sshd_config to modify the server settings and /etc/ssh/ssh_config to modify the client settings. If you plan to use this installation to both connect to other servers and connect to, you will need to modify both of the files. First, the /etc/ssh/sshd_config file will allow changes to be made to the ssh server. The following lines will need to be added or uncommented based on the original configuration file provided. I would highly recommend creating a backup copy of the file before making any changes in case something goes horribly wrong.
While there are other options that I would also configure at this point, they do not relate to the configuration of public key authentication and so will not be discussed here. This will “enable” authentication using a public / private key exchange and it will direct the server where to look for keys that it will accept. The “%h” is the variable for the home location, and then the default filename is authorized_keys but really any name can be used here. Restart the ssh server by issuing the following command:
sudo /etc/init.d/ssh restart
Now, we need to set the client. Open the /etc/ssh/ssh_config file and add or uncomment the following lines (again, I recommend making a backup of this file as well. This can be as simple as:
cp ssh_config ssh_confg.orig
Once you have your backup, the only line that needs to be changed is:
where this provides the system the location of the file to use to identify yourself to the remote server. In the next step we will create this file, so for now it can be named anything identity is simply a default. The “~/” refers to the current users home folder (or your folder in this case). Since the identity file doesn’t exist, we need to create it. To make things easy, I type “~/” and press return to make sure I am in my home directory. It really isn’t necessary, but when you want to verify the creation of the .ssh folder and the identity file, it is nice to already be here. Issuing the following command will generate the public and private key pair that we will use to identify ourselves to other servers.
ssh-keygen -t dsa
This will walk through a short process and ask you to name your keys. The default location is fine, but you may want to name your keys something special. Just note that whatever you set the name to here will need to be also set in the ssh_config file. So if you use the name “~/.ssh/mykey” for example, this location and name will need to be provided in the ssh_config file so that the ssh client will know where to find the key you would like to use.
Once the key generation is complete (if you didn’t before and you are using the default location) you will have a .ssh folder in your home directory. It is a dot file and therefore hidden by default, but typing
you will be shown the hidden files and folders in your directory. if you change directory into that folder you will see [your key name] and [your key name].pub. The [your key name] is the private key, you will want to guard this with your life. If someone gains access to this key they will be able to access any location / server that where you have uploaded your public key. Now, the last step to ssh key authentication is to put the public key in the “authorized_keys” file or the file on the server you want to access that verifies the keys for access.
The best way I have found to do this is to connect to the server via ssh and password one last time to upload the public key using the following command.
cat ~/.ssh/id_rsa.pub | ssh user@machine "mkdir ~/.ssh; cat >> ~/.ssh/authorized_keys"
If the .ssh directory already exists on the server the alternate to just place the key in the file would be
cat ~/.ssh/id_rsa.pub | ssh user@machine "cat >> ~/.ssh/authorized_keys"
where cat reads the file “id_rsa.pub” (or whatever the file name happens to be) and then it “pipes” it to the ssh session, and finally using cat we append the new key to the authorized_keys file.
Once these steps are complete, and no errors were encountered, you should be able to enter ssh user@machine and authenticate via key. If you provided a pass-phrase for your key, you will be asked to enter it, otherwise you will be logged on and ready to go. On Windows platforms using pass-phrases can be frustrating as it will ask for the pass-phrase every time a connection is attempted. This can be helped by using something like Pageant for PuTTY which will “capture” your pass-phrase for your key and use it when logging on. You will need to supply the pass-phrase 1 time every time you log on to the Windows computer, but it beats having to repeatedly type it when connecting to a server.