Module 1 · 1.3
Français
La première connexion SSH
Module 1: Votre premier serveur · Temps de lecture : 10 minutes
Objectif pédagogique : À l'issue de cette leçon, vous saurez vous connecter pour la première fois à votre serveur en SSH, vérifier l'empreinte du serveur avant de lui faire confiance et savoir quoi faire face à l'avertissement indiquant que l'identité du serveur a changé.
Notions clés : SSH, client et serveur, port 22, bannière de version, clé d'hôte (host key), empreinte (SHA256), known_hosts, trust on first use, "REMOTE HOST IDENTIFICATION HAS CHANGED", PowerShell et Terminal
Qu'est-ce que SSH ?
SSH (Secure Shell) est la connexion chiffrée qui vous permet d'administrer un serveur à distance. Vous tapez sur votre propre ordinateur, et les commandes sont exécutées sur le serveur. Tout ce qui transite par la connexion, y compris votre mot de passe, est chiffré.
Il y a deux côtés :
- le client SSH sur votre propre ordinateur : le programme
ssh. Sur macOS et Linux, il est installé par défaut. Sur Windows 10 (à partir de la version 1809) et Windows 11, le client OpenSSH fait partie de Windows ; vous l'utilisez dans PowerShell ou Windows Terminal. S'il manque, ajoutez-le via Paramètres, Fonctionnalités facultatives, "Client OpenSSH". Les programmes à fenêtres comme PuTTY fonctionnent aussi, mais dans cette formation nous utilisonsssh. - le serveur SSH sur le VPS : le programme
sshd(d'OpenSSH). Il écoute par défaut sur le port 22.
Se connecter
Vous vous connectez avec un nom d'utilisateur et l'adresse du serveur :
PS C:\Users\anna> ssh root@192.0.2.10Ou avec un nom, si vous l'avez configuré dans le DNS (leçon 7.1) :
anna@laptop:~$ ssh root@web1.example.comLa première fois, vous voyez quelque chose comme ceci :
The authenticity of host '192.0.2.10 (192.0.2.10)' can't be established.
ED25519 key fingerprint is SHA256:Xq3aTnPpC0m1o4cJ2kVqY8mWb7rZs5dLfE6hUyN9tKs.
This key is not known by any other names.
Are you sure you want to continue connecting (yes/no/[fingerprint])?C'est le moment le plus important de cette leçon. Ne tapez pas yes à l'aveugle.
La clé d'hôte et l'empreinte
Chaque serveur SSH possède une ou plusieurs clés d'hôte (host keys) : des paires de clés avec lesquelles le serveur prouve son identité. Les parties publiques se trouvent sur le serveur dans /etc/ssh/, par exemple /etc/ssh/ssh_host_ed25519_key.pub. À chaque connexion, le serveur démontre qu'il possède la partie secrète.
Une empreinte est un court résumé (un hash) d'une telle clé publique. OpenSSH affiche par défaut la forme SHA256 : SHA256: suivi de 43 caractères.
La question "Are you sure you want to continue connecting?" signifie : votre ordinateur ne connaît pas encore ce serveur. Qui garantit que vous parlez bien à votre VPS et pas à quelqu'un qui intercepte le trafic ? Personne, sauf si vous comparez l'empreinte avec une source fiable.
Cette source, c'est la console de votre fournisseur (leçon 1.2). Là, vous ne communiquez pas avec le serveur par le réseau. Connectez-vous à la console et affichez l'empreinte :
root@web1:~# ssh-keygen -lf /etc/ssh/ssh_host_ed25519_key.pub
256 SHA256:Xq3aTnPpC0m1o4cJ2kVqY8mWb7rZs5dLfE6hUyN9tKs root@web1 (ED25519)Si elle correspond exactement à ce qu'affiche le client, tapez yes. Vous pouvez aussi coller l'empreinte elle-même à la place de yes ; ssh la compare alors pour vous. Si elle diffère, arrêtez-vous et cherchez pourquoi (mauvaise adresse IP, serveur réinstallé, ou quelque chose de plus grave).
Attention au type : le client indique le type (ED25519, ECDSA ou RSA). Comparez l'empreinte du même type. De nombreuses images affichent aussi les empreintes dans la console au premier démarrage (cloud-init), entre des lignes comme BEGIN SSH HOST KEY FINGERPRINTS.
known_hosts et trust on first use
Si vous tapez yes, vous voyez :
Warning: Permanently added '192.0.2.10' (ED25519) to the list of known hosts.Le client enregistre la clé dans ~/.ssh/known_hosts (sous Windows C:\Users\<naam>\.ssh\known_hosts). Désormais, il compare automatiquement à chaque connexion. Ce modèle s'appelle trust on first use (TOFU, confiance à la première utilisation) : la première fois, vous devez vérifier vous-même, ensuite le client surveille.
C'est pourquoi cette première vérification est si importante : si vous faites confiance à une mauvaise clé, le client ne vous avertira plus jamais.
Si vous travaillez vous-même sur un ordinateur sous Debian ou Ubuntu, les noms dans known_hosts sont hachés par défaut (HashKnownHosts yes dans /etc/ssh/ssh_config), vous n'y voyez donc pas d'adresses IP lisibles. Sous Windows et macOS, elles y figurent en clair. La recherche fonctionne partout avec :
anna@laptop:~$ ssh-keygen -F 192.0.2.10
# Host 192.0.2.10 found: line 3
|1|kP9...= ssh-ed25519 AAAAC3NzaC1lZDI1NTE5AAAA..."REMOTE HOST IDENTIFICATION HAS CHANGED"
Il arrive que vous voyiez cet avertissement :
@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@
@ WARNING: REMOTE HOST IDENTIFICATION HAS CHANGED! @
@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@
IT IS POSSIBLE THAT SOMEONE IS DOING SOMETHING NASTY!
...
Host key verification failed.Le serveur présente une autre clé que celle connue de votre client. ssh refuse alors de se connecter. Il existe deux types de causes :
| Normal | Suspect |
|---|---|
| Vous avez réinstallé le VPS (nouvelles clés d'hôte) | Vous n'avez rien changé et pourtant la clé est différente |
| L'adresse IP a été attribuée à un autre serveur | Vous êtes sur un réseau wifi inconnu |
| Vous avez volontairement remplacé les clés d'hôte | L'empreinte dans la console diffère de ce que le client voit maintenant |
S'il y a une explication normale, vérifiez à nouveau l'empreinte dans la console et supprimez seulement ensuite l'ancienne ligne :
anna@laptop:~$ ssh-keygen -R 192.0.2.10
# Host 192.0.2.10 found: line 3
/home/anna/.ssh/known_hosts updated.À la connexion suivante, vous retrouvez la question de la première fois, et vous vérifiez à nouveau. Ne mettez jamais StrictHostKeyChecking no dans vos paramètres pour faire disparaître l'avertissement : vous désactiveriez précisément la protection dont il est question.
La bannière de version
Avant que quoi que ce soit ne soit chiffré, le client et le serveur s'envoient une ligne de texte : la bannière de version. Elle est visible par tout le monde sur internet. Vous la voyez avec ssh -v :
anna@laptop:~$ ssh -v root@192.0.2.10 2>&1 | grep "remote software"
debug1: Remote protocol version 2.0, remote software version OpenSSH_9.6p1 Ubuntu-3ubuntu13.5Le serveur indique ici quel protocole (2.0) et quel logiciel il utilise. Debian et Ubuntu y ajoutent la version du paquet. Ce n'est pas un secret à cacher : les attaquants essaient tout de toute façon, et vous vous protégez par les mises à jour (module 4), pas par une autre bannière. En revanche, c'est pratique : la bannière vous permet de voir de l'extérieur si votre serveur exécute réellement la version mise à jour.
Sur AlmaLinux et Rocky Linux
La connexion et les empreintes fonctionnent de la même façon. Le service s'appelle sshd au lieu de ssh (systemctl status sshd). La bannière ne contient pas de nom de distribution, seulement la version d'OpenSSH.
Résumé
- SSH est la connexion chiffrée vers votre serveur ;
sshest le client,sshdle serveur sur le port 22. - À la première connexion, le client affiche l'empreinte de la clé d'hôte. Comparez-la avec la sortie de
ssh-keygen -lfdans la console avant de taperyes. - Le client enregistre la clé dans
~/.ssh/known_hostset vous avertit désormais lui-même (trust on first use). - "REMOTE HOST IDENTIFICATION HAS CHANGED" est normal après une réinstallation ; sinon, c'est suspect. Ne supprimez une ancienne ligne qu'après vérification, avec
ssh-keygen -R. - La bannière de version est publique ; la protection vient des mises à jour, pas de la dissimulation.
Quiz
Exercice
Exercice Z1.3: Bannière SSH et empreinte de votre serveur. Saisissez l'adresse de votre serveur, la version du logiciel indiquée dans la bannière (comme OpenSSH_9.6p1) et l'empreinte ED25519 que vous avez obtenue dans la console avec ssh-keygen -lf. Le programme établit une seule connexion vers votre port SSH, lit la bannière et la clé d'hôte, puis compare. Il ne se connecte pas à une session.
Pour aller plus loin
- Se connecter à votre VPS en SSH (et créer une clé SSH)
- Plus d'accès à votre VPS : que faire ?
- ssh-keygen(1), options -l, -F et -R : https://manpages.debian.org/trixie/openssh-client/ssh-keygen.1.en.html
- ssh_config(5), StrictHostKeyChecking, FingerprintHash et HashKnownHosts : https://manpages.debian.org/trixie/openssh-client/ssh_config.5.en.html
- RFC 4253, section 4.2 (la bannière de version) : https://www.rfc-editor.org/rfc/rfc4253.html