Configurer SSH sur Linux : installation, configuration et sécurisation

Configurer SSH sur Linux permet d’administrer une machine à distance, de transférer des fichiers et d’automatiser des tâches dans un canal chiffré. Ce guide utilise OpenSSH et sépare clairement les commandes pour Ubuntu et Debian, Fedora, Arch Linux, openSUSE et Alpine Linux.  

L’essentiel
Commande clé : sudo sshd -t — tester la configuration avant tout rechargement.
Prérequis : accès sudo, une seconde session ouverte en secours.
Portée : Ubuntu, Debian, Fedora, Arch et Alpine, avec les écarts de pare-feu détaillés.
Sources : documentation officielle des projets cités, consultée le 20 juillet 2026.

Comment fonctionne SSH ?

SSH, pour Secure Shell, repose sur un client et un serveur. Le client ssh lance la connexion depuis votre poste. Le démon sshd écoute sur la machine distante, généralement sur le port TCP 22. Le chiffrement protège la session, mais l’identité du serveur doit aussi être vérifiée : accepter une empreinte inconnue sans contrôle expose à une attaque de type homme du milieu. OpenSSH fournit également scp, sftp, les tunnels de ports, les clés publiques et les fonctions de rebond comme ProxyJump.

Installer et activer OpenSSH selon la distribution

Pour configurer SSH sur Linux, exécutez uniquement le bloc correspondant à votre distribution. Chaque bloc est séparé pour rester visible et copiable avec le bouton de copie WordPress.

Ubuntu et Debian

sudo apt update
sudo apt install openssh-server
sudo systemctl enable --now ssh
sudo systemctl status ssh

Fedora

sudo dnf install openssh-server
sudo systemctl enable --now sshd
sudo systemctl status sshd

Arch Linux

sudo pacman -S openssh
sudo systemctl enable --now sshd
sudo systemctl status sshd

openSUSE

sudo zypper install openssh
sudo systemctl enable --now sshd
sudo systemctl status sshd

Alpine Linux

Sur Alpine, exécutez ces commandes avec le compte root. OpenRC remplace systemd.

apk add openssh
rc-update add sshd default
rc-service sshd start
rc-service sshd status

Vérifier le client, le serveur et le port d’écoute

La commande suivante affiche la version du client SSH. Elle ne prouve pas que le serveur sshd est installé.

ssh -V

Une étape importante pour configurer SSH sur Linux consiste à vérifier le paquet serveur avec le bloc de votre distribution.

Ubuntu et Debian

dpkg-query -W openssh-server

Fedora et openSUSE

rpm -q openssh-server 2>/dev/null || rpm -q openssh

Arch Linux

pacman -Q openssh

Alpine Linux

apk info -e openssh

Sur Ubuntu, Debian, Fedora, Arch Linux et openSUSE, vérifiez le processus et le port réellement ouverts.

sudo ss -ltnp | grep sshd

Sur une installation minimale d’Alpine Linux, utilisez plutôt l’outil BusyBox netstat :

nnetstat -lntp | grep sshd

Se connecter et vérifier l’empreinte du serveur

Depuis le serveur, relevez l’empreinte de la clé d’hôte Ed25519 par une console locale, l’interface du fournisseur ou un autre canal déjà fiable.

sudo ssh-keygen -lf /etc/ssh/ssh_host_ed25519_key.pub

Pour configurer SSH sur Linux de bout en bout, lancez ensuite la connexion depuis votre poste local.

ssh utilisateur@adresse_ip

Comparez l’empreinte affichée par le client avec celle obtenue sur le serveur. Acceptez-la uniquement si elles correspondent. La clé est alors enregistrée dans ~/.ssh/known_hosts.

Avec un port personnalisé :

ssh -p 2222 utilisateur@adresse_ip

Avec une clé privée précise :

ssh -i ~/.ssh/id_ed25519 utilisateur@adresse_ip

Configurer sshd sans se fermer l’accès

Pour configurer SSH sur Linux côté serveur, le fichier principal est /etc/ssh/sshd_config. De nombreuses distributions chargent aussi des fichiers placés dans /etc/ssh/sshd_config.d/. Vérifiez d’abord que la directive Include est active.

sudo grep -nE '^[[:space:]]*Include' /etc/ssh/sshd_config

Lorsque /etc/ssh/sshd_config.d/*.conf est inclus, créez un fichier dédié. Cette méthode évite de mélanger vos réglages avec le fichier fourni par le paquet. Si aucune directive Include correspondante n’apparaît, sauvegardez puis modifiez directement /etc/ssh/sshd_config.

sudo touch /etc/ssh/sshd_config.d/99-memolinux.conf
sudo chmod 644 /etc/ssh/sshd_config.d/99-memolinux.conf
sudo nano /etc/ssh/sshd_config.d/99-memolinux.conf

Exemple de configuration à adapter. Remplacez les noms indiqués dans AllowUsers ou supprimez cette ligne si elle n’est pas utile.

PermitRootLogin no
PubkeyAuthentication yes
MaxAuthTries 3
LoginGraceTime 30
X11Forwarding no
AllowUsers vincent
ClientAliveInterval 300
ClientAliveCountMax 2

Validez toujours la syntaxe avant de recharger le service.

sudo sshd -t
sudo sshd -T | less

Recharger SSH sur Ubuntu et Debian

sudo systemctl reload ssh

Recharger SSH sur Fedora, Arch Linux et openSUSE

sudo systemctl reload sshd

Recharger SSH sur Alpine Linux

rc-service sshd reload

Important : conservez la session actuelle ouverte. Testez immédiatement une nouvelle connexion dans un second terminal. Ne poursuivez qu’après ce test réussi.

Utiliser des clés SSH

Lorsqu’on veut configurer SSH sur Linux avec une authentification robuste, Ed25519 est le choix recommandé pour la plupart des systèmes modernes. Générez la paire sur votre poste local et protégez la clé privée avec une phrase secrète.

ssh-keygen -t ed25519 -C "poste-principal"

Copiez ensuite la clé publique sur le serveur.

ssh-copy-id -i ~/.ssh/id_ed25519.pub utilisateur@adresse_ip

Pour un port personnalisé :

ssh-copy-id -p 2222 -i ~/.ssh/id_ed25519.pub utilisateur@adresse_ip

Testez la connexion par clé dans une nouvelle fenêtre.

ssh -o IdentitiesOnly=yes -i ~/.ssh/id_ed25519 utilisateur@adresse_ip

Après un test réussi, vous pouvez désactiver les mots de passe dans la configuration du serveur. Ne désactivez pas KbdInteractiveAuthentication si vous utilisez une authentification PAM ou TOTP qui en dépend.

PasswordAuthentication no
KbdInteractiveAuthentication no

Validez et rechargez ensuite le service avec les commandes de la section précédente. Une clé RSA de 4096 bits reste utile pour certains anciens systèmes :

ssh-keygen -t rsa -b 4096 -C "compatibilite-ancienne"

Changer le port SSH sans interrompre le service

Avant de configurer SSH sur Linux sur un port personnalisé, gardez à l’esprit que changer le port ne remplace ni les clés SSH ni un pare-feu. Cela réduit surtout le bruit des robots dans les journaux. Ouvrez d’abord le nouveau port, ajoutez ensuite la directive suivante dans la configuration du serveur, validez avec sshd -t, rechargez SSH et testez une nouvelle connexion.

Port 2222

Ubuntu ou Debian avec UFW

Ouvrez le nouveau port et contrôlez les règles avant toute suppression.

sudo ufw allow 2222/tcp
sudo ufw status numbered

Après une connexion réussie sur le port 2222, retirez uniquement l’ancienne règle qui existe réellement.

sudo ufw delete allow 22/tcp

Lorsque l’ancienne règle a été créée avec le profil UFW OpenSSH, utilisez plutôt :

sudo ufw delete allow OpenSSH

Fedora, RHEL ou openSUSE avec firewalld

Détectez la zone active, ouvrez le nouveau port et vérifiez le résultat.

ZONE=$(sudo firewall-cmd --get-active-zones | head -n1)
sudo firewall-cmd --permanent --zone="$ZONE" --add-port=2222/tcp
sudo firewall-cmd --reload
sudo firewall-cmd --zone="$ZONE" --list-all

Sur Fedora et RHEL avec SELinux actif, autorisez également sshd à écouter sur ce port.

sudo dnf install policycoreutils-python-utils
sudo semanage port -a -t ssh_port_t -p tcp 2222

Si le port existe déjà sous un autre type SELinux, remplacez -a par -m. Après validation d’une nouvelle connexion, retirez le service prédéfini ssh seulement s’il est encore présent dans la zone active.

ZONE=$(sudo firewall-cmd --get-active-zones | head -n1)
sudo firewall-cmd --permanent --zone="$ZONE" --remove-service=ssh
sudo firewall-cmd --reload

Arch Linux et Alpine Linux

Ces distributions n’imposent pas un pare-feu unique. Adaptez les règles nftables, iptables ou le pare-feu du fournisseur avant de retirer l’accès au port 22.

Installer et configurer fail2ban selon la distribution

Pour configurer SSH sur Linux face aux tentatives répétées, fail2ban complète les clés et le pare-feu en bloquant temporairement les adresses qui multiplient les échecs. Les paquets et l’intégration aux journaux diffèrent selon la distribution. Avant d’automatiser le blocage, vous pouvez filtrer les journaux de connexion avec grep pour identifier les adresses réellement concernées.

Ubuntu et Debian

sudo apt install fail2ban
sudo systemctl enable --now fail2ban

Fedora

sudo dnf install fail2ban fail2ban-systemd fail2ban-firewalld
sudo systemctl enable --now fail2ban

Arch Linux

sudo pacman -S fail2ban
sudo systemctl enable --now fail2ban

openSUSE

sudo zypper install fail2ban
sudo systemctl enable --now fail2ban

Alpine Linux

apk add fail2ban fail2ban-openrc
rc-update add fail2ban default
rc-service fail2ban start

Créez ensuite une configuration locale. Adaptez le port à la valeur réellement utilisée par SSH.

sudo nano /etc/fail2ban/jail.local

[sshd]
enabled = true
port = 2222
maxretry = 3
findtime = 10m
bantime = 1h

Validez la configuration avant de redémarrer fail2ban.

sudo fail2ban-client -t
sudo systemctl restart fail2ban
sudo fail2ban-client status sshd

Sur Alpine, remplacez le redémarrage systemd par :

rc-service fail2ban restart
fail2ban-client status sshd

Créer des alias sûrs dans ~/.ssh/config

Le fichier client ~/.ssh/config simplifie le travail lorsqu’il faut configurer SSH sur Linux sur plusieurs machines : il évite de répéter le nom, le port et la clé. Créez-le puis limitez ses permissions.

mkdir -p ~/.ssh
chmod 700 ~/.ssh
nano ~/.ssh/config
chmod 600 ~/.ssh/config

Exemple pour deux serveurs :

Host monserveur
    HostName 192.168.1.100
    User vincent
    Port 2222
    IdentityFile ~/.ssh/id_ed25519
    IdentitiesOnly yes
    ForwardAgent no
    StrictHostKeyChecking accept-new

Host serveur-interne
    HostName 10.0.1.50
    User vincent
    ProxyJump bastion
    ForwardAgent no

StrictHostKeyChecking accept-new peut simplifier une automatisation maîtrisée : il accepte une nouvelle machine, mais refuse une clé déjà connue qui aurait changé. Ne remplacez pas ce réglage par no. Laissez aussi ForwardAgent no par défaut ; activez le transfert d’agent uniquement pour un hôte précis et lorsque vous comprenez le risque. Pour un simple rebond, préférez ProxyJump.

Connexion avec les alias :

ssh monserveur
ssh serveur-interne

Copier des fichiers avec scp et rsync

Pour configurer SSH sur Linux et transférer des fichiers, retenez que les versions modernes de la commande scp utilisent SFTP par défaut. Les commandes restent identiques pour l’utilisateur. Copier un fichier local vers le serveur :

scp fichier.txt utilisateur@adresse_ip:/home/utilisateur/

Copier un dossier :

scp -r dossier/ utilisateur@adresse_ip:/home/utilisateur/

Utiliser un port personnalisé :

scp -P 2222 fichier.txt utilisateur@adresse_ip:/home/utilisateur/

rsync doit être installé sur la machine locale et sur le serveur distant. Il ne retransmet que les différences et convient mieux aux synchronisations répétées.

rsync -avz dossier/ utilisateur@adresse_ip:/home/utilisateur/dossier/

Avec un port SSH personnalisé :

rsync -avz -e "ssh -p 2222" dossier/ utilisateur@adresse_ip:/home/utilisateur/dossier/

Pour automatiser des sauvegardes, consultez aussi le guide rsync et crontab.

Créer des tunnels SSH

Pour configurer SSH sur Linux avec un tunnel dédié, l’option -N évite d’ouvrir un shell et ExitOnForwardFailure=yes ferme immédiatement la connexion si le tunnel ne peut pas être créé.

Tunnel local

ssh -N -o ExitOnForwardFailure=yes -L 127.0.0.1:3306:localhost:3306 utilisateur@adresse_ip

Le port 3306 de votre poste local est alors relié au port 3306 vu depuis le serveur SSH.

Tunnel distant

ssh -N -o ExitOnForwardFailure=yes -R 127.0.0.1:8080:localhost:80 utilisateur@adresse_ip

Par défaut, le port distant reste lié à l’interface de boucle locale du serveur. Il n’est pas accessible depuis tout le réseau. Une exposition externe nécessite notamment une configuration volontaire de GatewayPorts côté serveur et des règles de pare-feu adaptées.

Proxy SOCKS

ssh -N -D 127.0.0.1:1080 utilisateur@adresse_ip

Seul le trafic des applications configurées pour utiliser le proxy SOCKS5 sur 127.0.0.1:1080 passe dans le tunnel.

Résoudre les erreurs courantes

Connection refused

Pour configurer SSH sur Linux sans erreur, vérifiez le service et le port selon votre distribution.

Ubuntu et Debian

sudo systemctl status ssh
sudo ss -ltnp | grep sshd
sudo journalctl -u ssh -n 50

Fedora, Arch Linux et openSUSE

sudo systemctl status sshd
sudo ss -ltnp | grep sshd
sudo journalctl -u sshd -n 50

Alpine Linux

rc-service sshd status
ss -ltnp | grep sshd

Permission denied (publickey)

Sur le serveur, vérifiez les droits du compte concerné.

chmod 700 ~/.ssh
chmod 600 ~/.ssh/authorized_keys

Depuis le client, affichez le détail de la négociation.

ssh -vvv -o IdentitiesOnly=yes -i ~/.ssh/id_ed25519 utilisateur@adresse_ip

Le guide sur chmod et les permissions Linux explique ces modes en détail.

Host key verification failed

Une clé d’hôte modifiée peut correspondre à une réinstallation légitime, mais aussi à une interception. Vérifiez d’abord la nouvelle empreinte depuis la console du serveur.

sudo ssh-keygen -lf /etc/ssh/ssh_host_ed25519_key.pub

Seulement après confirmation, supprimez l’ancienne entrée sur le client et reconnectez-vous.

ssh-keygen -R adresse_ip

Too many authentication failures

ssh -o IdentitiesOnly=yes -i ~/.ssh/id_ed25519 utilisateur@adresse_ip

Connexion lente

Ne modifiez pas immédiatement UseDNS. Identifiez d’abord l’étape qui bloque : résolution de nom, GSSAPI, clés proposées par l’agent ou réseau.

ssh -vvv utilisateur@adresse_ip

Consulter les tentatives de connexion

Ubuntu et Debian

sudo journalctl -u ssh --since "24 hours ago"
sudo journalctl -u ssh --since "24 hours ago" | grep -i failed

Fedora, Arch Linux et openSUSE

sudo journalctl -u sshd --since "24 hours ago"
sudo journalctl -u sshd --since "24 hours ago" | grep -i failed

Alpine Linux

Le chemin dépend du service de journalisation installé. Vérifiez généralement /var/log/messages ou la sortie du démon syslog.

grep -i sshd /var/log/messages | tail -50

Checklist de sécurisation SSH

• Vérifier l’empreinte du serveur avant la première acceptation.

• Utiliser une clé Ed25519 protégée par une phrase secrète.
• Interdire la connexion directe de root.
• Désactiver les mots de passe seulement après avoir testé la clé.
• Valider chaque modification avec sudo sshd -t.
• Garder une session existante ouverte pendant le test.
• Ouvrir le nouveau port avant de retirer l’ancien.
• Conserver ForwardAgent no et ne jamais utiliser globalement StrictHostKeyChecking no.
• Consulter régulièrement les journaux et l’état de fail2ban.

Conclusion

Une configuration SSH fiable repose sur une suite de vérifications : installer le bon service, valider sshd_config avec sshd -t, tester les clés dans une seconde session, adapter le pare-feu et surveiller les journaux. Une fois l’authentification par clé confirmée, vous pouvez désactiver progressivement les mots de passe et renforcer l’accès avec fail2ban. Gardez toujours une session ouverte pendant les changements afin d’éviter de vous verrouiller hors du serveur.

Questions fréquentes

Quelle différence entre SSH et SFTP ?

SSH fournit la session sécurisée. SFTP est un protocole de transfert de fichiers qui utilise la même infrastructure SSH. La commande scp moderne s’appuie elle aussi sur SFTP par défaut.

Le changement de port sécurise-t-il réellement SSH ?

Il réduit les scans automatisés et le bruit dans les journaux, mais ne remplace pas une authentification par clé, un pare-feu, la vérification des empreintes et des mises à jour régulières.

Peut-on désactiver immédiatement les mots de passe ?

Non. Copiez d’abord la clé publique, testez-la dans une seconde session et gardez l’ancienne connexion ouverte. Désactivez ensuite PasswordAuthentication, validez avec sshd -t et rechargez le service.

SSH fonctionne-t-il de la même manière sur toutes les distributions ?

Configurer SSH sur Linux suit la même logique générale : le protocole reste le même. Les différences concernent surtout le paquet, le nom du service, le pare-feu, SELinux et le système d’initialisation. C’est pourquoi les commandes de ce guide sont séparées par distribution et présentées dans des blocs copiables. Configurer SSH sur Linux correctement consiste donc à installer OpenSSH, vérifier l’identité du serveur, tester la configuration avant rechargement, privilégier les clés et adapter le pare-feu à la distribution utilisée. Pour un serveur qui héberge des conteneurs, consultez également le guide pour installer Docker sur Linux.

Dernière vérification des commandes et des procédures : 20 juillet 2026, d’après la documentation officielle des projets et distributions cités.