Durcir un accès SSH

Objectif : réduire la surface d’attaque d’un serveur Linux accessible par SSH depuis Internet — c’est la première cible de tout scan automatisé.

Environnement


Installation	Indifférent — serveur physique, VM (VMware, Proxmox, Hyper-V…) ou VPS cloud : seul l’OS et l’accès `sudo` comptent ici.
Système d’exploitation	Testé sur Debian/Ubuntu (`apt`) ; transposable à RHEL/Fedora (`dnf`, package `fail2ban` identique) ou Arch (`pacman`). Non applicable tel quel à Windows Server (OpenSSH Server y existe mais se configure différemment) ni macOS (rarement utilisé comme serveur SSH exposé).
Côté client	`ssh-keygen` est natif sous Linux et macOS ; sous Windows 10/11, le client OpenSSH est intégré (`ssh`, `ssh-keygen` disponibles nativement dans PowerShell/CMD), sinon via WSL.
Prérequis matériels	Négligeables : `fail2ban` et `sshd` tournent confortablement sur 1 vCPU / 512 Mo de RAM, même partagés avec d’autres services. Aucun disque dédié requis (quelques Mo de logs).

0. Avant de commencer : accès et prérequis

Accès nécessaire : une session SSH déjà ouverte sur le serveur, avec un compte disposant des droits sudo — c’est cet accès qu’on va justement durcir, donc il doit déjà fonctionner avant de commencer. Gardez si possible un accès de secours indépendant ouvert pendant toute la manipulation (console web fournie par l’hébergeur, ou iLO/iDRAC/IPMI pour du matériel physique) : une erreur dans sshd_config peut couper l’accès SSH normal, et ce filet de sécurité permet de corriger sans réinstaller le serveur.

Mettre à jour le système avant toute installation — un prérequis systématique, pas seulement pour ce tutoriel :

sudo apt update && sudo apt upgrade -y

Vérifier les paquets nécessaires plutôt que de supposer qu’ils sont déjà là :

# Le serveur SSH est presque toujours déjà installé — c'est lui qui vous a permis
# de vous connecter — mais on vérifie plutôt que de le tenir pour acquis :
dpkg -l | grep openssh-server || sudo apt install openssh-server -y

# fail2ban (utilisé à l'étape 3) n'est en revanche rarement présent par défaut :
dpkg -l | grep fail2ban

Si la dernière commande ne renvoie rien, c’est normal — fail2ban sera installé à l’étape 3.

1. Désactiver l’authentification par mot de passe

L’authentification par clé publique élimine le risque de bruteforce de mot de passe.

# Sur le poste client, générer une paire de clés (si pas déjà fait)
ssh-keygen -t ed25519 -C "identification-de-la-cle"

# Copier la clé publique sur le serveur
ssh-copy-id utilisateur@serveur

Puis sur le serveur, dans /etc/ssh/sshd_config :

PasswordAuthentication no
PubkeyAuthentication yes
PermitRootLogin no

2. Changer le port par défaut (mesure de réduction de bruit)

Port 2222

Ça ne stoppe pas un attaquant déterminé (un scan de ports le retrouve), mais élimine l’écrasante majorité des bots qui ne scannent que le port 22 — moins de bruit dans les logs, moins de charge.

3. Limiter les tentatives avec fail2ban

sudo apt install fail2ban -y

Configuration minimale dans /etc/fail2ban/jail.local :

[sshd]
enabled = true
port = 2222
maxretry = 3
bantime = 1h
findtime = 10m

Une IP qui échoue 3 fois en 10 minutes est bannie une heure.

4. Restreindre par pare-feu

Si les IP sources sont connues à l’avance (accès depuis un siège fixe, un VPN d’entreprise…), autoriser uniquement ces plages plutôt que tout Internet — voir Pare-feu.

nft add rule inet filter input tcp dport 2222 ip saddr 203.0.113.0/24 accept

5. Appliquer le principe du moindre privilège

Un utilisateur nominatif par personne, jamais de compte partagé.
sudo avec mot de passe pour les actions sensibles plutôt qu’un accès root direct.
Clés SSH avec passphrase, et une clé différente par machine cliente (facilite la révocation ciblée en cas de perte).

Checklist finale

Authentification par clé uniquement (PasswordAuthentication no)
PermitRootLogin no
Port non standard (mesure secondaire, pas une vraie protection)
fail2ban actif sur le service SSH
Accès filtré par pare-feu si les sources sont connues
Un compte nominatif par utilisateur