When you provision a new deploy Pakistan VPS or a dedicated Linux server, the default configuration almost always relies on password-based SSH authentication for the root user. Within minutes of your server coming online, automated botnets will begin relentlessly brute-forcing port 22 in an attempt to guess your password.
Relying on a password—even a complex one—is a significant vulnerability. In this guide, we will walk through the critical steps of migrating to cryptographic SSH keys and permanently disabling password authentication.
1. Generating Cryptographic SSH Keys
The first step in hardening your server is generating a secure key pair on your local machine (not the VPS). While RSA keys were the standard for many years, modern cryptography favors the Ed25519 algorithm, which offers better security and performance with a much smaller key size.
Open your local terminal and run:
ssh-keygen -t ed25519 -C "[email protected]"This command generates two files in your ~/.ssh/ directory:
id_ed25519(Your Private Key - NEVER share this)id_ed25519.pub(Your Public Key)
2. Copying the Public Key to the VPS
Next, you must transfer the public key to your Linux VPS. The easiest way to do this from a Linux or macOS local machine is using ssh-copy-id:
ssh-copy-id -i ~/.ssh/id_ed25519.pub root@your_vps_ipIf you are on Windows, you can manually copy the contents of id_ed25519.pub and append it to the ~/.ssh/authorized_keys file on your remote server. Ensure the permissions on the .ssh directory are strictly set to 700 and authorized_keys to 600.
3. Disabling Password Authentication
Once you have verified that you can successfully log into your VPS using your newly generated SSH key, it is time to disable password authentication entirely.
Log into your server and edit the SSH daemon configuration file:
sudo nano /etc/ssh/sshd_configLocate the following directives and modify them as shown:
PasswordAuthentication no
PubkeyAuthentication yes
PermitRootLogin prohibit-passwordBy setting PermitRootLogin prohibit-password, you ensure that the root user can only ever log in via a cryptographic key, rendering all password brute-force attacks useless.
Restart the SSH service to apply the changes:
sudo systemctl restart sshd4. Advanced: Auditing and Port Changing
For defense-in-depth, many administrators choose to change the default SSH port from 22 to a non-standard port (e.g., 2222). While this is merely security through obscurity, it dramatically reduces the noise in your /var/log/auth.log files by dropping automated script-kiddie traffic.
If you are using a control panel like cPanel or Plesk, ensure that your firewall rules are updated before changing the port. As discussed in our CSF Firewall Guide, locking yourself out by changing the SSH port before updating your TCP_IN rules is a common mistake.
Furthermore, integrating your SSH daemon with advanced WAFs or monitoring tools can help you track failed login attempts originating from Local Security WAF Bypasses.
Conclusion
Securing your Linux server is not a one-time task; it is an ongoing process of reducing your attack surface. By migrating from passwords to Ed25519 SSH keys, you eliminate the most common vector for server compromise, ensuring your infrastructure remains secure against automated internet scanning.
