Comment installer et configurer SSH sur Linux : un guide de sécurité complet pour 2025

SSH est le point d’accès le plus critique de votre serveur. Une configuration SSH mal paramétrée peut être compromise en moins de cinq minutes par des bots automatisés qui analysent internet. Que vous gériez un environnement VPS Hosting, une machine bare-metal ou une instance cloud, sécuriser SSH correctement dès le premier jour est non négociable.

Dans ce guide, vous apprendrez comment installer OpenSSH, le configurer de manière sécurisée, mettre en place une authentification par clé et appliquer des techniques de durcissement de niveau production — le tout sur un serveur Linux en 2025.

Qu’est-ce que SSH et pourquoi est-ce important ?

SSH (Secure Shell) est un protocole réseau cryptographique qui permet aux utilisateurs de se connecter de manière sécurisée à un système distant via un réseau non sécurisé tel qu’internet. Toutes les données transmises entre le client et le serveur sont entièrement chiffrées, ce qui en fait la norme industrielle pour la gestion de serveurs à distance.

Par défaut, SSH fonctionne sur le port 22 et prend en charge :

• La connexion à distance aux serveurs et machines virtuelles
• Le transfert de fichiers sécurisé via SCP et SFTP
• L’exécution de commandes à distance et l’automatisation par scripts
• La redirection de port et le tunneling pour le routage sécurisé du trafic
• La redirection X11 pour l’accès aux applications graphiques

SSH est votre interface d’administration principale. Traitez-la en conséquence.

Étape 1 : Installation du serveur OpenSSH

La plupart des distributions Linux modernes sont livrées avec OpenSSH préinstallé. S’il est absent, installez-le en utilisant le gestionnaire de paquets approprié à votre distribution.

Ubuntu / Debian

sudo apt update
sudo apt install openssh-server -y

CentOS / RHEL / AlmaLinux / Rocky Linux

sudo yum install openssh-server -y

Fedora

sudo dnf install openssh-server -y

Arch Linux

sudo pacman -S openssh

Après l’installation, le serveur OpenSSH (sshd) et le client OpenSSH sont disponibles, vous permettant d’accepter des connexions entrantes et de vous connecter à d’autres serveurs distants.

Étape 2 : Démarrage et activation du service SSH

Une fois installé, vous devez démarrer le démon SSH (sshd) et le configurer pour qu’il se lance automatiquement au démarrage du système.

Démarrer le service SSH

sudo systemctl start ssh

Activer SSH au démarrage

sudo systemctl enable ssh

Vérifier que le service est en cours d’exécution

sudo systemctl status ssh

Une sortie correcte affichera active (running) en vert. Si vous constatez des erreurs, consultez vos journaux système avec journalctl -xe pour obtenir des détails de diagnostic.

Étape 3 : Comprendre le fichier de configuration SSH

Le comportement de SSH est régi par un seul fichier de configuration principal :

/etc/ssh/sshd_config

Ce fichier contrôle tout — le port d’écoute, les méthodes d’authentification, les utilisateurs autorisés, les restrictions de connexion, et bien plus encore. Créez toujours une sauvegarde avant d’effectuer des modifications :

sudo cp /etc/ssh/sshd_config /etc/ssh/sshd_config.bak

Ouvrez le fichier avec votre éditeur de texte préféré :

sudo nano /etc/ssh/sshd_config

Après toute modification, validez toujours la syntaxe de la configuration avant de redémarrer le service pour éviter de vous bloquer l’accès :

sudo sshd -t

Si aucune erreur n’est retournée, appliquez les modifications :

sudo systemctl restart ssh

Étape 4 : Modifications essentielles de la configuration SSH

4.1 Changer le port SSH par défaut

Le port 22 est le premier port ciblé par les scanners automatisés et les bots de force brute. Le changer pour un port non standard réduit considérablement le bruit dans vos journaux et diminue l’exposition aux attaques opportunistes.

Localisez cette ligne dans sshd_config :

#Port 22

Décommentez-la et définissez un port personnalisé (choisissez un nombre entre 1024 et 65535 qui n’est pas déjà utilisé) :

Port 2222

Enregistrez le fichier, validez et redémarrez SSH :

sudo sshd -t && sudo systemctl restart ssh

> Important : Mettez à jour vos règles de pare-feu immédiatement après avoir changé le port (voir Étape 6). Ne pas le faire vous bloquera l’accès à votre serveur.

4.2 Désactiver la connexion root via SSH

Autoriser la connexion root directe via SSH est l’une des mauvaises configurations les plus courantes et les plus dangereuses. Si un attaquant devine ou force le mot de passe root, il dispose d’un contrôle total et sans restriction sur votre système.

Trouvez cette directive :

PermitRootLogin yes

Changez-la en :

PermitRootLogin no

Les utilisateurs doivent se connecter avec un compte standard et élever leurs privilèges en utilisant sudo si nécessaire. Cela crée une couche d’audit essentielle — chaque action privilégiée est enregistrée sous le nom d’un compte utilisateur identifié.

4.3 Imposer l’authentification par clé et désactiver les mots de passe

L’authentification par mot de passe est intrinsèquement vulnérable aux attaques par force brute. Les paires de clés SSH — une combinaison de clés publique/privée mathématiquement liées — sont exponentiellement plus sécurisées.

Localisez et définissez les directives suivantes :

PubkeyAuthentication yes
PasswordAuthentication no
ChallengeResponseAuthentication no

> Avertissement : Ne désactivez l’authentification par mot de passe qu’après avoir testé avec succès la connexion par clé. Désactiver les mots de passe sans clé fonctionnelle vous bloquera définitivement l’accès.

4.4 Directives de durcissement supplémentaires

Ajoutez ou modifiez ces paramètres dans sshd_config pour une configuration de production durcie :

# Restrict login to specific users (replace 'youruser' with actual usernames)
AllowUsers youruser

# Disconnect idle sessions after 5 minutes
ClientAliveInterval 300
ClientAliveCountMax 2

# Limit authentication attempts per connection
MaxAuthTries 3

# Disable empty passwords
PermitEmptyPasswords no

# Disable X11 forwarding if not needed
X11Forwarding no

# Use only modern, secure protocol version
Protocol 2

# Restrict SSH to specific network interface (optional, replace with your IP)
ListenAddress 0.0.0.0

Étape 5 : Génération et déploiement des paires de clés SSH

L’authentification par clé SSH remplace les mots de passe par une preuve cryptographique d’identité. Voici comment la configurer correctement.

Étape 5.1 : Générer une paire de clés sur votre machine locale

Exécutez cette commande sur votre poste de travail local (pas sur le serveur) :

ssh-keygen -t ed25519 -C "your_email@example.com"

> Pourquoi Ed25519 ? Ed25519 est un algorithme moderne à courbe elliptique qui est plus rapide, plus sécurisé et produit des clés plus courtes que l’ancien algorithme RSA. C’est le choix recommandé en 2025.

Si votre système ou vos outils nécessitent RSA pour des raisons de compatibilité, utilisez une clé de 4096 bits :

ssh-keygen -t rsa -b 4096 -C "your_email@example.com"

Il vous sera demandé de :

1. Choisir un chemin de fichier (appuyez sur Entrée pour accepter la valeur par défaut ~/.ssh/id_ed25519)
2. Définir une phrase de passe optionnelle (fortement recommandée — elle chiffre votre clé privée au repos)

Cela génère deux fichiers :

~/.ssh/id_ed25519 — Votre clé privée. Ne la partagez jamais. Ne la copiez jamais sur un serveur.
~/.ssh/id_ed25519.pub — Votre clé publique. C’est ce qui est installé sur les serveurs.

Étape 5.2 : Copier la clé publique sur le serveur
Utilisez ssh-copy-id pour transférer de manière sécurisée votre clé publique vers le serveur distant :
ssh-copy-id -p 2222 username@your_server_ip
Remplacez username par le nom de votre compte serveur et your_server_ip par l’adresse IP réelle.
Cette commande ajoute votre clé publique à ~/.ssh/authorized_keys sur le serveur avec les permissions correctes automatiquement.
Méthode manuelle (si ssh-copy-id n’est pas disponible) :
cat ~/.ssh/id_ed25519.pub | ssh username@your_server_ip "mkdir -p ~/.ssh && chmod 700 ~/.ssh && cat >> ~/.ssh/authorized_keys && chmod 600 ~/.ssh/authorized_keys"
Étape 5.3 : Tester la connexion par clé
Avant de désactiver l’authentification par mot de passe, vérifiez que la connexion par clé fonctionne :
ssh -p 2222 username@your_server_ip
Si vous vous connectez avec succès sans être invité à saisir un mot de passe (ou uniquement pour la phrase de passe de votre clé), l’authentification par clé fonctionne correctement. Vous pouvez maintenant désactiver en toute sécurité l’authentification par mot de passe dans sshd_config.
Étape 6 : Configuration de votre pare-feu pour SSH
Un pare-feu est votre première ligne de défense. Configurez-le toujours pour n’autoriser que le port SSH que vous utilisez.
Utilisation de UFW (Ubuntu / Debian)
# Allow your custom SSH port
sudo ufw allow 2222/tcp

# Enable the firewall
sudo ufw enable

# Verify the rules
sudo ufw status verbose
Utilisation de firewalld (CentOS / RHEL / Fedora)
# Add the custom SSH port
sudo firewall-cmd --permanent --add-port=2222/tcp

# Remove the default port 22 (optional, after confirming new port works)
sudo firewall-cmd --permanent --remove-service=ssh

# Reload firewall rules
sudo firewall-cmd --reload
Restreindre l’accès SSH par adresse IP
Pour une sécurité maximale, limitez l’accès SSH aux adresses IP connues et de confiance uniquement :
# UFW example: allow SSH only from a specific IP
sudo ufw allow from 203.0.113.10 to any port 2222 proto tcp
Cela est particulièrement efficace sur les Serveurs Dédiés où vous contrôlez tous les accès administratifs depuis une plage d’IP de bureau fixe ou VPN.
Étape 7 : Mesures de sécurité avancées
7.1 Installer et configurer Fail2Ban
Fail2Ban surveille les fichiers journaux SSH et bannit automatiquement les adresses IP qui montrent des signes d’activité de force brute.
# Install Fail2Ban
sudo apt install fail2ban -y   # Ubuntu/Debian
sudo yum install fail2ban -y   # CentOS/RHEL

# Create a local configuration file
sudo cp /etc/fail2ban/jail.conf /etc/fail2ban/jail.local
Modifiez /etc/fail2ban/jail.local et configurez la prison SSH :
[sshd]
enabled = true
port    = 2222
filter  = sshd
logpath = /var/log/auth.log
maxretry = 3
bantime  = 3600
findtime = 600
Démarrez et activez Fail2Ban :
sudo systemctl start fail2ban
sudo systemctl enable fail2ban
7.2 Utiliser le fichier de configuration SSH pour la gestion côté client
Sur votre machine locale, créez ou modifiez ~/.ssh/config pour simplifier les connexions et appliquer les paramètres de sécurité :
Host myserver
    HostName your_server_ip
    User youruser
    Port 2222
    IdentityFile ~/.ssh/id_ed25519
    ServerAliveInterval 60
    ServerAliveCountMax 3
Avec cette configuration, vous pouvez vous connecter simplement en tapant :
ssh myserver
7.3 Authentification à deux facteurs (2FA) pour SSH
Pour les environnements nécessitant le plus haut niveau de sécurité d’accès — tels que les bases de données de production, les systèmes financiers ou les infrastructures soumises à des réglementations de conformité — envisagez d’ajouter une authentification à deux facteurs basée sur TOTP en utilisant Google Authenticator ou Authy en complément des clés SSH.
sudo apt install libpam-google-authenticator -y
google-authenticator
Configurez ensuite PAM et sshd_config pour exiger à la fois une clé et un mot de passe à usage unique. Cela crée un véritable flux d’authentification multi-facteurs.
Étape 8 : Test et dépannage de SSH
Après avoir terminé votre configuration, vérifiez systématiquement que tout fonctionne comme prévu.
Test de connexion
ssh -p 2222 -v username@your_server_ip
L’option -v active le mode verbeux, affichant des informations de débogage détaillées sur chaque étape de la connexion — indispensable pour diagnostiquer les échecs d’authentification.
Problèmes courants et solutions




Problème
Cause probable
Solution




Connection refused
SSH non démarré ou mauvais port
Vérifiez systemctl status ssh et les règles du pare-feu


Permission denied (publickey)
Clé absente de authorized_keys ou permissions incorrectes
Vérifiez que ~/.ssh/authorized_keys existe avec chmod 600


Host key verification failed
Empreinte du serveur modifiée
Supprimez l’ancienne entrée de ~/.ssh/known_hosts


Connection timed out
Pare-feu bloquant le port
Vérifiez les règles UFW/firewalld et les groupes de sécurité cloud


Accès bloqué après modification de la configuration
Mauvaise configuration dans sshd_config
Utilisez l’accès console/KVM pour annuler les modifications




Commandes de diagnostic
# Check SSH service status
sudo systemctl status ssh

# View real-time SSH logs
sudo journalctl -u ssh -f

# Check which port SSH is listening on
sudo ss -tlnp | grep sshd

# Test configuration file syntax
sudo sshd -t
Référence complète de sshd_config durci
Voici un fichier sshd_config prêt pour la production intégrant toutes les recommandations de sécurité de ce guide :
# Network
Port 2222
ListenAddress 0.0.0.0
Protocol 2

# Authentication
PermitRootLogin no
PubkeyAuthentication yes
PasswordAuthentication no
PermitEmptyPasswords no
ChallengeResponseAuthentication no
MaxAuthTries 3
LoginGraceTime 30

# Session Management
ClientAliveInterval 300
ClientAliveCountMax 2
MaxSessions 5

# Access Control
AllowUsers youruser

# Features (disable what you don't need)
X11Forwarding no
AllowTcpForwarding no
GatewayPorts no
PermitUserEnvironment no

# Logging
SyslogFacility AUTH
LogLevel VERBOSE
Pourquoi votre infrastructure d’hébergement est importante pour la sécurité SSH
La sécurité de votre configuration SSH n’existe pas de manière isolée — elle dépend fortement de l’infrastructure sous-jacente. Une configuration SSH correctement durcie est plus efficace lorsqu’elle est déployée sur un serveur qui fournit déjà :

La protection DDoS pour absorber les attaques volumétriques avant qu’elles n’atteignent votre port SSH
Le stockage NVMe pour des écritures de journaux rapides et des temps de réponse Fail2Ban accélérés
Des ports réseau 1 Gbps pour assurer la stabilité des connexions sous charge
L’accès KVM/console comme méthode de récupération hors bande si vous vous bloquez accidentellement l’accès

Les offres VPS Hosting d’AlexHost incluent tout ce qui précède, avec un accès root complet et la prise en charge de configurations de pare-feu personnalisées — ce qui les rend idéales pour déployer la configuration SSH durcie décrite dans ce guide.
Si vous avez besoin d’un panneau de contrôle pour gérer votre serveur en parallèle de SSH, explorez les Panneaux de contrôle VPS pour des options incluant cPanel, Plesk et DirectAdmin. Pour les équipes gérant plusieurs propriétés web, l’Hébergement Web Mutualisé fournit un environnement géré où le durcissement SSH est pris en charge au niveau de l’infrastructure.
Et si vous exploitez des services web sécurisés par SSL en parallèle de votre serveur SSH durci, associer votre configuration à une solution de Certificats SSL de confiance garantit un chiffrement de bout en bout sur tous vos services publics.
Liste de contrôle de sécurité SSH
Utilisez cette liste de contrôle avant de considérer votre configuration SSH prête pour la production :

[ ] Serveur OpenSSH installé et en cours d’exécution
[ ] Port par défaut 22 changé pour un port personnalisé
[ ] Connexion root désactivée (PermitRootLogin no)
[ ] Paire de clés Ed25519 ou RSA-4096 générée
[ ] Clé publique déployée dans authorized_keys sur le serveur
[ ] Connexion par clé testée avec succès
[ ] Authentification par mot de passe désactivée
[ ] Pare-feu configuré pour n’autoriser que le nouveau port SSH
[ ] Fail2Ban installé et configuré
[ ] MaxAuthTries défini à 3 ou moins
[ ] ClientAliveInterval configuré pour terminer les sessions inactives
[ ] Syntaxe de sshd_config validée avec sudo sshd -t

• [ ] Accès console hors bande confirmé (KVM/VNC)

Conclusion

Installer et configurer SSH correctement est l’une des compétences les plus fondamentales en administration système Linux. Une installation SSH par défaut est une vulnérabilité ; une configuration SSH durcie est un atout. En suivant ce guide, vous avez :

1. Installé et démarré le serveur OpenSSH
2. Changé le port par défaut et désactivé la connexion root
3. Mis en place une authentification par clé cryptographiquement robuste
4. Configuré des règles de pare-feu pour restreindre l’accès
5. Déployé Fail2Ban pour bloquer les tentatives de force brute
6. Établi une méthodologie complète de dépannage

SSH, lorsqu’il est correctement configuré, devient une passerelle puissante, fiable et sécurisée pour la gestion à distance, les pipelines d’automatisation et la communication chiffrée entre systèmes. Combiné à une infrastructure d’hébergement robuste — telle que les Serveurs Dédiés d’AlexHost avec atténuation DDoS au niveau matériel — vous disposez d’une base véritablement difficile à compromettre.

Révisez périodiquement votre configuration SSH. Renouvelez vos clés annuellement. Surveillez vos journaux. La sécurité n’est pas une tâche ponctuelle — c’est une pratique continue.