Est-il possible dempêcher le message suivant concernant: (LIDENTIFICATION DE LHÔTE À DISTANCE A CHANGÉ)
Lorsque vous utilisez uniquement cette syntaxe de connexion
ssh xxx.xxx.xxx.xxx exemple de message davertissement:
ssh 10.19.11.1 CentOS release 5.8 (Final) Kernel 2.6.18-308.el5 on an i686 @@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@ @ 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 the RSA host key has just been changed. The fingerprint for the RSA key sent by the remote host is dd:6f:32:8f:8f:8c:70:9c:95:f1:48:83:60:97:cc:ed. Please contact your system administrator. Add correct host key in /root/.ssh/known_hosts to get rid of this message. Offending key in /root/.ssh/known_hosts:7 RSA host key for 10.19.11.1 has changed and you have requested strict checkin. Host key verification failed. chaque fois que je reçois ce message, je nettoie le /root/.ssh/known_hosts
comme
cp /dev/null /root/.ssh/known_hosts Jétais aussi pensant définir la commande cp / dev / null /root/.ssh/known_hosts dans la crontab,
donc chaque jour à 24h00 il nettoie le fichier known_hosts (cette solution diminue ce problème mais ne le résout pas )
donc cette solution nest pas si bonne solution car lutilisateur peut obtenir le message davertissement bien que nous nettoyions le fichier known_hosts chaque jour
peut-être que nous pouvons faire quelque chose sur / etc / ssh / ssh_config afin dempêcher la vérification de la clé dhôte SSH?
remarque:
Je ne veux pas utiliser la méthode suivante pour pr événement la vérification de la clé dhôte SSH (car jutilise réflexion / mastic)
ssh -o UserKnownHostsFile=/dev/null -o StrictHostKeyChecking=no [email protected] Jinsiste pour nutiliser que cette syntaxe comme
ssh xxx.xxx.xxx.xxx pour la connexion
Commentaires
- En termes simples: don ' t le faire. Avez-vous lu cet avertissement? Il y a une raison à cet avertissement. Et cest pour vous protéger des dommages causés par une attaque MitM et dautres mauvaises choses.
Réponse
Mise à jour: De nos jours, vous pouvez utiliser des certificats SSH , similaires à TLS certificats. Ensuite, vous pouvez ajouter une entrée known_hosts pour faire confiance au certificat plutôt quaux clés individuelles, et vous ne recevrez plus jamais ce message.
Tenez compte de l’avertissement de @ 0xC0000022L !
Si vous savez que la clé d’hôte a changé , vous pouvez supprimer cette entrée spécifique du fichier known_hosts:
ssh-keygen -R xxx.xxx.xxx.xxx Cest bien mieux que décraser la totalité hosts (ce qui peut être fait avec seulement > /root/.ssh/known_hosts).
Si vous ne voulez pas utiliser ssh options de ligne de commande, je crois que la seule autre façon de le faire serait de modifier le code SSH et de le recompiler. Ce que vous vraiment je ne veux pas faire!
Commentaires
- mais je veux le faire de manière automatique, lorsque lutilisateur se plaint de cela, je ne le fais pas Je ne veux pas le faire manuellement
- Vous ne ' ne voulez pas le faire manuellement (supprimer g
known_hostsentrées), et vous ne ' ne voulez pas le faire automatiquement (en utilisantsshoptions). Comment voulez-vous le faire alors? - @ l0b0 En donnant une option de ligne de commande pour supprimer la fonctionnalité. Dans certains environnements, tels que les environnements de machines virtuelles et dautres configurations très dynamiques (en particulier les environnements de test), ces clés dhôte changent fréquemment et comme elles se trouvent sur un réseau isolé, il y a peu de sécurité à gagner en effectuant la vérification. Devoir faire un
ssh-keygen -Rà chaque fois est ennuyeux. Je suppose que lon pourrait écrire un shell pour ssh, un script shell qui analyse ladresse de destination et pré-supprime la clé avant de passer des options à ssh, mais cela semble exagéré.
Réponse
étape 1: supprimer la clé défectueuse
ssh-keygen -R 192.168.1.1 étape 2: ajouter une nouvelle clé
ssh-keyscan 192.168.1.1 >> ~/.ssh/known_hosts ou selon votre situation
> ~/.ssh/known_hosts ssh-keyscan 192.168.1.1 192.168.1.2 ... >> ~/.ssh/known_hosts Commentaires
- -1 pour avoir fourni une arme à pied sans avertissement.
- @ l0b0 Très bien votre honneur!
Réponse
Lorsque vous vous connectez à des machines virtuelles jetables ou autres, vous devriez mieux ne pas stocker les clés en premier lieu.
Créez un ssh0 alias ou fonction avec le contenu suivant:
alias ssh0="ssh -o UserKnownHostsFile=/dev/null -o StrictHostKeyChecking=no -o LogLevel=ERROR" De cette façon, vous ne polluerez pas votre ~/.known_hosts avec des ordures, et puisque vous utilisez une commande différente, il y aurait un limite entre le « vrai » ssh et celui utilisé pour instrumenter un widget local.
Un autre alias utile est
alias sshy="ssh -o CheckHostIP=no" lorsque vous « se connecter à un appareil qui change fréquemment son adresse IP, par exemple. un routeur domestique auquel le FAI attribue une adresse IP différente à chaque fois quil est mis hors tension.
Commentaires
- Réponse parfaite à cela!