Qu’est-ce que SSH et comment fonctionne-t-il ?

Qu’est-ce que SSH ?

SSH (Secure Shell) est un protocole qui permet de se connecter à un ordinateur distant et d’y exécuter des commandes via une connexion chiffrée. Ce que vous saisissez est transmis à la machine distante, sa sortie vous est renvoyée, et personne qui surveille le trafic réseau entre les deux ne peut lire ces données. Un serveur Linux loué n’a ni écran ni clavier. SSH est donc le moyen de l’utiliser.

Le nom désigne deux éléments. SSH est le protocole décrit dans les RFC 4251 à RFC 4254. OpenSSH est le programme qui l’implémente. C’est celui qui fonctionne réellement sur presque tous les serveurs Linux et presque tous les ordinateurs portables. Quand quelqu’un dit « se connecter au serveur en SSH », il parle du programme client ssh exécuté sur sa machine, qui communique avec le programme serveur sshd à l’autre extrémité.

Le problème que SSH devait résoudre

La connexion à distance est bien antérieure à SSH. Telnet ouvrait une connexion TCP en clair vers le port 23 et envoyait chaque octet exactement comme il était saisi. Rien n’était chiffré, pas même votre mot de passe. Toute personne capable d’observer le trafic pouvait le lire : quelqu’un sur le même réseau de bureau ou l’opérateur de l’un des routeurs traversés. La famille rlogin présentait la même faiblesse. Elle faisait confiance au nom de la machine cliente, ce qui revenait à faire confiance à ce que le réseau affirmait être ce nom.

Tatu Ylönen a écrit le premier SSH en 1995 à l’université de technologie d’Helsinki, après une attaque par interception de mots de passe sur le réseau de l’université. La conception conserve la partie utile de Telnet, un flux d’octets entre votre terminal et un shell distant, et ajoute les deux éléments auxquels Telnet n’apporte aucune réponse : le chiffrement du flux et la preuve que le serveur distant est bien celui auquel vous vouliez vous connecter.

Ce second élément est facile à négliger, alors qu’il représente la moitié du fonctionnement de SSH. Le chiffrement seul ne vous protégerait pas. Une machine intermédiaire pourrait accepter votre connexion, la chiffrer parfaitement, lire tout ce que vous envoyez, puis transmettre le contenu au véritable serveur. SSH empêche cela en attribuant à chaque serveur une identité permanente, appelée host key, et en la vérifiant à chaque connexion.

Fonctionnement du modèle client-serveur

Deux programmes interviennent. Sur le serveur, sshd s’exécute en permanence et attend les connexions. Sur votre machine, ssh les établit. Ce sont deux programmes distincts, avec des fichiers de configuration distincts. Les confondre est la raison la plus fréquente pour laquelle une modification n’a aucun effet.

• Le serveur lit /etc/ssh/sshd_config. C’est dans ce fichier que la connexion par mot de passe est désactivée et que le port d’écoute est défini.
• Le client lit d’abord /etc/ssh/ssh_config pour les paramètres système par défaut, puis ~/.ssh/config pour vos propres paramètres par hôte.

Sur Debian et Ubuntu, l’unité de service s’appelle ssh. Sur RHEL, Rocky et Fedora, elle s’appelle sshd. Les versions récentes d’Ubuntu l’installent avec une activation par socket. Ainsi, systemctl status ssh peut indiquer inactive (dead) alors que la machine est parfaitement accessible, car ssh.socket est l’unité qui écoute et démarre le service à la demande.

Le client n’est pas nécessairement OpenSSH. PuTTY sur Windows, Termius sur un téléphone et l’accès distant intégré aux éditeurs utilisent tous le même protocole avec le même sshd. Windows 10 et 11 incluent également le client OpenSSH. ssh you@server fonctionne donc dans PowerShell sans rien installer.

Pourquoi SSH utilise-t-il le port 22 ?

Un port est un numéro qui indique au noyau à quel programme en écoute une connexion entrante est destinée. Les ports sous Linux fonctionnent de la même manière pour tous les services. SSH utilise le port 22 parce que l’IANA le lui a attribué en 1995. Ylönen a demandé un numéro libre situé à côté des protocoles que SSH devait remplacer : 21 était utilisé par FTP, 23 par telnet et 22 était libre.

Comme 22 est le port par défaut, tout le monde part de cette valeur. Votre remote Git, votre script de sauvegarde et le panneau de contrôle de votre fournisseur essaient tous d’abord le port 22. C’est également le cas de tous les scanners automatisés présents sur Internet. Un nouveau serveur dont l’authentification par mot de passe est activée commence à accumuler des lignes comme celle-ci dans /var/log/auth.log quelques minutes après le démarrage :

Failed password for invalid user admin from 203.0.113.55 port 43122 ssh2

Ce trafic est constant et ne vous vise pas personnellement. Déplacer sshd vers le port 2222 supprime la plupart de ces lignes, car les scanners balaient tout Internet sur le port 22 au lieu d’examiner votre serveur. Cela ne rend pas la machine plus difficile à compromettre pour quelqu’un qui l’examine réellement. Considérez le changement de port comme une simple réduction du bruit, rien de plus.

Vous pouvez observer la réponse du serveur avant même de vous y connecter :

nc 203.0.113.10 22

Sur Ubuntu 24.04, cette commande affiche quelque chose de proche de SSH-2.0-OpenSSH_9.6p1 Ubuntu-3ubuntu13. La bannière est envoyée en clair, avant l’établissement du chiffrement, car les deux parties doivent l’utiliser pour se mettre d’accord sur la version du protocole. Appuyez sur Ctrl+C pour fermer la connexion.

Ce qui se passe sur le réseau lorsque vous vous connectez

La séquence ci-dessous correspond à ce que fait un ssh you@server avant l’affichage de l’invite.

1. Le client résout le nom d’hôte en adresse IP, puis ouvre une connexion TCP vers le port 22.
2. Les deux côtés envoient leur bannière de version en clair.
3. Les deux côtés envoient la liste des algorithmes qu’ils prennent en charge : échange de clés, chiffrement, authentification des messages et compression. Ces informations sont toujours transmises en clair. L’option la plus robuste connue des deux côtés est sélectionnée.
4. L’échange de clés s’exécute. OpenSSH utilise actuellement de préférence curve25519-sha256. Les deux extrémités obtiennent le même secret partagé sans que ce secret ne transite sur le réseau. Une personne qui a enregistré toute la conversation ne peut donc pas le retrouver ultérieurement.
5. Le serveur signe le résultat de l’échange avec sa clé privée d’hôte. Votre client vérifie la signature avec la clé publique d’hôte qu’il a enregistrée. Cette étape empêche une machine intermédiaire de se faire passer pour votre serveur.
6. Le chiffrement commence. chacha20-poly1305@openssh.com est le chiffrement utilisé par défaut dans les versions actuelles d’OpenSSH.
7. Ce n’est qu’à ce moment que le client vous authentifie, avec un mot de passe ou une clé. Votre nom d’utilisateur et votre mot de passe circulent à l’intérieur du canal chiffré.
8. Le client ouvre un canal et demande un shell.

L’ordre de cette liste constitue toute la différence avec telnet. L’authentification intervient après le chiffrement du canal et après que le serveur a prouvé son identité. Votre mot de passe ne se retrouve donc jamais en clair sur le réseau.

Une personne qui surveille le réseau apprend tout de même certaines informations. Elle voit votre adresse IP, l’adresse IP du serveur, le port 22, les deux bannières de version en clair, ainsi que le moment d’envoi et la taille approximative de chaque paquet. Elle ne voit pas votre nom d’utilisateur, votre mot de passe, vos commandes ni leur sortie. La résolution du nom d’hôte à l’étape 1 ne fait pas partie de SSH et n’est généralement pas privée. La requête DNS qui résout le nom de votre serveur peut donc révéler quelle machine vous êtes sur le point de joindre, même si la session elle-même reste protégée.

La clé d’hôte et l’invite d’empreinte de la première connexion

Lorsque openssh-server est installé, il génère des paires de clés d’hôte pour la machine et les écrit dans /etc/ssh/, par exemple ssh_host_ed25519_key et ssh_host_ed25519_key.pub. La partie privée ne quitte jamais le serveur. La partie publique constitue l’identité du serveur. C’est elle qui sert à vérifier la signature à l’étape 5.

Lors de la première connexion à un nouveau serveur, votre client ne dispose d’aucune clé de référence. Il vous demande donc :

The authenticity of host '203.0.113.10 (203.0.113.10)' can't be established.
ED25519 key fingerprint is SHA256:E9nVQ5Sm2oQ3nGm5Zf1tOaU7Xh0k2p8bWc4dLrTvYxA.
This key is not known by any other names.
Are you sure you want to continue connecting (yes/no/[fingerprint])?

L’empreinte est un hash SHA256 de la clé publique d’hôte, affiché en base64. Elle est ainsi assez courte pour être comparée visuellement. En saisissant yes, vous enregistrez cette clé dans ~/.ssh/known_hosts sur votre propre machine. Lors de chaque connexion ultérieure à la même adresse, la clé proposée par le serveur est comparée à celle qui est enregistrée. Si elles correspondent, aucun message ne s’affiche et vous arrivez directement à votre invite.

Ce modèle est appelé trust on first use. Il faut toutefois comprendre ce qu’il implique. La première connexion est le seul moment où vous n’êtes pas protégé, car vous acceptez une clé que vous n’avez encore jamais vue. Pour supprimer cette incertitude, obtenez l’empreinte par un autre moyen et comparez-la. La plupart des fournisseurs l’affichent dans la sortie du boot visible depuis leur console web. Vous pouvez également l’afficher directement sur le serveur :

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

Cette commande affiche la même chaîne SHA256: que celle présentée par l’invite. Le choix [fingerprint] dans l’invite existe précisément pour cela : collez l’empreinte attendue. Le client continue uniquement si elle correspond à celle présentée par le serveur.

Sur Debian et Ubuntu, known_hosts est haché par défaut. Le fichier contient donc des lignes qui commencent par |1| au lieu de contenir des noms d’hôte lisibles. Exécutez ssh-keygen -F 203.0.113.10 pour trouver l’entrée correspondant à un hôte.

Pourquoi SSH indique-t-il que la clé d’hôte a changé ?

Tôt ou tard, vous rencontrerez ce long message :

@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@
@    WARNING: REMOTE HOST IDENTIFICATION HAS CHANGED!     @
@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@
IT IS POSSIBLE THAT SOMEONE IS DOING SOMETHING NASTY!

Il se termine par Host key verification failed. et le client refuse de se connecter. Il affiche également Password authentication is disabled to avoid man-in-the-middle attacks., car saisir votre mot de passe sur une machine inconnue est précisément le risque que ce contrôle doit empêcher.

Le message semble signaler une urgence, mais ce n’est généralement pas le cas. Les causes habituelles sont les suivantes :

• Vous avez recréé ou réinstallé le serveur. sshd a donc généré de nouvelles clés d’hôte lors du premier démarrage. C’est de loin la raison la plus fréquente.
• Vous avez supprimé un VPS et en avez créé un autre. Le fournisseur a ensuite attribué l’ancienne adresse IP à la nouvelle machine.
• Vous vous connectez via un forward ou un load balancer qui dirige maintenant les connexions vers une autre machine backend.
• Quelqu’un intercepte réellement la connexion.

Déterminez la cause avant de supprimer quoi que ce soit. Si vous avez réinstallé la machine il y a dix minutes, la cause est évidente. Si rien n’a changé de votre côté, arrêtez-vous et vérifiez la situation. Cet avertissement indique que le contrôle fonctionne correctement. Une fois la cause confirmée, supprimez l’entrée obsolète, puis reconnectez-vous :

ssh-keygen -R 203.0.113.10

Lors de la connexion suivante, l’invite affiche de nouveau l’empreinte. Vous pouvez alors la comparer à celle affichée dans la console du fournisseur.

Connexion par mot de passe ou par clé

L’authentification par mot de passe envoie votre mot de passe dans le canal déjà chiffré, puis sshd le compare à la base de données des comptes, généralement via PAM (modules d’authentification enfichables). Elle ne nécessite aucune préparation. C’est pourquoi un fournisseur peut vous fournir un nouveau serveur avec uniquement un mot de passe root.

La faiblesse ne vient pas du chiffrement. Elle vient du fait qu’un mot de passe est un secret court, que vous l’envoyez au serveur à chaque connexion et que le port 22 fait l’objet de tentatives en continu par des machines qui ne se fatiguent jamais.

L’authentification par clé publique fonctionne autrement. Vous créez une paire de clés sur votre propre machine. La partie publique est placée dans ~/.ssh/authorized_keys, dans votre compte sur le serveur. La partie privée reste sur votre ordinateur portable et n’est jamais transmise. Pour se connecter, le client signe des données qui incluent l’identifiant de session issu de l’échange de clés, puis le serveur vérifie cette signature avec la clé publique qu’il détient déjà. Comme les données signées sont liées à cette session précise, une signature interceptée ne peut pas être utilisée ailleurs.

Vérifiez bien le sens, car l’inversion est fréquente et dangereuse : la clé publique va sur le serveur, tandis que la clé privée reste avec vous. Une clé privée copiée sur un serveur est une clé privée à laquelle vous ne pouvez plus faire confiance.

La connexion par clé a aussi ses propres causes d’échec. sshd ignore les clés lorsque les permissions du fichier sont trop permissives, et l’indique dans le journal du serveur :

Authentication refused: bad ownership or modes for directory /home/ubuntu/.ssh

Le client vous indique seulement Permission denied (publickey). Ce message est identique pour une douzaine de causes différentes. Il est donc utile d’apprendre à interpréter correctement l’erreur de clé publique avant de vous retrouver bloqué. La création des clés, leur protection par une passphrase et leur chargement dans un agent sont expliqués dans la gestion des clés SSH. Désactiver la connexion par mot de passe sans vous bloquer vous-même est expliqué dans le renforcement de la sécurité SSH sur un VPS.

SFTP, scp et la redirection de port utilisent la même connexion

Voici le principe qui permet de comprendre le reste de l’écosystème SSH. L’authentification ouvre une connexion chiffrée, qui peut transporter plusieurs canaux indépendants en même temps. Un shell est un type de canal parmi d’autres.

• Un shell distant. ssh you@server ouvre un canal de session et demande un shell interactif.
• Une commande unique. ssh you@server uptime ouvre un canal, exécute une commande, affiche la sortie, puis se termine.
• SFTP. Le client demande à sshd de démarrer son sous-système sftp, puis le transfert de fichiers s’effectue dans la même connexion. SFTP est un protocole de transfert de fichiers qui utilise SSH. Sa conception n’a rien à voir avec celle de FTP. Le protocole qui ajoute le chiffrement à FTP s’appelle FTPS et n’a aucun lien avec SFTP.
• scp. Copie des fichiers avec la même authentification. Depuis OpenSSH 9.0, publié en 2022, scp utilise par défaut le protocole SFTP sous-jacent.
• Redirection de port. ssh -L 8080:localhost:80 you@server transforme le port 8080 de votre ordinateur portable en un accès au port 80 du serveur, via la connexion chiffrée. -R effectue la redirection dans l’autre sens, et -D 1080 transforme la session en proxy SOCKS.
• Git. Un remote comme git@github.com:user/repo.git correspond à une authentification SSH dont le côté distant exécute un gestionnaire de commandes au lieu d’un shell.
• rsync et Ansible sont également des clients SSH. Ils ouvrent un canal, exécutent une action, puis récupèrent la sortie.

Tous les éléments de cette liste utilisent le même port, la même vérification de clé d’hôte et les mêmes identifiants. C’est pourquoi la configuration de l’authentification par clé est immédiatement rentable : chacun de ces outils en bénéficie. C’est aussi pourquoi le même fichier ~/.ssh/config qui raccourcit vos connexions est celui qui vous permet de travailler à grande échelle lorsque vous administrez plusieurs serveurs Linux depuis un même ordinateur portable.

Ce que SSH ne fait pas

• Il ne sécurise pas votre serveur. SSH protège le chemin jusqu’à la porte. Le service reste exposé et les tentatives de connexion continuent. Bloquer les tentatives de connexion répétées avec fail2ban limite le volume de ces tentatives, tandis que l’authentification uniquement par clé supprime le mot de passe qu’elles cherchent à deviner.
• Il ne vous protège pas contre votre propre machine. Toute personne qui accède à votre ordinateur portable dispose de votre clé privée et de votre agent chargé.
• Il ne masque pas l’utilisation de SSH. Le numéro de port et la bannière de version en clair l’annoncent.
• Il ne couvre pas ce qui se passe avant l’établissement de la connexion. La résolution du nom et votre décision concernant l’adresse à approuver interviennent d’abord.

Où aller ensuite

Si vous avez actuellement un nouveau serveur ouvert dans la console d’un provider, l’ordre à suivre est établi. Connectez-vous, créez un utilisateur normal, installez votre clé, puis fermez les accès faciles derrière vous. Les dix premières minutes sur un nouveau VPS présente cet ordre du début à la fin, tandis que ce qu’est réellement un VPS explique la machine sous-jacente si ces termes sont encore nouveaux pour vous. Ensuite, lisez les deux articles sur les clés et le hardening, dans cet ordre.

FAQ

Que signifie SSH ?

SSH signifie secure shell. Il s’agit d’un protocole qui permet de se connecter à un ordinateur distant et d’y exécuter des commandes via une connexion chiffrée, défini par les RFC 4251 à RFC 4254. OpenSSH est l’implémentation utilisée par presque tout le monde : le client ssh sur votre machine et le serveur sshd sur la machine distante. Il a remplacé telnet, qui envoyait tout sur le réseau en texte clair, y compris les mots de passe.

Pourquoi SSH utilise-t-il le port 22 ?

L’IANA a attribué le port 22 à SSH en 1995, entre FTP sur le port 21 et telnet sur le port 23, les protocoles qu’il devait remplacer. Rien n’impose ce numéro : Port dans /etc/ssh/sshd_config le modifie sur le serveur, et ssh -p permet d’en sélectionner un autre sur le client. Comme 22 est le port par défaut, les scanners automatisés le sondent en permanence. C’est pourquoi le fichier /var/log/auth.log d’un serveur fraîchement installé se remplit constamment de lignes Failed password for invalid user. Changer de port réduit ce bruit, mais n’apporte aucune protection réelle.

Que faire lorsque SSH indique que la clé d’hôte a changé ?

Recherchez la cause avant de supprimer quoi que ce soit. La raison est généralement sans gravité : le serveur a été reconstruit, et sshd a donc généré de nouvelles clés d’hôte, ou une nouvelle machine a reçu l’ancienne adresse IP. Si vous savez que la machine a été reconstruite, exécutez ssh-keygen -R <host> pour supprimer la clé enregistrée, reconnectez-vous, puis comparez l’empreinte affichée avec celle indiquée dans la console de votre fournisseur. Si rien n’a changé de votre côté, ne vous connectez pas et ne saisissez pas votre mot de passe. Dans cet état, OpenSSH refuse déjà l’authentification par mot de passe, précisément pour cette raison.

SFTP et scp sont-ils différents de SSH ?

Ils s’exécutent au-dessus de SSH. Une fois l’authentification terminée, la connexion SSH peut transporter plusieurs canaux, et un shell n’est que l’un d’eux. SFTP est un protocole de transfert de fichiers qui utilise le sous-système sftp de sshd sur cette même connexion, et scp utilise le protocole SFTP sous-jacent depuis OpenSSH 9.0. La redirection de port et Git over SSH utilisent également des canaux de cette même connexion. Tous utilisent le même port, la même vérification de la clé d’hôte et la même connexion utilisateur. Notez que SFTP n’est pas FTP auquel on aurait ajouté le chiffrement : ce protocole s’appelle FTPS et il est distinct.

L’authentification par clé est-elle réellement préférable à un mot de passe ?

Oui, pour tout serveur accessible depuis Internet. Un mot de passe est un secret court que vous transmettez au serveur à chaque connexion, et le port 22 est continuellement ciblé par des clients automatisés. Avec une paire de clés, la clé privée ne quitte jamais votre machine : le client signe des données liées à la session actuelle, et le serveur vérifie cette signature avec la clé publique présente dans ~/.ssh/authorized_keys. Une signature enregistrée ne peut pas être réutilisée contre un autre serveur. Protégez la clé privée avec une phrase secrète, car un fichier de clé sans phrase secrète permet à toute personne qui le copie de se connecter.