What is this functionality used for and why do we set it up?
Normally you login securely to your server using SSH on port 22. This port is often attacked by automatic bots trying to break into your server. By using SSH keys you basically 'tie' your work computer to the server and it will be the only device allowed to login to the server.
WHAT TO UNDERSTAND
- Most tutorials show you how to secure the root account only using this method.
- This tutorial will show you how to secure any user account on the server with SSH keys
Ok, let's do it! - Here are the commands:
TO DO ON YOUR LOCAL COMPUTER/DEVICE
(1) Create the RSA Key Pair. (On the client machine. Probably your computer)
ssh-keygen -t rsa
(2) Store the Keys and Passphrase
Once you have entered the Gen Key command, you will get a few more questions:
Enter file in which to save the key (/home/demo/.ssh/id_rsa):
You can press enter here, saving the file to the user home (in this case, my example user is called demo).
Enter passphrase (empty for no passphrase):
I usually leave the passphrase empty to keep login easy. (Just hit return)
After running the command:
the public key is now located in /home/demo/.ssh/id_rsa.pub the private key (identification) is now located in /home/demo/.ssh/id_rsa
(3) Copy the Public Key
Once the key pair is generated, it's time to place the public key on the virtual server that we want to use.
Now you can go ahead and log into email@example.com and you will not be prompted for a password.
Most people will use above to protect the root account e.g. ssh-copy-id firstname.lastname@example.org but you can use this command from your local computer to upload your SSH key to ANY user account. e.g. ssh-copy-id email@example.com
Another way to get the public key on to the server is to login to the server and manually edit the 'authorized_keys' file that is in the .ssh directory of each users home directory. E.g. nano .ssh/authorized_keys (just paste the public key into this file)
TO DO ON YOUR SERVER (basically login with e.g. ssh firstname.lastname@example.org)
(4) Disable the Password for Root Login (optional)
This is done on the server by editing the sshd_config file
Within that file, find the line that includes PermitRootLogin and modify it to ensure that root can only connect with an SSH key:
Don't get confused by the wording 'without-password'. It just means that password authentication is DISABLED for root. It does NOT mean that root can login with an empty password
Basically PermitRootLogin specifies whether root can log in using ssh(1). The argument must be “yes”, “without-password”, “forced-commands-only”, or "no”. The default is “yes”. IF this option is set to “without-password”, password authentication is DISABLED for root. Thus without-password allows root login ONLY with public key authentication
(5) Disable password authentication for all users (also optional)
In the same file, find the line that includes PasswordAuthentication and modify it to ensure that ALL users must have an SSH key to connect. (regular password authentication will be disabled)
Do not implement step 5 above until you have first uploaded the SSH key to EACH user account using the ssh-copy-id command (step 3.) Because once this has been implemented, NO user account can login using a password. ONLY logins using an SSH Key will be allowed.
Put these changes into effect by using any of these commands:
service ssh restart OR
Most of above came from this great tutorial that you should read if you want to know more: https://www.digitalocean.com/community/tutorials/how-to-set-up-ssh-keys--2
LOCAL COMPUTERS - REMEMBER to implement above for each local computer that you are going to use to access your server
CONFIG FILE - Do not edit the sshd_config file until you have implemented SSH keys on all user accounts and on all computers you are going to use to connect to your server. If you do, the ssh-copy-id command will be blocked as you try to upload the SSH keys.
You need to decide WHAT users you wish should be able to access the server and THEN you can decide how tight you want your security to be. Below are some scenarios listed for you that can guide you:
Who will access the server?
JUST YOU [most secure]
Implement all steps, 1-5
YOU AND A DEVELOPER/S [secure and flexible]
Implement steps 1-4
YOU AND THE REST OF THE WORLD [flexible]
Do nothing (not recommended)
Security and flexibility don't always go hand in hand.
You need to decide what is more important to you - flexibility or security.