L'identification de l'hôte SSH change sur un réseau sans fil
Je me connecte régulièrement via SSH à un serveur distant, depuis un système Ubuntu, sur le port par défaut 22. Appelons le serveur example.org. Je suis sûr que ce serveur est correctement configuré et j'ai confirmé que le problème suivant est indépendant de mon système d'exploitation et persiste pendant les réinstallations.
Il existe un point d'accès Wifi particulier où, si je me connecte au serveur (ssh example.org), J'ai compris:
@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@
@ WARNING: REMOTE Host IDENTIFICATION HAS CHANGED! @
@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@
IT IS POSSIBLE THAT SOMEONE IS DOING SOMETHING NASTY!
Someone could be eavesdropping on you right now (man-in-the-middle attack)!
It is also possible that a Host key has just been changed.
The fingerprint for the ED25519 key sent by the remote Host is
SHA256:[REDACTED].
Please contact your system administrator.
Add correct Host key in /home/user/.ssh/known_hosts to get rid of this message.
Offending ED25519 key in /home/user/.ssh/known_hosts:3
remove with:
ssh-keygen -f "/home/user/.ssh/known_hosts" -R "serv.org"
ED25519 Host key for serv.org has changed and you have requested strict checking.
Host key verification failed.
Le point d'accès problématique appartient à un établissement universitaire et semble être plus verrouillé que les réseaux ISP commerciaux (par exemple, je ne peux pas télécharger de torrents dessus). Si je retourne sur un autre réseau (par exemple, en utilisant mon téléphone comme point d'accès), je peux me reconnecter.
Selon Wireshark:
- La requête DNS (à
8.8.8.8) pourexample.orgrenvoie la même adresse IP, même sur le point d'accès problématique. - L'échange de clés SSH semble se produire comme d'habitude, mais la clé envoyée par le serveur dans la "Réponse d'échange de clés ECDH" a en effet une empreinte digitale différente lorsque je me connecte via l'AP problématique.
Je ne comprends pas ce que fait ce réseau. Bloquer le port 22 serait une chose, mais ici, je semble atteindre le serveur et obtenir une mauvaise clé en réponse.
Ce point d'accès pourrait-il altérer intentionnellement la connexion SSH? Y a-t-il un moyen pour moi d'utiliser SSH en toute sécurité malgré cela? Dois-je simplement éviter de l'utiliser?
Soit les clés de l'hôte de ce système changent, soit quelqu'un/quelque chose est en train de MITMER la connexion SSH.
La ligne de conduite appropriée consiste à considérer cet hôte comme compromis (bien que ce ne soit probablement pas l'hôte lui-même, plutôt la connexion) à moins que/jusqu'à ce que vous ayez une explication.
Vous voudrez peut-être contacter l'administrateur système de ce point d'accès et l'informer de vos préoccupations et essayer de le suivre avec lui.
Puisqu'il s'agit d'un établissement universitaire, je pense que c'est probablement un pare-feu/passerelle de sécurité qui intercepte et analyse le trafic SSH pour des choses comme la prévention de la perte de données (DLP) ou la journalisation d'audit générale.
Par exemple d'un tel pare-feu: https://docs.paloaltonetworks.com/pan-os/9-0/pan-os-admin/decryption/decryption-concepts/ssh-proxy.html
La réponse de Davidgo est correcte. Notez que, tant que vous utilisez l'authentification pubkey et non le mot de passe, ce MITM ne compromet pas la sécurité de vos informations d'identification. Mais cela compromet la confidentialité et l'authenticité de tout ce qui est transmis au cours de la session. Notez que "l'authenticité de tout ce qui est transmis au cours de la session" inclut (plutôt, consiste probablement entièrement en) des commandes envoyées au shell ou quel que soit le processus avec lequel vous interagissez et la sortie renvoyée.
J'avais initialement suggéré ce qui suit, ce qui est dangereusement faux, au moins sans autres mesures:
Une solution de contournement simple est double-ssh. En supposant que l'hôte auquel vous vous connectez permet le transfert de port, connectez-vous une fois avec la connexion compromise, en utilisant l'authentification pubkey et avec le transfert activé pour transférer un port local vers
localhost:22, par exemple.-L 12345:localhost:22. Maintenant, vous pouvez exécuter une deuxième session ssh tunnelisée à travers la première, et à moins que l'attaquant n'anticipe activement ce que vous faites, cette deuxième session aura la bonne empreinte digitale de l'hôte et vous savez qu'elle est en fait sécurisée, non soumise à l'interception par le MITM.
Cela a été écrit à la hâte comme une simplification par rapport à la bonne façon que j'avais en tête de le faire, c'est-à-dire d'avoir un compte de connexion séparé utilisé uniquement pour le transfert, sans Shell, qui, je crois, est toujours sûr à utiliser avec un compromis (MITM '' d) connexion, mais je conseillerais toujours la prudence. Il peut également être possible de configurer votre authorized_keys fichier pour limiter la clé que vous utilisez pour la connexion initiale (MITM'd) afin qu'il ne puisse pas émettre de commandes, uniquement transférer les connexions; si c'est le cas, une telle configuration devrait être sûre.