Introduction : Au-delà des Fondamentaux
Ce guide suppose que les bases de la sécurité SSH sont déjà en place (authentification par clé, `PermitRootLogin no`, etc.). Nous allons nous concentrer sur des techniques de durcissement avancées pour les environnements de production qui exigent un niveau de sécurité maximal.
Section 1 : Authentification Multi-Facteurs (MFA) avec PAM
L'authentification par clé seule est robuste, mais elle reste vulnérable au vol de clé privée. Le MFA ajoute une couche de sécurité "quelque chose que vous possédez" (un téléphone, une clé hardware).
Exemple avec Google Authenticator (TOTP) :
- Installation du module PAM :
sudo apt-get install libpam-google-authenticator - Configuration par utilisateur : Lancez
google-authenticatorpour l'utilisateur concerné et scannez le QR code avec votre application TOTP. - Modification de la configuration PAM pour SSHD (
/etc/pam.d/sshd) :# AJOUTEZ CETTE LIGNE (souvent après @include common-auth) auth required pam_google_authenticator.so - Modification de la configuration SSHD (
/etc/ssh/sshd_config) pour activer l'authentification interactive :# Doit être à 'yes' ChallengeResponseAuthentication yes # Spécifie les méthodes requises. La clé ET le code TOTP seront demandés. AuthenticationMethods publickey,keyboard-interactive:pam
Note sur les certificats SSH : Pour une gestion à l'échelle de l'entreprise, l'utilisation d'une Autorité de Certification (CA) SSH pour signer les clés des utilisateurs est la pratique recommandée, éliminant le besoin de gérer les fichiers `authorized_keys` sur chaque serveur.
Section 2 : Confinement des Utilisateurs et Isolation des Sessions
Un utilisateur authentifié ne devrait avoir accès qu'aux ressources qui lui sont strictement nécessaires.
- Mettre en place une prison `chroot` : Idéal pour les comptes de service ou les accès SFTP. L'utilisateur est confiné dans un répertoire spécifique sans pouvoir voir le reste du système de fichiers.
Important : Le répertoire `ChrootDirectory` et tous ses parents doivent appartenir à `root` et ne pas être modifiables par d'autres utilisateurs.# Dans /etc/ssh/sshd_config # Le sous-système sftp doit pointer vers internal-sftp Subsystem sftp internal-sftp # Créez un bloc Match pour les utilisateurs ou groupes à confiner Match Group sftp-users # Force la connexion en SFTP uniquement ForceCommand internal-sftp # Spécifie le répertoire racine de la prison ChrootDirectory /sftp/%u # Interdit le tunneling AllowTcpForwarding no X11Forwarding no - Restreindre les capacités d'une clé SSH : Dans le fichier `authorized_keys`, vous pouvez préfixer une clé pour limiter drastiquement ses permissions.
# Clé autorisée uniquement depuis une IP, sans port forwarding, et forçant l'exécution d'un script from="192.168.1.100",no-port-forwarding,no-x11-forwarding,command="/usr/local/bin/backup.sh" ssh-rsa AAAA...
Section 3 : Cryptographie de Pointe et Durcissement du Protocole
Les standards cryptographiques évoluent. Il est essentiel de désactiver les algorithmes obsolètes et de forcer l'utilisation des plus robustes.
- Générer des clés d'hôte modernes : Supprimez les anciennes clés DSA et ECDSA et ne générez que des clés Ed25519, plus performantes et sécurisées.
# Supprimer les anciennes clés rm /etc/ssh/ssh_host_* # Régénérer uniquement les clés modernes ssh-keygen -t rsa -b 4096 -f /etc/ssh/ssh_host_rsa_key -N "" ssh-keygen -t ed25519 -f /etc/ssh/ssh_host_ed25519_key -N "" - Renforcer l'échange de clés Diffie-Hellman : Le fichier `moduli` contient les paramètres pour les groupes DH. Les groupes de moins de 2048 bits sont considérés comme faibles.
# Évaluez votre fichier moduli awk '$5 < 2048' /etc/ssh/moduli # Générez un nouveau fichier plus robuste (peut prendre du temps) ssh-keygen -G /etc/ssh/moduli.safe -b 4096 ssh-keygen -T /etc/ssh/moduli.final -f /etc/ssh/moduli.safe mv /etc/ssh/moduli.final /etc/ssh/moduli - Spécifier des algorithmes de premier ordre dans
sshd_config: Définissez explicitement une liste d'algorithmes modernes et retirez les anciens (CBC, SHA-1).# Exemple de configuration moderne KexAlgorithms curve25519-sha256@libssh.org,diffie-hellman-group-exchange-sha256 Ciphers chacha20-poly1305@openssh.com,aes256-gcm@openssh.com MACs hmac-sha2-512-etm@openssh.com,hmac-sha2-256-etm@openssh.com
Section 4 : Audit et Surveillance Actifs
La surveillance passive avec `fail2ban` est un bon début. Une approche active est nécessaire pour la détection d'intrusions.
- Utiliser le Linux Audit Daemon (`auditd`) : `auditd` peut surveiller les appels système et les accès aux fichiers de manière très granulaire.
# Règle pour surveiller toute modification des fichiers de conf SSH -w /etc/ssh/ -p wa -k ssh_config_changes - Alertes de connexion en temps réel : Utilisez un script PAM ou un `ForceCommand` pour déclencher une alerte (par email, webhook, etc.) à chaque connexion réussie.
Le script `ssh_alert.sh` recevra des informations sur la connexion via des variables d'environnement (`$SSH_CLIENT`) et pourra ensuite envoyer une notification.# Dans sshd_config, pour un utilisateur spécifique Match User bruno ForceCommand /usr/local/bin/ssh_alert.sh