Maîtriser et Sécuriser SSH sur un Serveur Linux

Introduction : Votre Porte d'Entrée Sécurisée vers Votre Serveur

Bienvenue dans le monde de l'administration système ! L'un des outils les plus fondamentaux et puissants à votre disposition est le protocole SSH, ou Secure Shell. Pensez y comme un tunnel blindé et chiffré qui vous permet de vous connecter à vos machines distantes, d'exécuter des commandes, de transférer des fichiers et de gérer l'ensemble de votre infrastructure, le tout de manière sécurisée sur un réseau potentiellement non sécurisé comme Internet.

Configurer correctement SSH n'est pas une simple formalité ; c'est la première et la plus importante ligne de défense pour la sécurité de votre serveur. Considérez que votre serveur est constamment la cible de scans automatisés. Notre objectif n'est pas seulement de configurer SSH, mais de le transformer en un rempart qui ignore 99% de ce bruit de fond malveillant. Il s'agit du remplaçant moderne et sécurisé des anciens protocoles vulnérables comme Telnet ou FTP, qui transmettaient les informations, y compris les mots de passe, en clair. Maîtriser SSH, c'est s'assurer que seules les personnes autorisées peuvent franchir la porte de votre forteresse numérique.

Les Fondations : L'Authentification par Clé SSH

1.1. Pourquoi les Clés SSH sont Supérieures aux Mots de Passe

Au cœur de SSH se trouve un mécanisme d'authentification bien plus robuste que le traditionnel mot de passe : la cryptographie asymétrique. Le principe est simple : vous générez une paire de clés numériques.

• Une clé privée : Elle vous appartient, reste secrète sur votre machine et ne doit jamais être partagée. C'est votre preuve d'identité unique.
• Une clé publique : Vous pouvez la distribuer librement. Vous l'installerez sur les serveurs auxquels vous souhaitez vous connecter.

Ce système offre deux avantages majeurs par rapport à un simple mot de passe :

• Sécurité accrue : Une clé SSH est une chaîne de caractères extrêmement longue et complexe, la rendant mathématiquement quasi impossible à deviner, même avec des attaques par force brute qui testent des milliards de combinaisons.
• Confort d'utilisation : Une fois la configuration initiale effectuée, vous pouvez vous connecter à vos serveurs sans avoir à saisir votre mot de passe à chaque fois, tout en bénéficiant d'une sécurité supérieure.

Maintenant que la théorie est claire, passons à la pratique et créons votre propre paire de clés.

Étape 1 : Vérifier l'Existence de Clés SSH sur Votre Poste Client

Avant de créer une nouvelle paire de clés, il est judicieux de vérifier si vous n'en possédez pas déjà une. Sur votre machine locale (votre ordinateur personnel), ouvrez un terminal et exécutez la commande suivante :

ls -l ~/.ssh/id_*.pub

Si cette commande retourne une erreur "Aucun fichier ou dossier de ce type", cela signifie que vous n'avez pas de clés existantes et pouvez passer à l'étape suivante. Si elle affiche un ou plusieurs noms de fichiers (comme id_rsa.pub ou id_ed25519.pub), vous avez déjà une paire de clés. Vous pouvez soit l'utiliser, soit en créer une nouvelle, dédiée à un usage spécifique.

Étape 2 : Générer une Nouvelle Paire de Clés SSH Sécurisée

Pour créer une nouvelle paire de clés, nous allons utiliser l'utilitaire ssh-keygen.

1. Choisir le bon algorithme : Conformément aux recommandations de sécurité modernes, l'algorithme ed25519 est le choix privilégié. Il est rapide, performant et extrêmement sécurisé. Une alternative robuste est RSA avec une taille de clé d'au moins 4096 bits.
2. Exécuter la commande : Dans votre terminal, lancez la commande suivante pour générer une clé ed25519. Remplacez le commentaire par votre propre adresse e-mail pour identifier facilement la clé plus tard.
   • -t ed25519 : Spécifie le type d'algorithme à utiliser.
   • -a 100 : Augmente le nombre de tours de la fonction de dérivation de clé. Cet ajout crucial rend votre clé privée beaucoup plus résistante aux attaques par force brute si le fichier venait à être volé.
   • -C "..." : Ajoute un Commentaire à la clé, généralement votre e-mail.
3. Protéger votre clé avec une phrase secrète : Le programme vous demandera ensuite d'entrer une phrase secrète (passphrase). C'est une étape cruciale. Cette phrase secrète chiffre votre clé privée sur votre disque dur. Ainsi, même si quelqu'un parvenait à voler le fichier de votre clé privée, il ne pourrait pas l'utiliser sans connaître cette phrase secrète. Choisissez-en une solide et mémorable.

Étape 3 : Copier Votre Clé Publique sur le Serveur

Pour que le serveur vous reconnaisse, il doit connaître votre clé publique.

1. La méthode recommandée : ssh-copy-id C'est l'outil le plus simple et le plus fiable pour cette tâche. Il copie votre clé publique sur le serveur et s'assure que les permissions des fichiers et dossiers sont correctes. Vous devrez saisir le mot de passe de votre utilisateur sur le serveur pour cette dernière fois.
2. L'alternative manuelle Si la commande ssh-copy-id n'est pas disponible, vous pouvez le faire manuellement. Affichez d'abord le contenu de votre clé publique sur votre machine locale :
3. Copiez l'intégralité de la sortie (la longue ligne commençant par ssh-ed25519...). Connectez-vous ensuite à votre serveur (avec votre mot de passe), et collez cette ligne dans le fichier ~/.ssh/authorized_keys. S'il n'existe pas, vous devrez le créer.

Étape 4 : Tester Votre Connexion par Clé

Maintenant que tout est en place, testons la connexion. Depuis votre machine locale, exécutez :

ssh utilisateur@adresse_du_serveur

Si tout s'est bien passé, le système devrait vous demander la phrase secrète de votre clé SSH (et non plus le mot de passe de votre compte utilisateur). Si vous n'avez pas défini de phrase secrète, la connexion s'établira instantanément.

Vous avez maintenant mis en place une authentification robuste. Il est temps de passer au niveau supérieur et de verrouiller complètement votre serveur.

Le Durcissement : Verrouiller Votre Serveur SSH

Le Fichier de Configuration Clé : /etc/ssh/sshd_config

Le comportement du service SSH on votre serveur est entièrement contrôlé par le fichier /etc/ssh/sshd_config. Pour le modifier, vous aurez besoin des droits d'administrateur. Nous utiliserons nano, un éditeur de texte simple :

sudo nano /etc/ssh/sshd_config

Important : Après chaque modification de ce fichier, vous devrez redémarrer le service SSH pour que les changements prennent effet.

# Pour Debian/Ubuntu
sudo systemctl restart ssh

# Pour RHEL/CentOS
sudo systemctl restart sshd

Mesure 1 : Interdire l'Authentification par Mot de Passe

C'est la mesure la plus efficace que vous puissiez prendre. Une fois que votre connexion par clé est fonctionnelle, il n'y a plus aucune raison de laisser l'authentification par mot de passe active. Cela élimine totalement le risque d'attaques par force brute.

Dans /etc/ssh/sshd_config, trouvez et modifiez les lignes suivantes pour qu'elles correspondent à :

# Interdit formellement l'usage de mots de passe
PasswordAuthentication no
# Désactive les mécanismes de type "challenge-réponse"
ChallengeResponseAuthentication no
# Empêche l'utilisation de modules d'authentification externes (PAM)
UsePAM no

L'option UsePAM no désactive le framework Pluggable Authentication Modules. Cela garantit que seule l'authentification native de SSH (nos clés publiques) est utilisée, fermant ainsi des portes dérobées potentielles que PAM pourrait introduire (authentification biométrique, etc.).

Mesure 2 : Désactiver l'Accès Direct de l'Utilisateur root

Permettre une connexion directe avec l'utilisateur root est une mauvaise pratique de sécurité. Un attaquant n'aurait qu'à deviner un seul secret pour obtenir un contrôle total. Le principe de moindre privilège impose de se connecter avec un utilisateur standard, puis d'élever ses privilèges avec sudo pour les tâches administratives.

Modifiez la ligne suivante :

PermitRootLogin no

Mesure 3 : Changer le Port par Défaut

Par défaut, SSH écoute sur le port 22. Tous les scripts malveillants automatisés sur Internet ciblent ce port en priorité. Changer le port ne renforce pas la cryptographie, mais cela réduit drastiquement le "bruit" des scans dans vos journaux système et vous rend moins visible.

1. Changer le port dans sshd_config :
2. (Choisissez un port non utilisé, généralement au-dessus de 1024).
3. Mettre à jour le pare-feu : ACTION CRITIQUE : Si vous oubliez de mettre à jour votre pare-feu, vous serez définitivement bloqué à l'extérieur de votre propre serveur après avoir redémarré le service SSH. N'omettez jamais cette étape.

Sur les distributions récentes, le service SSH peut être géré par un socket systemd, ignorant la directive Port dans sshd_config. Si le changement de port ne fonctionne pas, créez un fichier de surcharge pour le socket :

sudo mkdir -p /etc/systemd/system/ssh.socket.d
sudo bash -c 'cat > /etc/systemd/system/ssh.socket.d/listen.conf <<EOF
[Socket]
ListenStream=
ListenStream=2200
EOF'

Puis rechargez systemd et redémarrez SSH :

sudo systemctl daemon-reload
sudo systemctl restart ssh # ou sshd sur RHEL/CentOS

Mesure 4 : Renforcer les Algorithmes Cryptographiques

Pour une sécurité maximale, vous pouvez forcer votre serveur à n'utiliser que les algorithmes les plus modernes. La configuration suivante, inspirée des bonnes pratiques actuelles et des recommandations d'organismes comme l'ANSSI ou Mozilla, constitue une base extrêmement solide. Chaque directive joue un rôle précis :

• KexAlgorithms (Key Exchange) : Définit comment le client et le serveur négocient de manière sécurisée une clé de session secrète au début de la connexion.
• Ciphers (Chiffrements) : Liste les algorithmes de chiffrement symétrique autorisés pour crypter les données échangées pendant la session.
• MACs (Message Authentication Codes) : Assure l'intégrité des messages, en vérifiant qu'ils n'ont pas été altérés en transit.

Ajoutez ces lignes à votre fichier /etc/ssh/sshd_config :

# Algorithmes d'échange de clés
KexAlgorithms curve25519-sha256@libssh.org

# Algorithmes de chiffrement
Ciphers chacha20-poly1305@openssh.com,aes256-gcm@openssh.com

# Codes d'authentification de message
MACs hmac-sha2-512-etm@openssh.com,hmac-sha2-256-etm@openssh.com

Avant de Redémarrer : Toujours Tester la Configuration !

Modifier la configuration SSH est une opération délicate. Une simple erreur de syntaxe peut vous empêcher de vous reconnecter. Avant de redémarrer le service, utilisez toujours cette commande pour vérifier votre fichier de configuration :

sudo sshd -t

Si la commande ne retourne aucune erreur, vous pouvez redémarrer le service SSH. Si elle signale un problème, elle vous indiquera la ligne à corriger.

Pro-Tip : Gardez toujours votre session SSH actuelle ouverte. Essayez de vous connecter dans une nouvelle fenêtre de terminal après avoir testé la configuration et avant de redémarrer le service. C'est votre filet de sécurité pour ne pas vous retrouver bloqué dehors.

Votre serveur est maintenant configuré de manière statique et sécurisée. Passons à la défense active pour bloquer les attaquants en temps réel.

La Défense Active : Surveiller et Bannir les Attaques

Installation et Configuration de Fail2ban

Fail2ban surveille les journaux de votre serveur (y compris ceux de SSH) et, s'il détecte des tentatives de connexion échouées répétées depuis une même adresse IP, il la bannit automatiquement en créant une règle de pare-feu temporaire.

1. Installation (sur Debian/Ubuntu) :
2. Configuration de base pour SSH : Créez un fichier de configuration local. Fail2ban lira ce fichier en priorité, ce qui évite que vos modifications soient écrasées lors des mises à jour.
3. Ajoutez-y la configuration suivante :
4. Redémarrage du service :
5. Fail2ban est maintenant actif et protège votre serveur.

Consulter les Tentatives de Connexion

Même avec une défense automatisée, il est bon de savoir comment vérifier manuellement les journaux pour voir qui a tenté de se connecter.

Après avoir désactivé l'authentification par mot de passe, ces entrées de log devraient disparaître. Pour une surveillance plus globale et en temps réel de l'activité du service SSH (y compris les tentatives de connexion par clé échouées), utilisez :

sudo journalctl -u sshd -f

Vous avez maintenant un système de défense complet. Mais que faire si quelque chose ne fonctionne pas comme prévu ?

Dépannage : Résoudre les Problèmes Courants

Permission denied (publickey) : que faire ?

C'est l'erreur la plus fréquente après la mise en place des clés. Voici les causes possibles :

• La clé publique n'est pas correcte : La clé n'a pas été ajoutée correctement au fichier ~/.ssh/authorized_keys sur le serveur. Vérifiez que le contenu correspond exactement à votre fichier .pub.
• Les permissions sont incorrectes : SSH est très strict sur les permissions pour des raisons de sécurité. Le dossier .ssh et son contenu ne doivent pas être modifiables par d'autres utilisateurs. Appliquez les permissions correctes sur le serveur :
• Le client n'utilise pas la bonne clé privée : C'est un cas fréquent si vous gérez plusieurs clés (ex: id_ed25519, id_rsa, une pour le travail, une pour un projet). Par défaut, le client SSH peut essayer une clé qui n'est pas la bonne. Spécifiez explicitement le fichier de la clé privée à utiliser avec l'option -i :

J'obtiens un avertissement REMOTE HOST IDENTIFICATION HAS CHANGED!

Ce message est une protection de sécurité, pas une erreur. Il signifie que la "signature" (la clé d'hôte) du serveur a changé depuis votre dernière connexion. Cela se produit légitimement après une réinstallation du système d'exploitation du serveur. Cependant, cela peut aussi signaler une attaque de type "man-in-the-middle". Si vous êtes certain que le changement est légitime, supprimez simplement l'ancienne signature de votre fichier known_hosts local avec cette commande :

ssh-keygen -R "adresse_du_serveur"

À la prochaine connexion, SSH vous demandera de valider la nouvelle signature.

Ma clé générée avec PuTTYgen (Windows) n'est pas valide.

PuTTYgen, l'outil de génération de clés de PuTTY, enregistre par défaut les fichiers de clé dans un format propriétaire qui n'est pas compatible avec les serveurs OpenSSH standards. La solution est simple : ne copiez pas le contenu du fichier sauvegardé. Copiez plutôt le texte qui s'affiche directement dans la fenêtre principale de PuTTYgen, dans le champ intitulé "Public key for pasting into OpenSSH authorized_keys file". C'est ce format que vous devez coller dans votre fichier authorized_keys sur le serveur.

Conclusion : Une Forteresse Bien Gardée

En suivant ce guide, vous avez transformé un serveur potentiellement exposé en une forteresse numérique sécurisée. La sécurité n'est pas un produit unique, mais un processus continu basé sur de bonnes pratiques.

Pour résumer, voici les 3 règles d'or de la sécurité SSH :

1. Utilisez toujours des clés SSH et protégez systématiquement votre clé privée avec une phrase secrète robuste.
2. Désactivez systématiquement l'authentification par mot de passe et l'accès direct de l'utilisateur root.
3. Surveillez activement votre serveur avec des outils de défense comme Fail2ban pour bloquer les menaces en temps réel.

L'adoption de ces pratiques est le fondement d'une administration système non seulement sécurisée, mais aussi professionnelle et sereine. Votre serveur est désormais entre de bonnes mains : les vôtres.