Using SSH is a great way to remotely manage a server and to securely transfer data to and from it. You basically connect using SSH with your username and password. In that case you authenticate with something you know, which in this case is the password.
But you can also authenticate with something you have, like an SSH key. You can use this to authenticate without a password, and even configure the server to only allow SSH keys to prevent password attacks.
This tutorial shows how to configure the SSH server, generate SSH keys for each user and optionally disable password logins.
Verify that the server has a host key
On Linux, check if either the DSA host key file /etc/ssh/ssh_host_dsa_key or the RSA host key file /etc/ssh/ssh_host_rsa_key exists. If one or the other exists, you can only use that kind of key to connect to SSH. If you really want both, you can generate each like this (as root):
ssh-keygen -t dsa -f /etc/ssh/ssh_host_dsa_key
ssh-keygen -t rsa -f /etc/ssh/ssh_host_rsa_key
Of course you can use different file names if you like.
After settings these up, edit the SSHD config file (sshd_config) and make sure that there’s a HostKey item for each of these host keys and that these items are uncommented (don’t have a #-character in front of the line).
HostKey /etc/ssh/ssh_host_dsa_key HostKey /etc/ssh/ssh_host_rsa_key
Also make sure that RSAAuthentication and PubKeyAuthentication are set to yes and are uncommented:
RSAAuthentication yes PubkeyAuthentication yes
For security reasons you must make sure that the host key files (NOT the public key files with .pub in their names) are only readable and writable by root. These PRIVATE keys should be kept secret from anyone else. You can fix that with CHMOD:
chmod 600 /etc/ssh/ssh_host_dsa_key chmod 600 /etc/ssh/ssh_host_rsa_key
Save the SSHD configuration file and restart the SSH Server. Consult your OS to do this. On Linux this is usually done with either:
service sshd restart
Now make sure that the home folder of the user account you wish to login has a .ssh folder. Log on as the specific user, and then run:
If it gives an error about directory already exists, then you can just ignore that message. it just means that the folder is already there.
Generating an SSH keypair
Now you should generate an SSH keypair for each computer that should connect to the server. If that computer runs on Linux, BSD or Mac OS X you can do that directly from that computer. Otherwise you need to generate it using 3rd party tools or on a different Linux box and then move the keys to the specific computer afterwards.
First of all, make sure that you are logged in with the user account you wish to use when connecting to the server. Again, verify that the .ssh folder exists in your home folder.
Now run the following command in a terminal for an RSA keypair (replace RSA with DSA for a DSA keypair):
ssh-keygen -q -t rsa -f ~/.ssh/id_rsa -C '' -N ''
This will create two files in your .ssh folder: id_rsa (your private key) and id_rsa.pub (your public key). You should carefully guard your private key (make it read/write for your user account only (chmod 600)). Your public key should be stored on the server. We get to that in a minute.
If you are using Microsoft Windows, you should use a 3rd party utility or install the Cygwin UNIX layer. In case you would decide to generate the keypair on a different system, make sure that you import the PRIVATE key in your SSH application and REMOVE it from the original system where you’ve generated it.
Importing your public key
Your goal here is to save the contents of your public key into the file .ssh/authorized_keys in the home folder of the user account you wish to logon on the server. If the file doesn’t exist, you can create it. If you have an SFTP client with a file manager, this should not be a problem.
As an alternative, you can use SCP:
scp id_rsa.pub firstname.lastname@example.org:~/public_key
This copies your public key to the home folder of the server user account using the file name public_key. Now log on to the server using SSH. Enter the following command to add the contents of your public key to the authorized_hosts file:
cat ~/public_key >> ~/.ssh/authorized_hosts
You can now remove the public key you’ve uploaded to the server, as it’s no longer neccesary:
Tip: If you have to manage many public keys for one user, you can add information to each line of authorized_keys like the name of the computer using comments, like this:
# myPC ssh-rsa 12312310423094892304823904823904823 # myLaptop ssh-rsa 424098293048293048230948293048230948239084
Disable password logins
At this point you can login to SSH using either your password or your private key. You can still login using a password if you don’t have your private key at hand. If you want to disable password logons, follow these steps.
Before you continue, make sure that you can log on to SSH without the need of a password. If you disable password authentication and your keys aren’t working, this will render SSH useless and require you to access the server in a different way. That said, make sure to secure your private key. If all private keys are lost, you’ll end up in the same scenario.
Edit your SSHD config file as root (sshd_config) and set the line PasswordAuthentication to no, and make sure it’s uncommented:
Restart your SSH Server to save your settings.
If you are having issues, make sure to note any error messages you may receive when asking for help. Some tips:
– All files in your home folder should be owned by you (chown -R username ~/), and only be accessible to you (chmod 700 ~/ && chmod 600 ~/* && chmod 700 ~/.ssh). All other files should be owned by root and root only.
– The server should have the SSH Server AND Client installed, while the clients only need to have the SSH Client installed.
– This guide is targeted for users of Linux, BSD and Mac OS X. Other platforms like Microsoft Windows, iOS, Android etc. need to use 3rd party tools for an SSH Client and/or SSH Server, but the basics apply here as well.
– Key authentication is a great solution when using SSH connections in automated scripts. We don’t want to store a password in plain text on a system, now do we? 😉