SkyMinds.Net

SSH-Audit examine les algorithmes et paramètres exposés par un serveur SSH. Il aide à repérer des choix anciens et à préparer un durcissement. Son rapport ne remplace ni les mises à jour de la distribution, ni les tests de connexion des clients utilisés.

Installer et lancer SSH-Audit

Sur votre poste d’administration, avec Python et pipx disponibles :

pipx install ssh-audit
ssh-audit -p 22 serveur.example.comLangage du code : CSS (css)

Adaptez le port et utilisez uniquement un serveur que vous êtes autorisé à auditer. Le rapport distingue notamment échanges de clés, clés hôtes, chiffrements et codes d’authentification. Le dépôt officiel décrit aussi les politiques d’audit.

Lire les recommandations dans leur contexte

Un avertissement ne prouve pas à lui seul qu’une compromission a eu lieu. Vérifiez la version du paquet OpenSSH de votre distribution, ses correctifs et les besoins des clients. Les distributions peuvent rétroporter des corrections sans reprendre le numéro de la dernière version amont.

N’appliquez pas une longue liste d’algorithmes copiée depuis un autre serveur : certains noms ou directives peuvent être absents de votre version. Une configuration incompatible peut empêcher le service de se recharger.

Préparer le retour arrière

• Conserver la session SSH actuelle ouverte.
• Vérifier l’accès à une console de secours de l’hébergeur.
• Sauvegarder la configuration et inventorier les fichiers inclus.
• Prévoir un test depuis une seconde session avant de fermer la première.

sudo cp -a /etc/ssh/sshd_config /etc/ssh/sshd_config.avant-audit
sudo /usr/sbin/sshd -t
sudo /usr/sbin/sshd -T

La sauvegarde doit aussi couvrir les fichiers de sshd_config.d si vous les modifiez. sshd -t contrôle la configuration ; sshd -T aide à lire les paramètres effectifs. Les règles Match peuvent nécessiter un contrôle avec le contexte du client.

Conserver l’identité du serveur

Ne supprimez pas systématiquement /etc/ssh/ssh_host_*. Les clés hôtes servent à identifier votre serveur. Leur remplacement provoque des alertes chez les clients et doit être préparé, avec diffusion des nouvelles empreintes par un canal fiable.

Une rotation peut être nécessaire si une clé est compromise ou ne convient plus, mais elle ne se justifie pas simplement parce qu’elle a été générée automatiquement. Pour comprendre les alertes associées, consultez le diagnostic des clés d’hôte SSH différentes.

Modifier, valider, puis recharger

Faites une modification à la fois. Vérifiez les directives prises en charge par votre version et leur priorité dans les fichiers inclus. Validez ensuite la configuration avant de recharger le service.

sudo /usr/sbin/sshd -t
sudo systemctl reload ssh

L’exemple utilise le service ssh d’Ubuntu/Debian ; d’autres distributions utilisent sshd. Si la validation échoue, corrigez la configuration et ne rechargez pas le service. Ouvrez ensuite une seconde connexion et testez les usages nécessaires : shell, SFTP, rsync ou automatisations.

Limiter les accès sans provoquer de coupure

Définissez le filtrage réseau selon les adresses et usages attendus. Évitez d’empiler des règles iptables copiées sans examiner le pare-feu existant et IPv6. Une limite de connexions mal dimensionnée peut aussi bloquer des utilisateurs légitimes derrière une même adresse.

Après toute modification, relancez l’audit et comparez le résultat. Un bon score n’est pas une preuve globale de sécurité. Pour les transferts automatisés, voir la configuration SSH par clé pour rsync.

Documentation

SSH-Audit : projet et options ; OpenSSH : validation de configuration ; OpenSSH : gestion des clés.