BLOG

Moving from Passwords to SSH Keys: The Final Security Layer

- Essential First Steps to Secure a Linux VPS

- How to Install and Configure Fail2ban for SSH and Nginx Protection

-> Moving from Passwords to SSH Keys: The Final Security Layer

Introduction

We have already secured our VPS by creating a sudo user and configuring a firewall, and we have set up Fail2ban to ban bots. However, as long as password authentication is enabled, there is a theoretical chance that a brute-force attack could succeed (especially if your password is weak).

The "Gold Standard" of Linux security is disabling password authentication entirely and using SSH Keys. Even if an attacker knows your IP and username, they cannot log in without the cryptographic key file stored on your computer.

In this guide, we will generate an SSH key pair, install it on your server, and disable password logins forever.

Step 1: Generate a key pair (local machine)

Important: You must run this command on your computer (laptop/desktop), not on the VPS server.

We will use the Ed25519 algorithm, which is more secure and faster than the old RSA standard.

Open your local terminal and run:

xinit@localhost:~$ ssh-keygen -t ed25519 -C "your_email@example.com"

-t ed25519: Specifies the modern algorithm.
-C: Adds a comment (usually your email) to identify the key later.

The system will ask for a location (press Enter for default) and a passphrase.

Recommendation: Set a passphrase. This encrypts the key on your disk. If someone steals your laptop, they still cannot use the key without the passphrase.

⚠

Security warning: Protect your private key

NEVER share your private key. Never upload it to GitHub, never send it via Telegram/Slack, and never copy it to the server. If this key is leaked, anyone can access your servers. Treat it like your credit card pin.

The command above creates two files in your ~/.ssh/ folder:

id_ed25519.pub (Public Key): This is what you put on the server. It acts like a lock.
id_ed25519 (Private Key): This is the key to the castle.

Step 2: Copy the public key to the server

Now we need to install the "lock" (public key) on your server. Linux has a built-in utility for this.

Replace username and server_ip with your actual data:

xinit@localhost:~$ ssh-copy-id -i ~/.ssh/id_ed25519.pub username@server_ip

The system will ask for your user's password one last time to authorize the copy.

Step 3: Test the connection

Critical Step: Before disabling passwords, verify that the key works. If you skip this and disable passwords, you might lock yourself out of the server!

Open a new terminal window and try to connect:

xinit@localhost:~$ ssh username@server_ip

If everything is correct, you should be logged in immediately (or asked for the key's passphrase if you set one), without entering the user's account password.

Step 4: Disable password authentication

Now that the key is working, we can close the door for password-based logins.

xinit@localhost:~$ sudo nano /etc/ssh/sshd_config

Find the following parameters and change their values to no. If a line is commented out (starts with #), remove the #.

Disable password authentication:

PasswordAuthentication no

Disable Pluggable Authentication Modules (optional, but recommended for pure key-based setups):

UsePAM no

Also, ensure that root login is strictly disabled (as we discussed in previous articles):

PermitRootLogin no

Save the file (Ctrl+O, Enter) and exit (Ctrl+X).

Step 5: Apply changes

Restart the SSH service to apply the new security rules.

Restart the daemon:

xinit@localhost:~$ sudo systemctl restart sshd

Conclusion

Congratulations! Your server is now immune to password brute-force attacks. Even if a hacker has a supercomputer and tries billions of passwords per second, the server will simply reject the connection request immediately because it requires a cryptographic key.

This completes our server security trilogy. You now have a hardened Linux environment ready for production deployment.