Renforcer SSH : clés, port, restrictions

Comment configurer sshd : connexion par clé uniquement, restriction des utilisateurs et des adresses, changement de port, et comment ne pas perdre l'accès au cours de l'opération.

Mis à jour le 23 août 2026

SSH est la seule porte d'entrée vers la machine que vous utilisez au quotidien, et la cible principale des attaques par force brute automatisées. Vous le configurez une fois, et ensuite il ne demande plus aucune attention.

Effectuez toutes les modifications dans un fichier séparé, /etc/ssh/sshd_config.d/99-hardening.conf — ainsi une mise à jour de paquet n'écrasera pas votre travail et ne vous laissera pas sans accès.

Des clés plutôt que des mots de passe

PasswordAuthentication no
PubkeyAuthentication yes
KbdInteractiveAuthentication no
PermitEmptyPasswords no

Avant d'appliquer, assurez-vous que la clé fonctionne réellement : connectez-vous avec elle dans une fenêtre séparée. Les clés ajoutées dans l'onglet « Accès » du panneau /hosting/vds/m/<id> vont à l'utilisateur root ; pour les autres utilisateurs, vous devez les placer vous-même dans ~/.ssh/authorized_keys.

Génération d'une clé de votre côté :

ssh-keygen -t ed25519 -C "work laptop"

ed25519 est plus court et plus rapide que RSA. Si votre outil ne le prend pas en charge, utilisez rsa avec une longueur d'au moins 4096 bits.

Qui peut se connecter

PermitRootLogin prohibit-password
AllowUsers artem deploy
MaxAuthTries 3
LoginGraceTime 20
ClientAliveInterval 300
ClientAliveCountMax 2

AllowUsers est la règle la plus efficace après la désactivation des mots de passe : le force brute sur les noms d'autres personnes s'arrête immédiatement. Pour en savoir plus sur root — désactiver la connexion root par mot de passe.

Une restriction par adresse, si vous travaillez depuis un emplacement fixe :

Match Address 203.0.113.5
    PermitRootLogin yes

Changer le port

Déplacer SSH du port 22 vers un port non standard ne vous protège pas d'une attaque ciblée, mais cela élimine presque tout le bruit des scanners automatisés dans vos journaux.

Port 2222

L'ordre des étapes est strictement le suivant :

ufw allow 2222/tcp
sshd -t
systemctl restart ssh
ssh -p 2222 artem@<address>
ufw delete allow 22/tcp

La règle de pare-feu vient avant le redémarrage, et la suppression de l'ancienne uniquement après une connexion réussie sur le nouveau port. Voir aussi ports.

Appliquer et vérifier

sshd -t
sshd -T | grep -Ei "passwordauth|permitroot|allowusers|port"
systemctl restart ssh

sshd -t vérifie la syntaxe, sshd -T affiche la configuration finale effective — celle-là, et non ce que vous avez écrit dans le fichier.

Gardez votre session actuelle ouverte pendant la configuration. Elle survivra à un redémarrage de sshd, et c'est par elle que vous pourrez annuler une modification ratée. Si vous vous enfermez dehors — l'onglet « Console » du panneau fonctionne indépendamment de SSH.

Erreurs courantes

Erreur	Conséquence	Correction
Mots de passe désactivés sans tester la clé	Perte totale de l'accès réseau	Connectez-vous via la console du panneau et restaurez le paramètre
Modification dans le fichier principal par-dessus une ligne de `sshd_config.d`	Le paramètre ne prend pas effet	Vérifiez avec `sshd -T`
Port changé sans règle ufw	Perte d'accès	La règle d'abord, puis le port
Permissions sur `~/.ssh` plus larges que 700	La clé est silencieusement ignorée	`chmod 700 ~/.ssh`, `chmod 600 authorized_keys`
`AllowUsers` sans votre propre nom	Vous vous enfermez dehors	Console du panneau, modifiez le fichier

Dans sshd_config, la première occurrence d'un paramètre l'emporte, et les fichiers de sshd_config.d sont inclus au début. Vérifiez donc le résultat avec sshd -T plutôt que de lire le fichier.

fail2ban éliminera le bruit de force brute restant.