You would like to quickly set up a new server with root access and a root password (say on Digital Ocean), but are concerned about security. After all, it is difficult to create and remember a strong password, especially if you manage multiple servers. You would like to add SSH Key Authentication and protect yourself from brute-force cracking attempts but don't know how.
Set up your server with root access and a password and follow these steps to add an SSH Key as an authentication method. After copying your key to your new server, we will disable password login and require SSH Key and passphrase login instead.
Let's start by spinning up a new server...
Stage I: Set Up a New Digital Ocean Server and Log in via SSH
Follow these instructions to set up and connect to a new server via SSH:
- Set up a new Digital Ocean droplet test server for practice: Here's a free $10 credit, good for two months of server usage.
- If you're just getting started follow these steps:
- Create a new Droplet and choose Ubuntu 14.04 or 16.04.
- Select the $5/mo., 20GB server option (cheapest).
- Select the datacenter location nearest you.
- If you plan to use this server long-term you may elect to enable automatic Backups for an additional $1/month. (Worth it if you aren't familiar with creating system backups; Tarsnap works too though.)
- Forgo SSH login options: Don't add SSH keys at this time; we'll do this in Stage II.
- Choose a Hostname which will allow you to identify the droplet easily. NOTE: This is not a domain name.
- Hit 'Create' and watch as your server is magically spun up before your eyes!
- Next, get the root login password from the email Digital Ocean has sent you.
- Open your terminal on your local machine and log in to your droplet with the root password.
- Change the root password to a new secure password when prompted to do so. For example: 10+ random characters, or 6-10 memorable words works. We will be disabling password login in Stage III, but set a good password anyways: It's good practice!
- Get your IP address, either from your Digital Ocean droplets list, or through the command line using:
ifconfig | grep "inet addr:". NOTE: Use the entry to the left of
Bcast; not the localhost
127.0.0.1. Write this down somewhere.
Stage II: Create an RSA Key Pair to Add to Your New Remote Server
On your local server, perform the following steps:
ssh-keygen -t rsa-- This creates a public and private RSA-encrypted key pair, by default in the
- When prompted use the default location and hit ENTER.
- Set a robust passphrase, i.e. 6-10 words that you will remember. This secures your RSA-key. Write this down in a secure location.
- Next, copy your Public Key (
/home/user/.ssh/id_rsa.pub) to the remote server. Do:
- If prompted for a password, enter the remote root login password which you set in Stage I.
- You should see the following output if the SSH key was copied over correctly:
Number of key(s) added: 1
Now try logging into the machine, with: "ssh 'root@<remote-IP>'" and check to make sure that only the key(s) you wanted were added.
- Test it out. Try loggin in using SSH key authentication:
- When prompted, enter your passphrase for your
- You should now be logged in securely having used your SSH key and your passphrase.
At this point you can go ahead and do this for any number of servers you administer. Each one, once it has received your Public Key, will allow you to log in using the key and your passphrase. The true advantage of this is that this one passphrase will now allow you to log in to all the servers you copy your key to.
But wait, there's more! Now we can truly secure our servers by disabling password login...
Stage III: Disable Password Login on Your Remote Server and Require SSH Key Authentication
On your remote server, now that we have added the SSH key, we can safely disable password-based logins for root.
Follow these steps in order to complete the process and secure your server:
- Open the
sshd_configfile found in
/etc/ssh/with your favorite text editor, e.g.:
- Find the line which says
PermitRootLogin yesand change it to
- Save and quit: In Vim, do
:wq, and hit
- Restart your SSH daemon to use the new settings. Do:
- You're done! Server secured!
Rinse and repeat on all your favorite servers!
As a final step, you can set up
ssh-agent to load your passphrase for you automatically.
(Optional) Stage IV: Let
ssh-agent Load the Passphrase Automatically
eval $(ssh-agent)to run the ssh-agent in the background. This daemon stores your passphrase in memory on your local system and pulls it up whenever you are logging into a system which requires it.
You should see a message such as: "
Agent pid 12345". Check that ssh-agent is running. Do:
ps aux | grep agentand look for the PID number shown. Assuming you have found it we will now go ahead and add our keys to it.
Enter the command:
ssh-add. This will add the standard key identity to the key manager. The ssh-add program will then ask you for your passphrase. After you have entered your passphrase your key will be loaded into memory.
Try logging in to your remote system again:
ssh root@<remote-IP-address>. This time you should not be asked to provide your passphrase and you will be logged right in!
Shout out to The New Boston. I learn from the best...
View these three awesome video tutorials from The New Boston. This is how I learned to use SSH Key Authentication:
STAGE I: Setup and Connect to SSH Server
STAGE II: SSH Key Authentication
STAGE III: Disable Password Login
Reddit user ackackacksyn has correctly pointed out that the
PermitRootLogin without-password setting would only disable password login for the root user.
For many reasons, it is advisable to disable the root user entirely and instead set up SSH Key Authentication for a
wheel-group user. You may then set the
PasswordAuthentication setting in
/etc/ssh/sshd_config to 'no'.
Look for the following:
# Change to no to disable tunnelled clear text passwords #PasswordAuthentication yes
Simply un-comment (remove the
#) the line and change it to:
PasswordAuthentication no. Of course, you'll need to have set up the SSH Key Authentication method from Stages I and II first.
This would allow your commands to be "properly logged for your audit trail", adds ackackacksyn. The Debian wiki corroborates this: Using
sudo is better because, "when a sudo command is executed, the original username and the command are logged".