Skip to content

SSH Hardening & Key-Based Authentication

Admin
October 1, 2026
5 min read

Securing remote SSH access is the first and most critical defense for any internet-facing Linux VPS. Follow these modular configuration steps to lock down port 22:

Step 1: Generate an Ed25519 Cryptographic Key Pair

01

Generate an Ed25519 Cryptographic Key Pair

Local Machine

Avoid legacy RSA keys. Modern Ed25519 keys offer superior cryptographic resilience with compact 256-bit key length and faster handshake speeds.

Terminal window
ssh-keygen -t ed25519 -C "admin@configcorner"
❯ View Expected Console Output

Generating public/private ed25519 key pair.
Enter file in which to save the key (/home/user/.ssh/id_ed25519):
Enter passphrase (empty for no passphrase): [PROTECTED]
Your identification has been saved in /home/user/.ssh/id_ed25519
Your public key has been saved in /home/user/.ssh/id_ed25519.pub

Step 2: Deploy Public Key to Target VPS

02

Deploy Public Key to Target VPS

Transfer

Append your local public key to the remote server’s ~/.ssh/authorized_keys file using ssh-copy-id. Before changing server policy, open a second terminal and verify that a new session succeeds with the key. Keep the current administrative session open as a recovery path.

Terminal window
ssh-copy-id -i ~/.ssh/id_ed25519.pub user@vps-ip-address
# In a second terminal, require public-key authentication for this test:
ssh -o PreferredAuthentications=publickey \
-o PasswordAuthentication=no user@vps-ip-address
❯ View Expected Console Output

/usr/bin/ssh-copy-id: INFO: Source of key(s) to be installed: “id_ed25519.pub”
Number of key(s) added: 1
Now try logging into the machine with: “ssh user@vps-ip-address”

Step 3: Create an Early-Loaded SSH Hardening Drop-In

03

Disable Password Authentication & Enforce Key-Only

Hardening

First confirm that the main SSH configuration includes /etc/ssh/sshd_config.d/*.conf and check existing files for earlier active values. OpenSSH generally keeps the first value it reads, so a file named 99-… may not override an earlier drop-in. This example uses an early filename; still verify the effective settings before reloading.

Terminal window
sudo install -d -m 0755 /etc/ssh/sshd_config.d
sudo tee /etc/ssh/sshd_config.d/00-local-hardening.conf >/dev/null <<'EOF'
PasswordAuthentication no
PermitRootLogin no
PubkeyAuthentication yes
AuthenticationMethods publickey
MaxAuthTries 3
EOF
sudo sshd -t
sudo sshd -T | grep -E '^(passwordauthentication|permitrootlogin|pubkeyauthentication|authenticationmethods|maxauthtries) '

Step 4: Validate Configuration and Reload SSH

04

Validate Configuration and Reload SSH

Verification

Validate syntax and effective values. If the server uses Match blocks, also check the effective configuration for the actual user, client address, and host. Reload whichever unit is active on this distribution; reload keeps the current SSH session available while new connections use the updated configuration.

Terminal window
sudo sshd -t
sudo sshd -T | grep -E '^(passwordauthentication|permitrootlogin|pubkeyauthentication|authenticationmethods|maxauthtries) '
if systemctl is-active --quiet ssh.service; then
sudo systemctl reload ssh.service
elif systemctl is-active --quiet sshd.service; then
sudo systemctl reload sshd.service
else
echo 'No active ssh.service or sshd.service found; identify the service name before applying changes.'
exit 1
fi
❯ View Expected Console Output

passwordauthentication no
permitrootlogin no
pubkeyauthentication yes
authenticationmethods publickey
maxauthtries 3
● sshd.service - OpenSSH server
   Active: active (running)

Comments