Qu'est-ce que SSH ?

SSH (Secure Shell) est un protocole cryptographique permettant de se connecter de manière sécurisée à des systèmes distants. Il établit un canal chiffré entre le client et le serveur pour protéger les échanges contre l'interception. Malgré sa conception sécurisée, une configuration par défaut insuffisante expose les infrastructures à des risques importants : accès non autorisés, attaques par force brute, compromission de comptes privilégiés et exploitation de vulnérabilités.

Communication SSH pour création de session sécurisée
Etablissement d'une session sécurisée

Recommandations

Backup de la configuration de base

Lors du durcissement SSH, enregistrez votre configuration originale et pensez à tester chaque modification sur un environnement de test avant déploiement en production. Une mauvaise configuration peut entraîner une perte d'accès au serveur.

Important : Toute modification du fichier sshd_config nécessite un redémarrage du service SSH pour être prise en compte. Avant de fermer votre session actuelle, testez toujours la connexion depuis une nouvelle fenêtre pour éviter de vous bloquer.

Sur Linux : 
sudo systemctl restart sshd
sudo systemctl status sshd # Vérifier le statut
Sur Windows : 
Restart-Service sshd
Get-Service sshd # Vérifier le statut

Désactiver l'accès root direct

Autoriser la connexion directe en tant que root facilite la compromission totale du système. Un attaquant qui obtient le mot de passe root via brute force ou fuite de données bénéficie immédiatement de privilèges maximaux. En désactivant l'accès root direct, on impose une élévation de privilèges après connexion (via sudo ou su), ce qui laisse une trace dans les logs et ajoute une couche de protection.

Éditer le fichier de configuration SSH : 
sudo nano /etc/ssh/sshd_config
Modifier le paramètre suivant : 
PermitRootLogin no

Forcer l'authentification par clé publique

L'authentification par mot de passe est vulnérable aux attaques par force brute et par dictionnaire. Les botnets scannent constamment Internet à la recherche de ports SSH ouverts et tentent des milliers de combinaisons de mots de passe. L'authentification par clé publique élimine complètement ce vecteur d'attaque en exigeant la possession de la clé privée, rendant les tentatives de force brute inefficaces.

Générer une paire de clés SSH (sur le poste client) : 
ssh-keygen -t ed25519 -C "user@entreprise.com"
Pour une compatibilité étendue (serveurs anciens), utiliser RSA 4096 bits : 
ssh-keygen -t rsa -b 4096 -C "user@entreprise.com"
Copier la clé publique sur le serveur : 
ssh-copy-id -i ~/.ssh/mykey user@serveur

Ou alors vous pouvez ajouter la clé directement dans le home de l’utilisateur voulu dans authorized_keys.

Désactiver l'authentification par mot de passe dans sshd_config : 
PasswordAuthentication noPubkeyAuthentication yesChallengeResponseAuthentication no

Interdire les mots de passe vides

Même si l'authentification par mot de passe reste temporairement activée (phase de transition), il est essentiel de s'assurer qu'aucun compte ne possède un mot de passe vide. Un compte sans mot de passe est une porte ouverte triviale pour un attaquant.

PermitEmptyPasswords no

Limiter les utilisateurs autorisés

Autoriser tous les comptes utilisateurs (même les comptes locaux) à se connecter via SSH augmente inutilement la surface d'attaque. En définissant explicitement quels utilisateurs ou groupes peuvent utiliser SSH, on réduit les cibles potentielles et on limite l'impact d'une compromission de compte.

Ajouter dans sshd_config : 
AllowUsers admin1 admin2 
AllowGroups ssh-users # ou pour autoriser un groupe entier

Les directives AllowUsers, DenyUsers, AllowGroups, et DenyGroups sont traitées dans cet ordre.

Changer le port par défaut

Pourquoi ? Laisser SSH sur le port 22 expose le service aux scans automatisés. Bien que ce ne soit pas une protection forte contre un attaquant déterminé, changer le port réduit drastiquement le bruit des tentatives automatisées et les journaux saturés de connexions échouées.

#Port 2222
Port 2222

Important : pensez à autoriser le nouveau port dans votre pare-feu (iptables, ufw, Windows Firewall). Testez la connexion sur le nouveau port avant de fermer votre session actuelle.

Exemple de connexion avec port personnalisé : 
ssh -p 2222 utilisateur@serveur

Utiliser uniquement le protocole SSH version 2

SSHv1 contient des failles de sécurité cryptographiques connues qui permettent des attaques de type man-in-the-middle et déchiffrement. SSHv2 corrige ces vulnérabilités et est désormais le standard. Cette directive est souvent déjà configurée par défaut sur les systèmes récents, mais il est important de la vérifier.

Protocol 2

Renforcer les algorithmes cryptographiques

Des algorithmes de chiffrement obsolètes ou faibles (MD5, SHA1, DES, 3DES) peuvent être compromis par des attaquants disposant de ressources suffisantes. En limitant SSH aux algorithmes modernes et robustes, on garantit que même un attaquant interceptant le trafic ne pourra pas le déchiffrer.

KexAlgorithms curve25519-sha256,curve25519-sha256@libssh.org,diffie-hellman-group-exchange-sha256
Ciphers chacha20-poly1305@openssh.com,aes256-gcm@openssh.com,aes128-gcm@openssh.com,aes256-ctr,aes192-ctr,aes128-ctr
MACs hmac-sha2-512-etm@openssh.com,hmac-sha2-256-etm@openssh.com,hmac-sha2-512,hmac-sha2-256

Configurer les timeouts de session

Les sessions SSH inactives représentent un risque de sécurité. Un administrateur ayant laissé une session ouverte sur un poste non verrouillé expose ses privilèges. Les timeouts forcent la déconnexion des sessions inactives, limitant cette fenêtre d'opportunité pour un attaquant.

Le serveur envoie un message au client toutes les ClientAliveInterval secondes. Si aucune réponse n'est reçue après ClientAliveCountMax tentatives, la connexion est fermée.

ClientAliveInterval 300 
ClientAliveCountMax 2

Dans cet exemple, une session inactive sera déconnectée après 10 minutes (300 secondes × 2 tentatives).

Déployer Fail2Ban (Linux)

Pourquoi ? Malgré toutes les protections, des tentatives de connexion échouées répétées peuvent saturer les journaux et consommer des ressources. Fail2Ban analyse les logs SSH et bannit automatiquement (via iptables) les adresses IP montrant un comportement malveillant (tentatives répétées de connexion échouées), bloquant ainsi les attaques par force brute en temps réel.

Installation : 
sudo apt install fail2ban  # Debian/Ubuntu
sudo yum install fail2ban  # RHEL/CentOS
Configuration de base dans /etc/fail2ban/jail.local : 
[sshd]
enabled = true
port = 2222
filter = sshd
logpath = /var/log/auth.log
maxretry = 3
bantime = 3600
findtime = 600

Cette configuration bannit pendant 1 heure toute IP ayant échoué 3 tentatives de connexion en 10 minutes.

sudo systemctl enable fail2ban
sudo systemctl start fail2ban

Informations complémentaires

Même avec toutes les configurations SSH précédentes, exposer le service à l'ensemble d'Internet reste risqué. Restreindre l'accès SSH aux adresses IP de confiance uniquement (VPN, réseaux internes, adresses fixes d'administration) réduit drastiquement la surface d'attaque.

L’authentification par clé SSH améliore fortement la sécurité, mais elle ne protège pas contre tous les scénarios. Une clé privée peut être compromise (vol d’ordinateur portable, compromission du poste client). Dès lors, l’ajout d’un second facteur d’authentification MFA, via Google Authenticator, YubiKey ou autre peut s’avérer interessant.

Pour les environnements hautement sensibles, envisagez l'utilisation de bastions SSH (jump hosts) pour centraliser et contrôler tous les accès distants.

← Retour aux articles

Besoin d'un audit de sécurité ou d'un accompagnement sur mesure ?

Découvrir nos services →