SSH : sécuriser l’accès distant

SSH-1, le protocole SSH (Shell sécurisé) d'origine, comportait une faille de conception fondamentale qui permettait à un attaquant actif d'insérer des données arbitraires dans une session chiffrée sans être détecté. SSH-2, une refonte complète du protocole publiée en 2006 sous la forme des RFC 4251 à 4254, a corrigé ces faiblesses au moyen de protocoles distincts pour les couches de transport, d'authentification et de connexion, ainsi que d'un contrôle d'intégrité renforcé utilisant HMAC. SSH-1 est obsolète et aucun serveur moderne ne devrait l'activer.

Le protocole de la couche de transport SSH gère l'échange initial de clés et établit un canal chiffré dont l'intégrité est protégée. Il négocie les algorithmes pour l'échange de clés (généralement ECDH), l'authentification de l'hôte (généralement Ed25519 ou RSA), le chiffrement symétrique (généralement AES-256-CTR ou ChaCha20-Poly1305) et le MAC (généralement HMAC-SHA2-256). Chaque paquet ultérieur est à la fois chiffré et soumis à une vérification d'intégrité au moyen des algorithmes négociés.

Une fois la couche de transport sécurisée, la couche d'authentification de l'utilisateur négocie la manière dont celui-ci prouve son identité au serveur. Trois méthodes courantes sont le mot de passe (l'utilisateur saisit un mot de passe, qui est envoyé chiffré sur la couche de transport), la clé publique (l'utilisateur prouve qu'il possède une clé privée correspondant à une clé publique autorisée sur le serveur) et GSSAPI (intégration de l'authentification unique Kerberos pour les environnements d'entreprise).

La couche de connexion SSH multiplexe plusieurs canaux logiques sur l'unique connexion de transport chiffrée. Une session SSH classique comporte un canal pour l'interpréteur de commandes interactif. Des canaux supplémentaires prennent en charge le transfert de ports, le transfert X11 et le transfert de fichiers SFTP, tout en partageant la même connexion authentifiée et chiffrée. Les demandes de canal permettent au client de demander un pseudo-terminal, de définir des variables d'environnement ou d'exécuter une commande précise.

Lors de la première connexion à un serveur SSH, le client reçoit la clé d'hôte du serveur et doit décider s'il peut lui faire confiance. La politique par défaut consiste à faire confiance lors de la première utilisation (TOFU) : l'utilisateur est invité à vérifier l'empreinte de la clé (généralement affichée sous la forme d'un hachage tel que SHA256:...), et si elle est acceptée, elle est stockée dans le fichier known_hosts. Lors des connexions suivantes, la clé stockée est comparée à celle présentée par le serveur, et toute discordance déclenche un avertissement sévère concernant d'éventuelles attaques de l'homme du milieu.

Le fichier known_hosts, stocké à ~/.ssh/known_hosts, contient une base de données des clés d'hôte des serveurs, indexées par nom d'hôte et adresse IP. Chaque entrée associe l'adresse d'un serveur à sa clé publique. Si la clé d'un serveur change, peut-être parce que le serveur a été réinstallé ou parce qu'un attaquant usurpe son identité, SSH refuse de se connecter et affiche un avertissement. Les administrateurs utilisent l'authentification des hôtes par certificat pour éviter les décisions de confiance TOFU à grande échelle.

L'authentification par clé publique stocke la clé publique de l'utilisateur dans ~/.ssh/authorized_keys sur le serveur. Lorsque l'utilisateur se connecte, le serveur envoie un défi chiffré avec la clé publique ; seul le détenteur de la clé privée correspondante peut répondre correctement, prouvant ainsi son identité sans transmettre la clé privée ni un mot de passe. Cette méthode est plus sûre que les mots de passe, car les clés privées ne sont jamais envoyées sur le réseau et ne peuvent pas être obtenues par hameçonnage.

Trois familles d'algorithmes de clés SSH sont couramment utilisées. Les clés RSA de 3072 ou 4096 bits sont compatibles avec tous les serveurs. ECDSA utilisant la courbe P-256 de NIST est plus rapide que RSA à niveau de sécurité équivalent, mais les paramètres de sécurité de P-256 ont suscité des réserves. Ed25519, fondé sur l'algorithme de signature numérique sur courbe d'Edwards, est la recommandation actuelle : des clés de 256 bits rapides et compactes, de solides propriétés de sécurité et aucune préoccupation particulière liée aux paramètres.

Tatu Ylönen, chercheur finlandais à l'Université de technologie d'Helsinki, a développé SSH en 1995 après qu'une attaque d'interception de mots de passe sur le réseau de son université a exposé des centaines d'informations d'authentification. Il a choisi le port 22 parce qu'il se trouvait entre telnet (23) et ftp (21). SSH a remplacé ces deux protocoles non sécurisés. Ylönen a fondé SSH Communications Security, puis a publié SSH-2 comme norme ouverte par l'intermédiaire de l'IETF. OpenSSH, la mise en œuvre libre dominante, a été créée par le projet OpenBSD en 1999.

L'agent SSH est un processus d'arrière-plan qui conserve en mémoire les clés privées déchiffrées, permettant une authentification unique auprès de plusieurs serveurs sans saisir à nouveau la phrase secrète. Le transfert d'agent (indicateur -A) étend ce mécanisme en transférant la connexion de l'agent vers des serveurs distants, ce qui permet d'accéder en un saut à des serveurs internes. Cependant, le transfert d'agent constitue un risque de sécurité : un serveur distant compromis peut utiliser l'agent transféré pour s'authentifier en votre nom auprès d'autres serveurs. Utilisez ProxyJump plutôt que le transfert d'agent.

Une configuration SSH sécurisée consiste notamment à désactiver la connexion de root (PermitRootLogin no), à désactiver l'authentification par mot de passe (PasswordAuthentication no) au profit des seules clés publiques, à utiliser des clés d'hôte Ed25519, à n'activer que le protocole SSH-2, à configurer des délais d'expiration pour les sessions inactives, à restreindre les utilisateurs autorisés avec AllowUsers ou AllowGroups et à modifier le port par défaut comme mesure de dissimulation afin de réduire le bruit des analyses automatisées. Fail2ban ou des outils similaires bloquent les adresses IP après plusieurs tentatives infructueuses.

Pourquoi l'authentification par clé publique de SSH est-elle considérée comme plus sûre que l'authentification par mot de passe ?

SSH-2 a remplacé SSH-1, qui comportait des failles, par des couches distinctes de transport, d'authentification et de connexion. La couche de transport négocie le chiffrement et l'intégrité. L'authentification des utilisateurs prend en charge les mots de passe, les clés publiques et GSSAPI. La vérification des clés d'hôte utilise TOFU et known_hosts. Ed25519 est l'algorithme de clés recommandé. Le transfert d'agent constitue un risque de sécurité ; utilisez ProxyJump à la place. Le renforcement de la sécurité comprend la désactivation de la connexion de root et de l'authentification par mot de passe.