Creating and Deploying a SSH Key
A SSH Key allows you to log into a remote server without ever having to enter the password for you user on that server. In some situations, you can use this to increase security, by configuring the remote host to only allow SSH to be used when the client has a key. It can also be useful when the remote host does not have a password, such as when using Dropbear on initramfs. Or, if you need to be able to set up a cron job that can log onto a remote host, you could setup a passwordless key (although there are inherent risks to doing so) and use that to allow the log on.
Fortunately, setting up your SSH key is easy.
Generating the SSH Key
Do this part on the computer that you plan to ssh from
Run the command
ssh-keygen -t dsa
You should then see the prompt:
Enter file in which to save the key (/home/user/.ssh/id_dsa):
Unless you have a good reason, leaving it in the default location will make it easier to find in the future, should you need it again.
Once you’ve hit enter, you should see the password prompt:
Enter passphrase (empty for no passphrase):
Unless you have a very specific reason to leave it empty, such as the aforementioned cron job, it is best to give it a password.
You will then be prompted to enter the password a second time.
Placing the Key on the Remote Host
In order to use the key to access the remote host, you must copy your public key over.
If you used the default name and location, you should find your public key in ~/.ssh/id_dsa.pub
. You can copy this file over to the new server anyway you want, without concerns over security. Even if some one get this file, all they can do is setup their machine to allow you to log in.
If you don’t have a good way to do this, simply use the scp command, as follows:
scp .ssh/id_dsa.pub user@remotehost:~
This will leave the public key in the home directory of the user on the remote host.
Adding the Key on the Remote Host
Having copied the key over, you must now add it to the authorized_keys2
file.
First, make sure that the .ssh
directory exists, by entering the command mkdir ~/.ssh
Next make sure that the authorized_key2
file exists with the command:
touch ~/.ssh/authorized_keys2
If these files already exists, then this will do no harm. If they do not, then all the necessary directories and files will exist after you run the commands.
Next you add the key to the authorized_keys2 file. Assuming you copied the id_dsa.pub file to the user’s home directory, then the proper command is
cat ~/id_dsa.pub >> ~/.ssh/authorized_keys2
You are now done with the copy of the public key on the server, so you may delete it.
Next, make sure that the proper permissions are set for the authorized_keys2 file with the command:
chmod 600 ~/.ssh/authorized_keys2
If you use a common distribution like Debian, at this point you can probably test your key by logging out, then logging back in. When you log back in, you should be prompted for your key’s password instead of the user password.
If you are still prompted for the user password, then open the file /etc/ssh/sshd_config
(or its equivalent) for editing.
Make sure that each of the both the following lines are as below
PubkeyAuthentication yes
RSAAuthentication yes
Now restart the sshd server, by running the command
/etc/init.d/ssh restart
Forcing Server to Only Use SSH Keys
If you can setup keys for each of the computers you intend to log into your server from, then being able to log in remotely with the user’s password becomes an unnecessary security risk. Fortunately, it is possible to force SSH to only accept clients with keys.
All of the following commands must be done while logged into the server.
Open the file /etc/ssh/sshd_config
(or its equivalent) for editing.
Make sure that the lines below are set to no
, as shown
ChallengeResponseAuthentication no
PasswordAuthentication no
UsePAM no
Now restart the sshd server, by running the command
/etc/init.d/ssh restart