Chapitre 02
SSH : gérer & sécuriser l'accès

1. Clé plutôt que mot de passe

Une authentification par mot de passe est fragile (rejouable, devinable, saisie à chaque connexion) et pénible à automatiser. On lui préfère une paire de clés : une clé privée qui reste sur le laptop, une clé publique qu'on dépose sur l'edge. On génère la paire une fois :

# Sur le laptop — clé Ed25519 (moderne, courte, rapide)
ssh-keygen -t ed25519 -C "eng-laptop maint"
# → crée ~/.ssh/id_ed25519 (privée) et ~/.ssh/id_ed25519.pub (publique)

On copie ensuite la clé publique sur l'edge. La façon la plus sûre :

laptop:~$ ssh-copy-id maint@192.168.0.10
/usr/bin/ssh-copy-id: INFO: attempting to log in with the new key(s)...
maint@192.168.0.10's password: (dernière fois qu'on le tape !)
Number of key(s) added: 1

La clé publique atterrit dans ~/.ssh/authorized_keys sur l'edge. La prochaine connexion se fait sans mot de passe :

laptop:~$ ssh maint@192.168.0.10
maint@edge-cell12:~$   # entré directement, via la clé

2. ~/.ssh/config : arrêter de tout retaper

Taper ssh maint@192.168.0.10 vingt fois par jour, avec des options, est vite fastidieux. Le fichier ~/.ssh/config sur le laptop mémorise tout sous un alias :

# ~/.ssh/config (sur le laptop)
Host edge12
    HostName 192.168.0.10
    User maint
    IdentityFile ~/.ssh/id_ed25519
    ServerAliveInterval 30      # ping applicatif : détecte une coupure
    ServerAliveCountMax 3

Désormais un simple ssh edge12 suffit. ServerAliveInterval évite les sessions « gelées » quand le réseau OT hoquette : SSH envoie un petit paquet toutes les 30 secondes et ferme proprement au bout de 3 sans réponse.

Rebondir par un jump host

Souvent, l'edge n'est pas joignable directement depuis le poste bureautique : il faut d'abord passer par une machine de rebond (un bastion ou un serveur de saut sur la DMZ OT). SSH gère ce rebond nativement avec ProxyJump :

# ~/.ssh/config — rebond par un bastion
Host bastion
    HostName bastion.usine.local
    User camille

Host edge12
    HostName 192.168.0.10
    User maint
    ProxyJump bastion            # ← rebond automatique

Un ssh edge12 ouvre alors la session à travers le bastion, en une seule commande. Le trafic reste chiffré de bout en bout ; le bastion ne fait que relayer.

3. Tunnels : atteindre ce qui est « derrière » l'edge

L'edge voit des équipements que le laptop ne joint pas directement : le serveur web du CPU S7-1500, une interface d'admin d'un conteneur qui n'écoute que sur localhost, le broker MQTT. Un tunnel local (-L) transporte un port distant jusqu'au laptop :

# Depuis le laptop : exposer le web du CPU (192.168.0.1:443) sur localhost:8443
ssh -L 8443:192.168.0.1:443 edge12
# → puis, dans le navigateur du laptop : https://localhost:8443

Lecture de -L 8443:192.168.0.1:443 : « écoute en local sur 8443, et fais ressortir la connexion depuis l'edge vers 192.168.0.1:443 ». La destination est résolue du point de vue de l'edge : c'est tout l'intérêt.

4. Durcir le sshd de l'edge

Une fois les clés en place, on peut resserrer la configuration du serveur SSH. Elle vit dans /etc/ssh/sshd_config sur l'edge. Les réglages qui comptent :

# /etc/ssh/sshd_config (sur l'edge) — extrait durci
PermitRootLogin no              # jamais de login root direct
PasswordAuthentication no       # clés uniquement
KbdInteractiveAuthentication no
AllowUsers maint                # liste blanche de comptes
X11Forwarding no
# (Optionnel) restreindre au segment OT :
# ListenAddress 192.168.0.10

On applique sans couper la session en cours : on teste d'abord la syntaxe, puis on recharge (pas restart) le service.

maint@edge-cell12:~$ sudo sshd -t          # valide la syntaxe, ne dit rien si OK
maint@edge-cell12:~$ sudo systemctl reload ssh
# reload ré-applique la config sans fermer les connexions établies

5. Quand ça ne passe pas : ssh -v

Une connexion qui échoue est frustrante parce que le message par défaut est laconique. L'option -v (jusqu'à -vvv) déroule chaque étape de la négociation et montre où ça bloque.

laptop:~$ ssh -v edge12
OpenSSH_9.2p1 Debian-2, OpenSSL 3.0.11
debug1: Connecting to 192.168.0.10 [192.168.0.10] port 22.
debug1: connect to address 192.168.0.10 port 22: Connection timed out

À chaque symptôme sa cause probable :

6. known_hosts et l'empreinte qui change

SSH mémorise l'empreinte de chaque hôte dans ~/.ssh/known_hosts. Si elle change, il refuse net de se connecter avec un avertissement alarmant :

@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@
@    WARNING: REMOTE HOST IDENTIFICATION HAS CHANGED!     @
@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@
Someone could be eavesdropping on you right now (man-in-the-middle attack)!

La cause bénigne et fréquente : l'edge a été réinstallé ou son OS régénéré, donc sa clé d'hôte est neuve. Après avoir confirmé que c'est bien le cas (et pas une usurpation), on retire l'ancienne entrée :

laptop:~$ ssh-keygen -R 192.168.0.10
# retire l'ancienne empreinte ; la prochaine connexion en redemandera confirmation

Récapitulatif

Exercices

Host edge12
    HostName 192.168.0.10
    User maint
    IdentityFile ~/.ssh/id_ed25519

laptop:~$ ssh -L 8443:192.168.0.1:443 edge12