SSH

SSH (Secure Shell) permet d’ouvrir une session shell chiffrée sur une machine distante, de transférer des fichiers (via SFTP ou SCP) et de créer des tunnels chiffrés — c’est le moyen d’administration standard des serveurs Linux/Unix, sur le port 22.

Fonctionnement

1. Le client se connecte, et serveur et client négocient les algorithmes de chiffrement, d’échange de clés et d’authentification.
2. Le client vérifie l’identité du serveur via sa clé publique — au premier accès, la clé est présentée (l’empreinte apparaît, à vérifier idéalement par un canal indépendant) puis stockée dans ~/.ssh/known_hosts ; toute clé différente lors d’une connexion ultérieure déclenche un avertissement fort (signe possible d’une attaque de l’homme du milieu, ou simplement d’une réinstallation du serveur).
3. Le client s’authentifie auprès du serveur — par mot de passe, ou de façon plus robuste par paire de clés (une clé privée gardée sur le poste client, une clé publique déposée sur le serveur dans ~/.ssh/authorized_keys).
4. Une fois authentifiée, la session est chiffrée de bout en bout pour toute la durée de la connexion.

Au-delà du shell interactif

• SCP / SFTP : transfert de fichiers au-dessus du même canal chiffré (voir SFTP).
• Port forwarding / tunneling : rediriger un port local ou distant à travers la connexion SSH — utile pour accéder à un service qui n’écoute que sur localhost d’une machine distante, ou pour chiffrer un protocole non sécurisé.

  ssh -L 8080:localhost:80 utilisateur@serveur   # tunnel local

• ProxyJump / bastion : rebondir via un serveur intermédiaire pour atteindre une machine qui n’est pas directement exposée (ssh -J bastion utilisateur@serveur-interne).
• Agent forwarding : réutiliser les clés chargées dans l’agent SSH du poste local pour s’authentifier plus loin, sans copier de clé privée sur les serveurs intermédiaires.

Sécurité

L’authentification par clé publique élimine le risque de bruteforce de mot de passe (voir le tutoriel Durcir un accès SSH pour une mise en place complète : désactivation du mot de passe, fail2ban, restriction d’accès).

Point de vigilance

Une clé privée SSH doit toujours être protégée par une passphrase — sans elle, un vol du fichier de clé (poste compromis, sauvegarde mal protégée) donne un accès direct et silencieux à tous les serveurs où la clé publique correspondante est déployée, sans qu’aucun mot de passe supplémentaire ne bloque l’attaquant.