SSH Sécurité

Warning

26.10 : ne purgez pas en masse les packages OpenSSH dans l’état rc. Les packages de remplacement peuvent toujours utiliser l’ancienne configuration et la purge peut interrompre SSH. Vérifiez 26.10 problèmes connus et conservez l’accès à la récupération avant la maintenance à distance.

SSH est l’outil principal de gestion des serveurs Linux à distance et l’une des cibles les plus courantes des attaquants. Cet article explique comment renforcer complètement la sécurité de SSH sur Ubuntu 26.04.

Authentification par clé

Génération d’une paire de clés SSH

Générez une paire de clés sur le client (votre ordinateur local) :


# Generate an Ed25519 key (recommended, more secure and faster)
ssh-keygen -t ed25519 -C "your_email@example.com"
 
# If you need compatibility with older systems, use RSA 4096-bit
ssh-keygen -t rsa -b 4096 -C "your_email@example.com"
 
# You will be prompted:
# Enter file in which to save the key (/home/user/.ssh/id_ed25519):
# Enter passphrase (empty for no passphrase):
# It is strongly recommended to set a passphrase

Déploiement de la clé publique sur le serveur


# Method 1: Using ssh-copy-id (recommended)
ssh-copy-id -i ~/.ssh/id_ed25519.pub user@server
 
# Method 2: Manual copy
cat ~/.ssh/id_ed25519.pub | ssh user@server "mkdir -p ~/.ssh && chmod 700 ~/.ssh && cat >> ~/.ssh/authorized_keys && chmod 600 ~/.ssh/authorized_keys"
 
# Method 3: Manual operation
# On the server:
mkdir -p ~/.ssh
chmod 700 ~/.ssh
nano ~/.ssh/authorized_keys
# Paste the public key content
chmod 600 ~/.ssh/authorized_keys

Test de la connexion par clé


# Log in using the key
ssh -i ~/.ssh/id_ed25519 user@server
 
# If configured as the default key, log in directly
ssh user@server

SSH Gestion des clés d’agent


# Start SSH Agent
eval "$(ssh-agent -s)"
 
# Add a key to the Agent (enter the passphrase once to cache it)
ssh-add ~/.ssh/id_ed25519
 
# List loaded keys
ssh-add -l
 
# Remove all cached keys
ssh-add -D

Warning

Avant de modifier la configuration de SSH, assurez-vous que l’authentification par clé a été testée avec succès et gardez votre session SSH actuelle ouverte. Ne fermez l’ancienne connexion qu’après avoir vérifié que vous pouvez vous connecter normalement à partir d’un nouveau terminal, sinon une mauvaise configuration pourrait vous bloquer définitivement hors du serveur.

Renforcement de la configuration du serveur SSH

Modifiez le fichier de configuration du serveur SSH :


sudo nano /etc/ssh/sshd_config

Désactivation de la connexion par mot de passe

Désactivez la connexion par mot de passe uniquement après avoir confirmé que la connexion par clé fonctionne :


# Disable password authentication
PasswordAuthentication no

# Disable empty passwords
PermitEmptyPasswords no

# Disable keyboard-interactive authentication
KbdInteractiveAuthentication no

Désactivation de la connexion root


# Completely prohibit root from logging in via SSH
PermitRootLogin no

# Or only allow root to log in with keys (not recommended)
# PermitRootLogin prohibit-password

Modification du port par défaut


# Use a non-standard port (reduces automated scanning)
Port 2222

Après avoir modifié le port, mettez à jour vos règles de pare-feu :


sudo ufw allow 2222/tcp
sudo ufw delete allow 22/tcp

Restreindre les utilisateurs connectés


# Only allow specific users to log in
AllowUsers admin deployer

# Only allow specific groups to log in
AllowGroups sshusers

# Deny specific users
DenyUsers guest test

Autres paramètres de sécurité


# Limit authentication attempts
MaxAuthTries 3

# Limit concurrent unauthenticated connections
MaxStartups 3:50:10

# Session timeout (disconnect after 300 seconds of inactivity)
ClientAliveInterval 300
ClientAliveCountMax 2

# Disable X11 forwarding (servers usually don't need it)
X11Forwarding no

# Disable Agent forwarding (unless actually needed)
AllowAgentForwarding no

# Disable TCP forwarding (unless actually needed)
AllowTcpForwarding no

# Use strong encryption algorithms
# Note: OpenSSH 10.2 (26.04) already prefers the post-quantum KEX mlkem768x25519-sha256 by default.
# Avoid overriding KexAlgorithms — hardcoding a list freezes the algorithm set
# and may end up dropping newly added post-quantum defaults in the future. Keep the secure defaults.
#
# Only override for troubleshooting or temporary interop with old clients, and always put the post-quantum algorithm first:
# KexAlgorithms mlkem768x25519-sha256,sntrup761x25519-sha512@openssh.com,curve25519-sha256@libssh.org,curve25519-sha256
Ciphers chacha20-poly1305@openssh.com,aes256-gcm@openssh.com,aes128-gcm@openssh.com
MACs hmac-sha2-512-etm@openssh.com,hmac-sha2-256-etm@openssh.com

# Display a login banner
Banner /etc/ssh/banner.txt

# Login grace time
LoginGraceTime 30

Application de la configuration


# Check configuration syntax
sudo sshd -t
 
# Restart SSH service (on Ubuntu the unit is ssh.service; sshd is just an alias)
sudo systemctl restart ssh
 
# Note: on 26.04 ssh listens via socket activation by default,
# so after changing the port you must reload the socket unit:
sudo systemctl daemon-reload
sudo systemctl restart ssh.socket
 
# Important: Test the connection in a new terminal window -- do not close the current one!
ssh -p 2222 user@server

Protection fail2ban

fail2ban surveille les fichiers journaux et bannit automatiquement les adresses IP en cas de plusieurs tentatives de connexion infructueuses.

Installation et configuration


# Install
sudo apt install fail2ban
 
# Start and enable at boot
sudo systemctl enable --now fail2ban

Création d’une configuration locale

Ne modifiez pas directement /etc/fail2ban/jail.conf ; créez plutôt une configuration locale :


sudo nano /etc/fail2ban/jail.local


[DEFAULT]
# Ban duration (seconds)
bantime = 3600
 
# Detection time window (seconds)
findtime = 600
 
# Maximum failed attempts
maxretry = 3
 
# Ban action
banaction = ufw
 
# Ignored IPs (whitelist)
ignoreip = 127.0.0.1/8 ::1 192.168.1.0/24
 
# Email notifications
# destemail = admin@example.com
# sendername = Fail2Ban
# mta = sendmail
# action = %(action_mwl)s
 
[sshd]
enabled = true
port = 2222
filter = sshd
logpath = /var/log/auth.log
maxretry = 3
bantime = 3600

Gestion de fail2ban


# View status
sudo fail2ban-client status
 
# View SSH jail status
sudo fail2ban-client status sshd
 
# View banned IPs
sudo fail2ban-client status sshd | grep "Banned IP"
 
# Manually ban an IP
sudo fail2ban-client set sshd banip 203.0.113.50
 
# Manually unban an IP
sudo fail2ban-client set sshd unbanip 203.0.113.50
 
# View fail2ban logs
sudo tail -f /var/log/fail2ban.log
 
# Reload configuration
sudo fail2ban-client reload

Configuration avancée de fail2ban

Protéger d’autres services :


# Nginx authentication protection
[nginx-http-auth]
enabled = true
filter = nginx-http-auth
port = http,https
logpath = /var/log/nginx/error.log
maxretry = 3
 
# Nginx malicious requests
[nginx-botsearch]
enabled = true
filter = nginx-botsearch
port = http,https
logpath = /var/log/nginx/access.log
maxretry = 2

Configuration client SSH

Créez un fichier de configuration SSH sur le client pour simplifier les connexions :


nano ~/.ssh/config


# Global settings
Host *
    ServerAliveInterval 60
    ServerAliveCountMax 3
    AddKeysToAgent yes

# Production server
Host prod
    HostName 203.0.113.10
    User admin
    Port 2222
    IdentityFile ~/.ssh/id_ed25519_prod

# Jump host
Host bastion
    HostName 203.0.113.20
    User jump
    Port 2222
    IdentityFile ~/.ssh/id_ed25519

# Connect to an internal server via jump host
Host internal
    HostName 10.0.1.50
    User admin
    ProxyJump bastion
    IdentityFile ~/.ssh/id_ed25519

Connexions simplifiées après configuration :


ssh prod
ssh internal

Authentification à deux facteurs

Ajoutez l’authentification à deux facteurs Google Authenticator à SSH :


# Install
sudo apt install libpam-google-authenticator
 
# Each user runs the initialization
google-authenticator
# Follow the prompts to complete setup and scan the QR code
 
# Configure PAM
sudo nano /etc/pam.d/sshd
# Add:
# auth required pam_google_authenticator.so
 
# Configure SSH
sudo nano /etc/ssh/sshd_config
# Set:
# AuthenticationMethods publickey,keyboard-interactive
# KbdInteractiveAuthentication yes
 
sudo systemctl restart ssh

OpenSSH Échange de clés post-quantique

Ubuntu 26.04 est livré avec OpenSSH 10.2, dont l’échange de clés par défaut préfère le schéma hybride post-quantique mlkem768x25519-sha256 (ML-KEM-768 combiné avec X25519), protégeant contre les attaques « récolter maintenant-décrypter-plus tard ».


# Confirm the KEX algorithms supported by your OpenSSH (should include mlkem768x25519-sha256)
ssh -Q kex
 
# Inspect the KEX algorithm actually negotiated for a connection
ssh -v user@server 2>&1 | grep "kex:"

Note

Le KEX post-quantique n’est utilisé que lorsque les deux parties le prennent en charge. Lors de l’interopérabilité avec des clients/serveurs plus anciens (OpenSSH sous 9.0), il revient automatiquement à l’algorithme classique curve25519-sha256, sans aucune configuration manuelle nécessaire. Sauf si vous rencontrez un réel problème de compatibilité, ne remplacez pas la valeur par défaut de KexAlgorithms, pour éviter de supprimer accidentellement la protection post-quantique.

Surveillance et audit


# View successful login records
last -n 20
 
# View failed login records
lastb -n 20
 
# View SSH authentication logs
journalctl -u ssh.service --since today | grep -E "Accepted|Failed"
 
# Count failed login IPs
journalctl -u ssh.service | grep "Failed" | awk '{print $(NF-3)}' | sort | uniq -c | sort -rn | head -20
 
# View current SSH connections
who
w
ss -tnp | grep :22

Liste de contrôle de sécurité

Avant d’appliquer les modifications, confirmez les points suivants :

L’authentification par clé a été configurée et testée
Vous disposez d’un mode d’accès de secours (accès console, autre utilisateur, etc.)
Le pare-feu a été mis à jour avec les règles de port correspondantes
La liste blanche fail2ban inclut vos adresses IP couramment utilisées
Vous avez testé la connexion depuis un nouveau terminal avant de fermer l’ancien
La syntaxe de configuration SSH a été validée avec sshd -t