SSH : clés, configuration, tunnels

SSH est la porte d'entrée de tous les serveurs Linux : administration à distance, copie de fichiers, accès Git, automatisation avec Ansible. Bien l'utiliser, c'est gagner du temps ; bien le configurer, c'est fermer la première cible des attaquants. Cette leçon est théorique : votre machine de lab n'a pas de client SSH, et aucun serveur à joindre.

Ce que vous saurez à la fin : vous connecter avec une clé plutôt qu'un mot de passe, organiser vos connexions dans ~/.ssh/config, copier des fichiers, utiliser un rebond et un tunnel, et durcir un serveur SSH.

1. Se connecter

ssh [email protected]                # utilisateur@machine
ssh -p 2222 [email protected]        # sur un autre port
ssh eleve@serveur 'df -h'             # lance une seule commande et rend la main

À la première connexion, SSH affiche l'empreinte de la clé du serveur et demande confirmation. Elle est ensuite gardée dans ~/.ssh/known_hosts. Si elle change un jour, SSH refuse avec un avertissement : soit le serveur a été réinstallé, soit quelqu'un s'intercale. Vérifiez avant de supprimer l'ancienne entrée (ssh-keygen -R serveur).

2. Les clés plutôt que les mots de passe

ssh-keygen -t ed25519 -C "eleve@portable"     # crée ~/.ssh/id_ed25519 (privée) et id_ed25519.pub (publique)
ssh-copy-id eleve@serveur                     # ajoute la clé publique dans ~/.ssh/authorized_keys du serveur
ssh eleve@serveur                             # plus de mot de passe

• La clé privée ne quitte jamais votre machine, protégée par une phrase de passe et des droits 600.
• La clé publique se distribue librement.
• ssh-agent garde la clé déverrouillée le temps de la session : eval "$(ssh-agent -s)" && ssh-add.

3. ~/.ssh/config : des raccourcis

Host bastion
    HostName 203.0.113.10
    User eleve
    IdentityFile ~/.ssh/id_ed25519

Host app-*
    User deploy
    ProxyJump bastion          # passe par le bastion pour joindre les serveurs internes

ssh bastion suffit, et ssh app-01 traverse automatiquement le bastion. Un bastion est la seule machine exposée sur Internet : les autres ne sont joignables qu'à travers lui.

4. Copier et tunnelliser

scp fichier.tar.gz bastion:/tmp/              # copie simple
rsync -avz dossier/ bastion:/srv/dossier/      # synchronisation : ne transfère que les différences
ssh -L 5432:base-interne:5432 bastion          # tunnel local : localhost:5432 mène à la base interne

Le tunnel -L est précieux pour joindre un service qui n'est pas exposé (une base de données, un tableau de bord) sans ouvrir de port. kubectl port-forward applique la même idée dans Kubernetes.

5. Durcir le serveur

Dans /etc/ssh/sshd_config (ou un fichier de /etc/ssh/sshd_config.d/) :

PasswordAuthentication no        # clés seulement : fin des attaques par mot de passe
PermitRootLogin no               # on se connecte en utilisateur, puis sudo
PubkeyAuthentication yes
AllowUsers eleve deploy          # liste blanche des comptes autorisés

sudo sshd -t                     # vérifie la configuration AVANT de recharger
sudo systemctl reload ssh

Gardez toujours une session ouverte pendant que vous testez une nouvelle configuration dans une seconde fenêtre : une erreur pourrait vous enfermer dehors. Ajoutez ensuite un pare-feu (leçon L.14) et un outil qui bannit les adresses trop insistantes, comme fail2ban.

Validez la leçon avec le questionnaire.