Skip to Content
Serveur LinuxPartie 4 — SSH : accès & durcissement4.1 — SSH : le principe

Chapitre 4.1 — SSH : le principe

⏱️ TL;DR — SSH (Secure Shell) te donne un terminal sur une machine distante, dans un tunnel chiffré. Ton client ssh parle au serveur sshd qui tourne sur le VPS, par défaut sur le port 22. Se connecter tient en une ligne : ssh user@ip. À la première connexion, ton client te montre l’empreinte du serveur et te demande de la valider ; il la range dans ~/.ssh/known_hosts pour reconnaître la machine ensuite. Si un jour cette empreinte change sans raison, SSH hurle : ça peut être une attaque de l’homme du milieu (MITM). Enfin, deux façons de prouver qui tu es : le mot de passe (transmis, bruteforçable) ou une clé (rien de secret ne transite, insensible au bruteforce). On choisit les clés — c’est tout le chapitre suivant.

🎯 Objectifs

  • Expliquer ce qu’est SSH : un shell distant chiffré entre un client et un serveur sshd.
  • Te connecter à un VPS avec ssh user@ip (et sur un port non standard).
  • Comprendre l’empreinte du serveur, le fichier known_hosts et pourquoi SSH t’avertit à la première connexion.
  • Reconnaître une alerte de changement d’empreinte et savoir qu’elle peut signaler une attaque MITM.
  • Distinguer l’authentification par mot de passe de l’authentification par clés, et savoir pourquoi les clés sont supérieures.

SSH, c’est quoi au juste

Sur ton portable, tu ouvres un terminal et tu tapes des commandes sur ta machine. SSH fait exactement pareil, mais sur une machine qui est ailleurs : tu tapes chez toi, ça s’exécute là-bas, et le résultat revient sur ton écran. Comme si tu étais assis devant le serveur.

Deux acteurs :

  • Le client : le programme ssh sur ton poste (installé d’office sur macOS, Linux, et Windows moderne).
  • Le serveur : un service nommé sshd (le d de daemon) qui écoute en permanence sur le VPS et attend les connexions.

Entre les deux, tout est chiffré. Personne sur le réseau — ton FAI, un wifi public, un routeur au milieu — ne peut lire tes commandes, ton mot de passe, ni ce que le serveur te renvoie. C’est la différence avec les vieux protocoles comme Telnet, qui envoyaient tout en clair.

🔒 Sécurité — SSH chiffre le transport, mais il fait aussi deux autres choses cruciales : il authentifie le serveur (tu es sûr de parler à ta machine, pas à un imposteur) et il t’authentifie auprès du serveur (le VPS est sûr que c’est bien toi). Chiffrement, identité du serveur, identité du client : ces trois garanties sont ce qui rend SSH sûr. On les détaille dans ce chapitre.

Se connecter : la commande de base

La forme la plus courante :

ssh deploy@203.0.113.10
# ssh          -> le client SSH
# deploy       -> l'utilisateur SOUS lequel tu ouvres la session sur le serveur
# @203.0.113.10 -> l'adresse (IP ou nom de domaine) de la machine distante

Tu peux viser un nom de domaine au lieu d’une IP :

ssh deploy@vps.formacampus.fr

Par défaut, ssh frappe au port 22 — le port standard de SSH. Si le serveur écoute sur un autre port (on verra en 4.4 pourquoi certains le déplacent), tu le précises avec -p :

ssh deploy@203.0.113.10 -p 2222
# -p 2222 -> connecte-toi au port 2222 au lieu du port 22 par defaut

Une fois connecté, ton prompt change : tu passes de toi@ton-portable à quelque chose comme deploy@vps:~$. Tu es sur le serveur. Toutes tes commandes s’exécutent là-bas jusqu’à ce que tu tapes exit (ou Ctrl-D) pour revenir chez toi.

🐚 Au terminal — Le premier réflexe après une connexion : vérifier où tu es et qui tu es, pour ne pas taper une commande destructrice sur la mauvaise machine.

hostname   # le nom de la machine : suis-je bien sur le VPS ?
whoami     # quel utilisateur : deploy ? root ?
pwd        # dans quel dossier je me trouve

La première connexion : l’empreinte du serveur

La toute première fois que tu contactes un serveur, ssh affiche un message de ce genre :

The authenticity of host '203.0.113.10' can't be established.
ED25519 key fingerprint is SHA256:aZ9c...k4Q.
Are you sure you want to continue connecting (yes/no/[fingerprint])?

Traduction : « je ne connais pas encore cette machine ; voici son empreinte (fingerprint), un condensé unique de sa clé publique de serveur. Tu confirmes que c’est bien elle ? »

Pourquoi cette question ? Parce que SSH veut que tu garantisses, une fois, l’identité du serveur. Idéalement, tu compares cette empreinte à celle que ton hébergeur t’a fournie (dans la console du VPS, l’email de création…). En pratique, sur un VPS que tu viens de créer, on répond yes. Dès lors, ssh mémorise l’empreinte dans un fichier :

~/.ssh/known_hosts

À partir de là, à chaque reconnexion, ton client recompare l’empreinte reçue à celle stockée. Si elles correspondent : silence, ça passe. C’est ta garantie de parler toujours à la même machine.

💡 Réflexe — Réponds yes machinalement seulement sur une machine que tu viens de créer et dont tu contrôles l’adresse. Si un jour tu te connectes à une infrastructure sensible, compare vraiment l’empreinte affichée à celle communiquée par une voie sûre. C’est le seul moment où l’humain valide l’identité du serveur — après, la machine s’en charge.

Quand l’empreinte change : l’alerte MITM

Voici le message qui doit te faire dresser l’oreille :

@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@
@    WARNING: REMOTE HOST IDENTIFICATION HAS CHANGED!    @
@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@

Ton client dit : « l’empreinte de ce serveur ne correspond plus à celle que j’avais enregistrée ». Et il refuse de continuer. Deux explications possibles :

  1. Légitime : le serveur a été réinstallé (ses clés de serveur ont été régénérées), ou tu réutilises une IP qui appartient maintenant à une autre machine. Fréquent quand on recrée un VPS.
  2. Attaque : quelqu’un s’est inséré au milieu de la connexion (Man In The Middle, MITM) et se fait passer pour ton serveur pour intercepter ce que tu tapes — y compris ton mot de passe.

SSH ne peut pas deviner lequel des deux : il bloque et te laisse trancher. Si tu sais que le serveur a été réinstallé, tu retires l’ancienne empreinte puis tu revalideras la nouvelle :

ssh-keygen -R 203.0.113.10
# -R <hote> -> supprime les cles memorisees pour cet hote dans known_hosts
# a la prochaine connexion, ssh te reposera la question de la premiere fois

⚠️ Piège — Voir cette alerte et contourner à l’aveugle (éditer known_hosts sans réfléchir, ou pire, désactiver la vérification) parce que « c’est chiant ». Si tu n’as pas réinstallé le serveur, cette alerte est peut-être la seule chose qui te sépare d’un attaquant qui lit ta session. Comprends pourquoi l’empreinte a changé avant de la revalider.

Prouver qui tu es : mot de passe ou clés

Le serveur t’a laissé entrer dans le tunnel chiffré, il connaît son identité — reste à prouver la tienne. Deux méthodes :

Le mot de passe

Tu tapes le mot de passe du compte, il transite (chiffré par le tunnel) jusqu’au serveur qui le vérifie. Ça marche, mais :

  • Le secret voyage : il quitte ta machine à chaque connexion. Le tunnel le protège, mais le mot de passe existe « des deux côtés ».
  • Il est bruteforçable : des robots frappent le port 22 en boucle et essaient des millions de mots de passe. Un mot de passe faible finit par tomber. C’est un fait mesurable — les logs d’un VPS neuf en sont pleins.

Les clés

Tu génères une paire : une clé privée (qui ne quitte jamais ta machine) et une clé publique (que tu déposes sur le serveur). À la connexion, le serveur te lance un défi que seule ta clé privée peut résoudre. Résultat :

  • Aucun secret ne transite. Ta clé privée reste chez toi ; le serveur ne voit que la preuve que tu la détiens.
  • Le bruteforce est vain : une clé ed25519 ne se devine pas — l’espace des possibles est astronomique. Les robots peuvent frapper des années, ils n’entreront pas.

🔒 Sécurité — C’est le choix de sécurité fondateur de ce cours : sur un serveur exposé, on désactive l’authentification par mot de passe et on n’autorise que les clés (voir 4.4). À lui seul, ce réglage élimine l’écrasante majorité des attaques SSH — celles des robots qui tentent des mots de passe au hasard. Comprendre pourquoi est le sujet du chapitre 4.2.

Le premier contact avec un VPS neuf

Concrètement, quand ton hébergeur te livre un VPS Ubuntu tout frais, tu reçois en général une IP et un accès initial : soit un mot de passe root par email, soit (mieux) une clé que tu as fournie au moment de la commande, déjà déposée. Le premier ssh ressemble à ceci :

ssh root@203.0.113.10
# premiere connexion : ssh affiche l'empreinte, tu reponds yes
# puis le mot de passe root (si l'hebergeur en a fourni un)

À partir de là, tout le travail des parties 4 et 5 consiste à transformer cet accès brut et fragile (root, mot de passe) en un accès sûr : créer un utilisateur deploy, y déposer ta clé, couper root et le mot de passe. On ne reste jamais sur l’accès root par mot de passe d’origine.

🧭 Sur FormaCampus — L’équipe de FormaCampus commande un VPS Ubuntu LTS chez son hébergeur. L’IP arrive par email, avec un mot de passe root temporaire. Leur tout premier ssh root@… sert uniquement à préparer le terrain : ils vont créer l’utilisateur deploy, y installer les clés de chaque membre de l’équipe, puis verrouiller root et le mot de passe. Objectif de la partie : que plus personne ne se connecte en root ni par mot de passe — uniquement deploy, uniquement par clé. Le mot de passe root de l’email finira inutilisable, et c’est très bien.

En résumé

SSH = un shell distant dans un tunnel chiffré, entre ton client ssh et le sshd du serveur, port 22 par défaut. Il authentifie le serveur (empreinte + known_hosts, alerte si ça change) et t’authentifie (mot de passe ou, bien mieux, clés). Le reste de la partie construit l’accès par clés, la config client qui rend ça confortable, et le durcissement du serveur.

✏️ Exercices

Exercice 1 — Lis la commande. Un collègue te donne cette ligne : ssh admin@vps.exemple.fr -p 2222. Décompose chaque morceau : que vaut l’utilisateur, l’hôte, le port ? Sur quel port se connecterait-on sans le -p ?

✅ Solution

admin = l’utilisateur sous lequel on ouvre la session. vps.exemple.fr = l’hôte distant (un nom de domaine, résolu en IP par le DNS). -p 2222 = le port SSH visé, ici 2222 (non standard). Sans -p, ssh viserait le port 22, le port par défaut de SSH.

Exercice 2 — Alerte à l’empreinte. Tu te connectes à un serveur que tu utilises depuis des mois et tu tombes sur WARNING: REMOTE HOST IDENTIFICATION HAS CHANGED!. Tu n’as rien réinstallé. Que fais-tu, et pourquoi pas simplement forcer la connexion ?

✅ Solution

Je ne force pas. L’empreinte a changé alors que je n’ai pas touché au serveur : ça peut être une attaque MITM (quelqu’un intercepte ma connexion en se faisant passer pour le serveur). J’enquête d’abord : le serveur a-t-il été réinstallé à mon insu (par un collègue, l’hébergeur) ? L’IP a-t-elle été réattribuée ? Je vérifie par une voie sûre (console de l’hébergeur, l’empreinte officielle). Seulement si le changement est légitime, je retire l’ancienne empreinte avec ssh-keygen -R <hote> puis je revalide. Forcer à l’aveugle, ce serait potentiellement livrer ma session (et mon mot de passe) à l’attaquant.

Exercice 3 — Mot de passe ou clé ? Explique, en une phrase chacun, deux raisons concrètes pour lesquelles une clé SSH est plus sûre qu’un mot de passe sur un serveur exposé à Internet.

✅ Solution

(1) Rien de secret ne transite : la clé privée reste sur ma machine, le serveur ne reçoit qu’une preuve que je la détiens, alors qu’un mot de passe voyage (même chiffré) à chaque connexion. (2) Insensible au bruteforce : une clé ed25519 ne se devine pas (espace de possibles astronomique), là où les robots qui frappent le port 22 finissent par casser un mot de passe faible.

🧠 Quiz de révision

1. Quels sont les deux programmes en jeu dans une connexion SSH, et où tourne chacun ?

Le client ssh, sur ton poste, qui initie la connexion ; et le serveur sshd (un daemon), qui tourne en permanence sur le VPS et écoute les connexions (port 22 par défaut). Le client parle au serveur dans un tunnel chiffré.

2. À quoi sert le fichier ~/.ssh/known_hosts ?

Il mémorise l’empreinte des serveurs auxquels tu t’es déjà connecté. À chaque reconnexion, ssh recompare l’empreinte reçue à celle stockée pour garantir que tu parles bien à la même machine. Une divergence déclenche une alerte (possible MITM).

3. Pourquoi ssh te pose-t-il une question à la toute première connexion à un serveur ?

Parce qu’il ne connaît pas encore ce serveur : il te montre son empreinte et te demande de valider son identité une première fois. Ta réponse yes enregistre l’empreinte dans known_hosts. C’est le seul moment où l’humain garantit l’identité du serveur.

4. Que peut signaler une alerte « REMOTE HOST IDENTIFICATION HAS CHANGED » ?

Soit un changement légitime (serveur réinstallé, clés de serveur régénérées, IP réattribuée), soit une attaque MITM où un tiers s’intercale et se fait passer pour ton serveur. SSH bloque et te laisse trancher : il faut comprendre la cause avant de revalider.

5. En quoi une clé SSH « ne fait jamais voyager de secret », contrairement au mot de passe ?

Avec une clé, la partie privée reste sur ta machine ; le serveur t’envoie un défi que seule ta clé privée peut résoudre, et il ne voit que la preuve que tu la détiens — jamais la clé elle-même. Un mot de passe, lui, est transmis au serveur à chaque connexion (protégé par le tunnel, mais transmis).

Chapitre suivant : Les clés SSH — générer ta paire, la déposer sur le serveur, et ne plus jamais taper de mot de passe.

Last updated on
Vue d'ensemble4.2 — Les clés SSH