How to secure SSH access to a LWS VPS: keys only and fail2ban

Procédure

To secure SSH access to your LWS VPS, it is recommended to completely disable password authentication in favor of an SSH key, then install fail2ban. This setup protects your server against brute-force attacks and eliminates the risks associated with intercepted or guessed passwords. In this tutorial, you will copy your public SSH key, adjust the SSH configuration to override cloud-init default settings, then install and verify fail2ban's active protection.

Install your SSH key

1. Connect once via SSH, then disconnect

   Open a terminal on your computer and connect to the server using the root password received in your delivery email. During the first connection, accept the server key fingerprint by typing yes. Once connected, immediately end the session by running exit to return to your local machine.

   ⌨ On your computerCopy

   ssh root@203.0.113.10
   exit

2. Copy your public SSH key to the VPS

   From your computer, use the ssh-copy-id command to copy your public key to the server. Enter your root password one last time when the terminal prompts you. If you had already added your SSH key during the order or reinstallation from the KVM panel, this step is not necessary.

   ⌨ On your computerCopy

   ssh-copy-id root@203.0.113.10

   Expected result

   Number of key(s) added: 1
   
   Now try logging into the machine, with: "ssh 'root@203.0.113.10'"
   and check to make sure that only the key(s) you wanted were added.

3. Verify SSH key-based login

   Reconnect to your VPS via SSH from your computer. The connection should be established instantly without asking for the server root password, confirming that your public key has been installed correctly.

   ⌨ On your computerCopy

   ssh root@203.0.113.10

Disable password login

1. Spot the cloud-init file trap

   List the files present in the /etc/ssh/sshd_config.d/ directory and display the contents of 50-cloud-init.conf. This file enables password authentication. Since the SSH server keeps the first directive encountered when reading files in alphabetical order, your own configuration must necessarily be read before it.

   ⌨ On the serverCopy

   ls /etc/ssh/sshd_config.d/
   cat /etc/ssh/sshd_config.d/50-cloud-init.conf

   Expected result

   PasswordAuthentication yes

2. Create the priority SSH configuration file

   Open the nano editor to create the file 00-key-only.conf. The 00 prefix ensures that this file will be processed before 50-cloud-init.conf. Add the directives disabling passwords and limiting root access to keys, then save with Ctrl+X, confirm with O (or Y depending on the language), and press Enter.

   ⌨ On the serverCopy

   nano /etc/ssh/sshd_config.d/00-cles-uniquement.conf

   📄 /etc/ssh/sshd_config.d/00-cles-uniquement.confCopy

   # SSH login by key only
   PasswordAuthentication no
   KbdInteractiveAuthentication no
   PermitRootLogin prohibit-password

3. Test the syntax and apply the configuration

   Run sshd -t to check for syntax errors, then verify the active values with sshd -T. Note that permitrootlogin displays without-password, which corresponds to prohibit-password. If everything is correct, reload the SSH service to apply the new settings without interrupting your session.

   ⌨ On the serverCopy

   sshd -t
   sshd -T | grep -E "^(passwordauthentication|kbdinteractiveauthentication|permitrootlogin)"
   systemctl reload ssh

   Expected result

   permitrootlogin without-password
   passwordauthentication no
   kbdinteractiveauthentication no

Test SSH access

1. Confirm password rejection and key-based access

   Without closing your active session, open a second terminal window on your computer. First try a connection by forcing key rejection with the PubkeyAuthentication=no option: the server must refuse access. Then start a normal connection: key-based authentication should succeed.

   ⌨ On your computerCopy

   ssh -o PubkeyAuthentication=no root@203.0.113.10
   ssh root@203.0.113.10

   Expected result

   root@203.0.113.10: Permission denied (publickey).

Install and verify fail2ban

1. Install fail2ban

   From your session connected to the VPS, update the Debian repositories list with apt update, then install the fail2ban package. On recent Debian versions, fail2ban automatically enables protection for the SSH service as soon as installation is complete.

   ⌨ On the serverCopy

   apt update
   apt install -y fail2ban

2. Check fail2ban status and close the session

   Make sure the fail2ban service is active with systemctl, then query the sshd jail to confirm that filtering works and monitors connections. You can then disconnect with complete peace of mind.

   ⌨ On the serverCopy

   systemctl is-active fail2ban
   fail2ban-client status sshd
   exit

   Expected result

   active
   Status for the jail: sshd
   |- Filter
   |  |- Currently failed: 1
   |  |- Total failed:     3
   |  `- Journal matches:  _SYSTEMD_UNIT=ssh.service + _COMM=sshd
   `- Actions
      |- Currently banned: 0
      |- Total banned:     0
      `- Banned IP list:

Glossary

SSH (Secure Shell)

A secure communication protocol that allows you to connect to and administer a remote server from the command line.

Public key

A key file placed on the remote server to verify the user's identity without transmitting a password.

Private key

A strictly confidential key file kept on your local computer and used to prove your identity to the server.

Cloud-init

An automation tool used during the initial deployment of virtual machines to initialize their network and access settings.

fail2ban

Security software that monitors system logs and temporarily blocks suspicious IP addresses at the firewall level.

Jail

In fail2ban, a set combining a detection filter for abusive attempts and a ban rule for a given service.

Frequently asked questions