Question Comment supprimer la vérification de clé RSA stricte dans SSH et quel est le problème ici?


J'ai un serveur Linux qui chaque fois que je me connecte me montre le message qui a changé la clé d'hôte SSH:

$ ssh root @ host1   @@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@ @@@@@@@@@   @ AVERTISSEMENT: HÔTE DISTANT   L'IDENTIFICATION A CHANGÉ! @   @@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@ @@@@@@@@@   IL EST POSSIBLE QUE QUELQU'UN FAIT   Quelque chose de méchant! Quelqu'un pourrait être   vous écoute en ce moment   (attaque de l'homme au milieu)! C'est aussi   possible que la clé de l'hôte RSA a   vient d'être changé. L'empreinte digitale pour   la clé RSA envoyée par l'hôte distant est   93: a2: 1b: 1c: 5f: 3e: 68: 47: bf: 79: 56: 52: f0: ec: 03: 6b.   S'il vous plaît contacter votre système   administrateur. Ajouter la clé d'hôte correcte dans   /home/emerson/.ssh/known_hosts à obtenir   débarrasser de ce message. Clé en infraction   /home/emerson/.ssh/known_hosts:377

La clé d’hôte RSA pour hôte1 a changé et   vous avez demandé une vérification stricte.   La vérification de la clé de l'hôte a échoué.

Il me garde connecté pendant quelques secondes, puis ferme la connexion.

host1: ~ / .ssh # Lecture depuis l'hôte distant host1: connexion réinitialisée par un homologue   Connexion à host1 fermée.

Est-ce que quelqu'un sait ce qui se passe et ce que je pourrais faire pour résoudre ce problème?


36
2018-05-08 11:34


origine


Cette dupes question précédente: serverfault.com/questions/2988/… - Drew Stephens


Réponses:


S'il vous plaît, ne supprimez pas l'intégralité du fichier known_hosts comme recommandé par certaines personnes, cela annule totalement le sens de l'avertissement. C'est une fonction de sécurité qui vous avertit qu'une attaque au centre pourrait avoir eu lieu.

Je vous suggère d'identifier la raison pour laquelle quelque chose a changé, probablement une mise à niveau de SSH a modifié les clés de cryptage en raison d'une éventuelle faille de sécurité. Vous pouvez ensuite purger cette ligne spécifique de votre fichier known_hosts:

sed -i 377d ~/.ssh/known_hosts

Ce La ligne 377 d’élètes comme indiqué après les deux points dans l’avertissement:

/home/emerson/.ssh/known_hosts:377

Vous pouvez également supprimer la clé appropriée en procédant comme suit:

ssh-keygen -R 127.0.0.1 (obviously replace with the server's IP)

Veuillez NE PAS purger le fichier entier et assurez-vous qu'il s'agit bien de la machine à laquelle vous voulez vous connecter avant de purger la clé spécifique.


61
2018-05-08 11:47



Ne pas supprimer plus de 350 serveurs en raison d'une incompatibilité de clé. Une idée pourquoi il continue à fermer la connexion? - setatakahashi
N’est-il pas résolu une fois que vous avez supprimé l’enregistrement abouti_connu pertinent? Sinon, pourriez-vous exécuter le client ssh en mode commenté et le coller quelque part. - Adam Gibbins
Il ferme la machine car la clé d’hôte n’est pas valide, comme elle le dit. Si vous êtes sérieux au sujet de la sécurité, vous devez vérifier auprès de l'administrateur du serveur pour vous assurer que la clé de l'hôte a changé pour une raison légitime. Si c'est le cas, vous pouvez le remplacer, comme l'a expliqué Adam. - Matthew Flaschen
J'ai suivi votre suggestion, mais $ sed -i "46 d" ~ / .ssh / known_hosts sed: 1: "/Users/myusr/.ssh ...": caractères supplémentaires à la fin de la commande, je l'ai donc supprimé manuellement avec Vim et cela a fonctionné. Merci! - Luis Ramirez-Monterosa
La syntaxe d'Adam est presque correcte, mais vous avez besoin d'un espace entre le "377" et le "d". De plus, sous OS X, les hôtes connus se trouvent dans ~ / .ssh / known_hosts; notez l'absence d'un "." dans le nom du fichier. - ktappe


Je pense que même si certaines des réponses ici traitent du plan d'action recommandé dans la question du PO, cela ne répond pas complètement à la question.

La question indique "Comment supprimer la vérification de clé RSA stricte dans SSH et quel est le problème ici?"

Le problème ici est, comme l'ont conseillé d'autres personnes, un changement d'hôte probablement dû à la réinstallation du serveur (scénario le plus courant). Et la solution recommandée consiste en effet à supprimer la clé incriminée du fichier .ssh / allowed_keys avec un fichier sed intégré.

Cependant, je n'ai vu aucune réponse aborder la partie spécifique de la question "Comment supprimer la vérification de clé RSA stricte dans SSH".

Vous pouvez supprimer la vérification StrictHostKey dans votre fichier de configuration ssh, généralement stocké sur ~/.ssh/config.

Un exemple de bloc hôte est fourni ci-dessous:

Host 101
  HostName yourip|hostname
  User youruserid
  IdentityFile /path/to/keyfile
  Port 22
  StrictHostKeyChecking no

La ligne spécifiquement ajoutée est la dernière StrictHostKeyChecking no qui fait exactement ce que ça. En fonction de votre scénario, cela peut vous être utile, par exemple exécuter plusieurs conteneurs virtualisés sur un serveur dédié sur quelques ips, arrêter et démarrer une autre instance sur la même adresse IP.


20
2017-08-15 16:38



+1 Parce que cette publication s’applique réellement à la partie de vérification stricte du message d’erreur. - Shibumi
+1 de moi aussi pour répondre au contenu de la question. Selon les facteurs, il peut y avoir plus à faire. Cette approche dégrade la vérification de l'hôte de "strict" à "certains" (ma terminologie). Dans ma situation, ssh a reçu l'autorisation de m'empêcher de me connecter, car je voulais me connecter en entrant un mot de passe, ce qui a été désactivé par "une" vérification de l'hôte. Vous devez donc continuer et demander à ssh d’utiliser / dev / null en tant que "UserKnownHostsFile". Ceci active la vérification d’hôte sur «aucune» et les avertissements DIRE susmentionnés s’appliquent. Ne le faites pas de manière globale ou permanente. - cardiff space man
C'est vraiment une solution élégante. Merci d'avoir partagé! - Leon li


Un autre moyen de supprimer StrictHostKeyChecking lorsque vous n’avez besoin que de le faire pour un seul serveur:

ssh <server> -o StrictHostKeyChecking=no

9
2017-10-10 16:17



Vous permettra de vous connecter mais de ne pas résoudre le problème de façon permanente. - Andres Canella
Quand je le fais, cela me donne la possibilité d’ajouter la clé, ce qui résout ensuite le problème de façon permanente. - Greg Dougherty
Peut-être avons-nous un problème différent? Je me connecte à un serveur qui avait une adresse IP différente auparavant. - Andres Canella
Si vous avez un serveur dont les données ont changé, vous devez le supprimer de votre fichier hosts connu (après avoir établi que la modification est correcte) et ajouter ses nouvelles informations. Si vous avez un nouveau serveur, -o vous permettra de vous connecter au serveur et d’obtenir ses informations ajoutées. - Greg Dougherty


Tout d'abord, s'agit-il de votre machine? Avez-vous sciemment changé les clés de l'hôte? Sinon, je serais très préoccupé par le fait que quelque chose a altéré ces données.

Deuxièmement, augmentez le débogage SSH,

ssh -vvv user@host

et voyez ce que cela vous dit. Essayez également de regarder dans / var / log / secure et / var / log / messages sur le serveur auquel vous essayez de vous connecter pour obtenir des indices, sshd affiche de bons messages d'erreur.

Troisièmement, cette machine est-elle connectée à Internet? Devez-vous vraiment autoriser les connexions root?


5
2018-05-09 14:51



+1 pour le commentaire de connexion root - Fahad Sadah
Pour que cette erreur se produise, il suffit que la machine cible soit ré-imagée. Si vous vous connectez à une cible située de votre côté d'une zone démilitarisée, une attaque MitM est très improbable. - ktappe


Vous obtenez cela parce que quelque chose a changé (comme une nouvelle carte réseau, une nouvelle adresse IP, le changement de logiciel serveur, etc.). Focus sur la sécurité a un bel article sur Protection de la clé de l'hôte SSH.

Retirez simplement la clé (avec SFTP ou similaire) du serveur, en modifiant le $HOME/.ssh/known_hosts et acceptez le nouveau lors de la prochaine connexion.

Votre connexion peut être interrompue à cause du paramètre StrictHostKeyChecking. Voir ce fil pour un problème similaire.


3
2018-05-08 11:41



Noooo, s'il te plaît, ne fais pas ça. Cela annule totalement toute la sécurité fournie par cette fonctionnalité. Veuillez ne supprimer que la clé spécifique qui a changé, pas tous les connus (connus). - Adam Gibbins
Je n'ai pas recommandé de supprimer le fichier known_hosts, j'ai recommandé de le modifier et d'en retirer la clé.
Ooop, désolé, mal interprété. - Adam Gibbins
Ce message ne peut certainement pas être déclenché par une nouvelle adresse IP, encore moins par une nouvelle carte réseau. Voir la réponse correcte d'Adam Gibbins. - bortzmeyer
Avant de voter contre (je trouve les gens très heureux avec cela), faites vos recherches. Lisez cet article sur la sécurité. securityfocus.com/infocus/1806. J'en cite un peu: "Pourquoi une clé d'hôte peut-elle changer? La machine à laquelle vous souhaitez vous connecter a été déplacée vers un nom DNS ou une adresse IP différent, ou a été entièrement remplacée par une nouvelle." Si une réponse est horriblement incorrecte, veuillez laisser une chance pour une correction. Après tout, c'est un wiki.


En tant qu'hôte [au sens large du terme, il peut s'agir de tout, d'une réinstallation / démarrage multiple à un ordinateur totalement différent avec une adresse IP que vous avez déjà connectée], le client ssh semble avoir changé, cela vous donne la Erreur.

Il n'est pas nécessaire de désactiver la vérification stricte, pas plus que la suppression en bloc des clés enregistrées.

Il est tout à fait possible d'avoir deux clés différentes répertoriées dans known_hosts pour un nom d'hôte ou une adresse IP particulier; vous donnant 2 alternatives selon que vous pensez avoir besoin ou non de la 'vieille' clé actuellement stockée dans known_hosts

Supprimez la clé particulière à laquelle il fait référence, en l377 de known_hosts pour le PO, ou conservez les deux.

Le moyen le plus simple de conserver les deux, en évitant la suppression de clés dans known_hosts, est

  1. Modifiez le fichier known_hosts pour ajouter # au début de la 'vieille' entrée référencée temporairement dans le fichier known_hosts [@ l377].
  2. Connectez-vous [ssh à l'hôte], acceptez l'invite pour ajouter la nouvelle clé 'automatiquement'
  3. Ensuite, éditez à nouveau le serveur known_hosts pour supprimer le #.

plus de réponses à "Ajouter la clé d’hôte correcte dans known_hosts" / plusieurs clés d’hôte ssh par nom d’hôte?


2
2018-06-05 13:26