Qui voit réellement votre mot de passe SSH sur un VPN non fiable ?

Faites passer une session SSH par un VPN que vous n’exploitez pas, et le mot de passe appartient toujours au serveur SSH, pas au réseau intermédiaire. Si le transport vers un hôte vérifié est correctement protégé, un observateur passif sur ce chemin n’obtient pas le mot de passe sous une forme lisible. Mais changez une condition, et la réponse change : un hôte non vérifié, une liste de chiffrements affaiblie ou un poste de travail compromis produisent des résultats différents. Exécutez les contrôles ci-dessous dans l’ordre, et traitez chacun comme une condition d’arrêt.

Nommez le destinataire avant de taper quoi que ce soit

Le champ du mot de passe voyage à l’intérieur d’un message d’authentification, et ce message voyage à l’intérieur du transport chiffré. La confidentialité est une propriété du transport, ce qui signifie qu’elle dépend du fait d’avoir négocié une protection et de l’avoir négociée avec l’hôte que vous visiez. C’est précisément cette seconde moitié que les gens sautent. Une connexion chiffrée vers un imposteur est à la fois confidentielle et inutile. La connexion au VPN ne prouve rien sur l’hôte SSH, et la réputation du fournisseur ne remplace pas le contrôle de la clé.

Gardez les deux directions séparées dans votre tête. La clé d’hôte répond à la question de savoir quel serveur vous avez atteint. L’authentification par mot de passe ou par clé répond à la question de savoir quel utilisateur le serveur accepte. Améliorer la seconde ne répare jamais la première.

Vérifiez l’identité de l’hôte, l’enregistrement et la négociation

Commencez côté client avec l’enregistrement que vous détenez déjà. Une empreinte publiée comparée à une source de confiance, et une entrée known_hosts qui correspond encore, vous donnent la seule preuve qui compte avant le début de l’authentification.

ssh-keygen -F ssh.internal.example.net -f ~/.ssh/known_hosts
ssh -o StrictHostKeyChecking=yes ssh.internal.example.net

Côté serveur, imprimez les empreintes que vous comptez publier au lieu de les copier de mémoire. Les distribuer hors du canal est tout l’enjeu ; une empreinte collée depuis le même canal de discussion que le nom d’hôte ne prouve qu’une chose : que les deux viennent du même endroit.

ssh-keygen -lf /etc/ssh/ssh_host_ed25519_key.pub
sudo sshd -T | grep -E 'hostkey|kexalgorithms|cipher'

Les algorithmes négociés proviennent de l’intersection des deux côtés. Si une configuration client épingle un échange de clés obsolète pour joindre un appareil ancien, ce choix s’applique à chaque hôte avec lequel il parle, alors limitez-le à cet hôte plutôt qu’à l’échelle globale.

Lisez les méthodes que le serveur accepte réellement

Savoir quelles méthodes d’authentification un serveur autorise vous dit à quoi sert le mot de passe. Un hôte qui n’accepte que des clés publiques n’a aucun échange de mots de passe à protéger, et un hôte qui accepte encore des mots de passe mérite une décision délibérée plutôt qu’un défaut hérité.

sudo sshd -T | grep -E 'passwordauthentication|pubkeyauthentication|permitrootlogin'

Faire passer un utilisateur à l’authentification par clé retire le mot de passe de cet utilisateur de cet échange. Cela ne rend pas un poste de travail compromis sûr, et cela ne rend pas une session distante non fiable inoffensive. Ce sont des risques différents avec des contrôles différents. Décidez aussi du transfert d’agent. Transférer un agent vers un hôte non fiable donne à cet hôte la capacité d’utiliser vos clés pendant la session, ce qui est une exposition plus large que la question du mot de passe par laquelle tout a commencé.

Traitez un avertissement de clé d’hôte comme une étape d’incident

Quand le client avertit que l’identification de l’hôte a changé, arrêtez-vous et vérifiez par un canal qui ne passe pas par le même chemin réseau. Comparez l’empreinte avec la console du serveur ou avec l’opérateur qui l’a reconstruit. Supprimer l’ancienne entrée pour faire taire l’avertissement est la seule action à refuser. Elle jette la preuve et transforme une interception possible en connexion ordinaire.

Si l’hôte a été reconstruit légitimement, supprimez l’entrée obsolète seulement après confirmation de la nouvelle empreinte, puis reconnectez-vous et vérifiez à nouveau la négociation. Consignez le changement avec la date et la raison, car la personne suivante verra le même avertissement et doit savoir qu’il a été résolu.

Ce que ce guide ne couvre pas

Un opérateur de VPN qui observe le trafic n’est pas la même chose qu’un logiciel disposant de privilèges locaux sur votre machine. La compromission du poste terminal, une extension de navigateur hostile ou un enregistreur de frappe se situent sous tout ce que SSH peut négocier, et aucun tunnel n’y change rien. Si le poste de travail est suspect, suivez la procédure d’incident au lieu de tester le secret en vous reconnectant par une autre sortie. Se reconnecter prouve que le chemin réseau a changé et rien sur le poste terminal.

Terminez par le cas ordinaire : hôte vérifié, transport protégé, la méthode d’authentification que vous avez choisie exprès, et aucun transfert dont vous n’aviez pas besoin. Cette combinaison est la réponse à la question du titre, et ce sont quatre décisions plutôt qu’une.