A password can be guessed, but an SSH key cannot. That is why the most useful way to protect a server is to log in with a key and turn off password login completely. Then the bots that guess passwords around the clock simply run into a locked door.
Here is what we will do, step by step.
- create a separate user instead of root;
- create an SSH key on your computer;
- copy the key to the server;
- check that key login works;
- disable password login and root login.
What you will need
To begin, you need SSH access to the server as root. The IP address and password are in the email you receive after ordering and in the “Instructions” section of the client area. We showed where to find it in the article on ordering a VPS.
1. Create a separate user
The commands are run on the server, as root.
Working as root every day is unsafe, because a single mistake or a stolen password gives an attacker full access. So we will create a regular user and give them the right to run administrator commands through sudo.
# Create the user admin (you can choose any name).
# The command asks you to set a password, and you can skip the
# other questions with the Enter key
adduser admin
# Add the user to the sudo group so they can run administrator
# commands
usermod -aG sudo admin# Create the user admin (you can choose any name)
adduser admin
# Set a password for the user
passwd admin
# On these systems administrators belong to the wheel group
usermod -aG wheel adminYou will still need the user's password, because sudo asks for it. But you will soon no longer need it to log in to the server.
2. Create an SSH key on your computer
This command is run on your own computer. On Windows, open PowerShell, and on macOS and Linux, open Terminal.
# Create an ed25519 key, a modern and secure option
ssh-keygen -t ed25519 -a 64The program will ask a couple of questions.
- where to save the key – just press Enter;
- passphrase – a password for the key itself. It is best to set one, because then nobody can use a stolen key file without it.
As a result, two files will appear in your user's .ssh folder.
id_ed25519– the private key, which stays with you only;id_ed25519.pub– the public key, which we will put on the server.
Never share your private key
The id_ed25519 file is your private key. Do not send it in messengers, do not upload it to cloud storage and do not put it on the server.
Only the file ending in .pub ever leaves your computer.
3. Copy the key to the server
The command is run on your own computer. Replace SERVER_IP with the server's IP address.
# Copy the public key to the server for the user admin
ssh-copy-id admin@SERVER_IP# Windows has no ssh-copy-id command, so we send the key in a
# single line. It creates the .ssh folder on the server, appends
# the key to authorized_keys and sets the right permissions
type $env:USERPROFILE\.ssh\id_ed25519.pub | ssh admin@SERVER_IP "mkdir -p ~/.ssh && chmod 700 ~/.ssh && cat >> ~/.ssh/authorized_keys && chmod 600 ~/.ssh/authorized_keys"The command will ask for the admin user's password. This is the last time you need it to log in.
4. Check key login
Connect from your computer in a new terminal window.
# Connect as the new user. The server password should not be
# requested, at most the key passphrase if you set one
ssh admin@SERVER_IP
# Once on the server, check that sudo works. The command should
# print root
sudo whoamiIf you connect through Termius, add the key in its settings and set the user to admin. We showed how to connect through Termius in a separate article.
5. Disable password login and root login
Do not close the old connection
Keep your previous session open until you have made sure that key login works in a new window. If something goes wrong, you can easily put everything back through it.
On Ubuntu and Debian, SSH reads its settings from several files in the /etc/ssh/sshd_config.d/ folder at once, and the setting that comes first wins. For example, the 50-cloud-init.conf file may allow password login, and then your ban in another file simply will not work. That is why we will create our own file numbered 00, so the server reads it before all the others.
From here on, the commands are run on the server.
# Create a file for our SSH settings and open it in the nano
# editor
sudo nano /etc/ssh/sshd_config.d/00-security.confPaste these lines into the file.
# Do not allow logging in directly as root
PermitRootLogin no
# Do not allow password login
PasswordAuthentication no
# Keep key login enabled
PubkeyAuthentication yesTo save the file, press Ctrl + O and Enter, and to exit the editor, press Ctrl + X.
Now we will check the settings and apply them.
# Check the settings for errors. If the command prints nothing,
# everything is fine
sudo sshd -t
# See which settings are actually in effect
sudo sshd -T | grep -E "permitrootlogin|passwordauthentication"The output should contain permitrootlogin no and passwordauthentication no. If you see a different value, another file is overriding it. Check what is in the folder with the ls /etc/ssh/sshd_config.d/ command.
All that is left is to restart SSH.
# Restart SSH so the new settings take effect
sudo systemctl restart ssh# Restart SSH so the new settings take effect
sudo systemctl restart sshd6. Final check
Open one more terminal window and check both cases.
# Logging in as admin with the key should work
ssh admin@SERVER_IP
# Logging in as root should now end with a Permission denied
# error
ssh root@SERVER_IPIf that is what you see, congratulations, nobody can guess the password to your server any more. You can close the old session now.
If you lose access after all
If you lose access after all, open the server with the Console button in the server list in your client area. The console opens the server right in your browser, without SSH, and you can undo the settings by deleting the /etc/ssh/sshd_config.d/00-security.conf file.
Our resources
Telegram channel: https://t.me/f3cloud_news
F3 Cloud: https://f3cloud.com