J'ai réinstallé mon serveur et je reçois ces messages:
[user@hostname ~]$ ssh root@pong
@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@
@ 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 RSA key sent by the remote host is
6e:45:f9:a8:af:38:3d:a1:a5:c7:76:1d:02:f8:77:00.
Please contact your system administrator.
Add correct host key in /home/hostname /.ssh/known_hosts to get rid of this message.
Offending RSA key in /var/lib/sss/pubconf/known_hosts:4
RSA host key for pong has changed and you have requested strict checking.
Host key verification failed.
J'ai essayé différentes solutions que j'ai trouvées sur Internet. Mon known_hosts
fichier (normalement en ~/.ssh/known_hosts
) est en /var/lib/sss/pubconf/known_hosts
. J'ai essayé de le modifier, mais il reste dans un état. J'ai installé ipa-client et j'ai Fedora 19. Comment puis-je résoudre cet avertissement?
Jusqu'à présent, toutes les réponses ne fonctionnent que si vous n'avez pas installé Freeipa.
La bonne réponse pour freeipa dans les commentaires ci-dessous d'Adrin est ici .
ssh
verification
ipa
man-in-the-middle
Filip Dobrovolný
la source
la source
Réponses:
Voici la solution la plus simple
Par exemple,
Depuis la
ssh-keygen
page de manuel :-R hostname
Supprime toutes les clés appartenant au nom d'hôte d'un fichier known_hosts. Cette option est utile pour supprimer les hôtes hachés (voir l'option -H ci-dessus).la source
ssh-keygen -R [127.0.0.1]:3022
. Vérifiez simplement dans votre fichier .ssh / known_hosts ce qu'il dit explicitement.Utilisation
Exemple avec une adresse IP / nom d'hôte serait:
Cela mettra à jour l'infraction de votre hôte à partir des hôtes connus. Vous pouvez également fournir le chemin des hôtes connus avec l'indicateur -f.
la source
$ ssh-keygen -R {server.name.com}
|$ ssh-keygen -R {ssh.server.ip.address}
|$ ssh-keygen -R server.example.com
J'ai eu cette même erreur après avoir recréé une image Digital Ocean Ubuntu. J'ai utilisé la commande suivante avec l'adresse IP de mon serveur à la place de
[IP_ADDRESS]
la source
Lorsque vous réinstallez le serveur, son identité change et vous commencerez à recevoir ce message. Ssh n'a aucun moyen de savoir si vous avez changé le serveur auquel il se connecte, ou si un serveur intermédiaire a été ajouté à votre réseau pour flairer toutes vos communications - il le porte donc à votre attention.
Supprimez simplement la clé des hôtes connus en supprimant l'entrée appropriée:
C'est
4d
à cause deOffending RSA ...known_hosts:4
la source
sed -i -e 4d /var/lib/sss/pubconf/known_hosts
identification
dans le cas où vous souhaitez reconstruire le serveur sans provoquer de perturbations comme ce message d'erreur?Le marteau est de supprimer tous les hôtes connus d'un seul coup:
Je me heurte à cela car nous utilisons de petits sous-réseaux de serveurs de courte durée à partir d'un boîtier de connexion et avons fréquemment la réutilisation des adresses IP internes des serveurs qui partagent la même clé ssh.
la source
known_hosts
est censée empêcher). Ne faites cela que si vous êtes sûr que tous les hôtes sont en sécurité.Le problème est que vous avez déjà accepté une connexion SSH à un ordinateur distant et que l'empreinte numérique de l'ordinateur distant ou la clé de hachage SHA256 a changé depuis votre dernière connexion. Ainsi, lorsque vous essayez à nouveau de SSH ou utilisez github pour extraire du code, qui utilise également SSH, vous obtenez une erreur. Pourquoi? Parce que vous utilisez la même adresse d'ordinateur distant qu'avant mais que l'ordinateur distant répond avec une empreinte digitale différente. Par conséquent, il est possible que quelqu'un usurpe l'ordinateur auquel vous vous êtes déjà connecté. Il s'agit d'un problème de sécurité.
Si vous êtes sûr à 100% que l'ordinateur distant n'est pas compromis, piraté, usurpé, etc., tout ce que vous devez faire est de supprimer l'entrée dans votre fichier connu_hosts pour l'ordinateur distant. Cela résoudra le problème car il n'y aura plus d'incompatibilité avec les identifiants d'empreintes digitales SHA256 lors de la connexion.
Sur Mac, voici ce que j'ai fait:
1) Trouvez la ligne de sortie qui lit
RSA host key for servername:port has changed and you have requested strict checking.
Vous aurez besoin à la fois du nom de serveur et éventuellement du port de cette sortie de journal.2) Sauvegardez le fichier des hôtes connus SSH
cp /Users/yourmacusername/.ssh/known_hosts /Users/yourmacusername/.ssh/known_hosts.bak
3) Trouvez la ligne où l'ancienne empreinte digitale de l'ordinateur est stockée et supprimez-la. Vous pouvez rechercher l'empreinte digitale de l'ordinateur distant incriminé en utilisant le nom de serveur et le port de l'étape 1.
nano /Users/yourmacusername/.ssh/known_hosts
4) CTRL-X pour quitter et choisissez Y pour enregistrer les modifications
Tapez maintenant
ssh -p port servername
et vous recevrez l'invite d'origine que vous avez faite lorsque vous avez essayé SSH pour la première fois sur cet ordinateur. Vous aurez alors la possibilité d'enregistrer l'empreinte SHA256 mise à jour de cet ordinateur distant dans votre fichier known_hosts. Si vous utilisez SSH sur le port 22, l'argument -p n'est pas nécessaire.Tous les problèmes que vous pouvez restaurer le fichier d'origine connu_hosts:
cp /Users/yourmacusername/.ssh/known_hosts.bak /Users/yourmacusername/.ssh/known_hosts
la source
ssh-keygen -R [IP_ADDRESS]
cela ne fonctionnait pas pour moi. Merci!Comme beaucoup l’ont déjà dit, utiliser
ssh-keygen
, c’est-à-direEn outre, vous pouvez envisager de désactiver temporairement la vérification des clés d'hôte:
la source
Host ???? CheckHostIP no StrictHostKeyChecking no
(3 lignes, tabulées à partir du 2)Travaille pour moi!
Cela indique que vous avez une clé RSA incriminée à la ligne no. 4
Solution 1 :
Solution 2:
OU
Solution 3:
Cela supprimera la
4th
ligne de/root/.ssh/known_hosts
en place (-i
).la source
J'ai utilisé la solution de mockinterface, bien que le sed -i ne fonctionnait pas tout à fait, je l'ai résolu en supprimant la ligne à la main avec vim:
Vous pouvez utiliser n'importe quel autre éditeur de texte que vous souhaitez, mais vous devrez probablement montrer vos privilèges administratifs
la source
Pour les utilisateurs Mac, vous pouvez utiliser l'
-R
indicateur de lassh-keygen
commande. Exemple rapide:THE_IP_ADDRESS
étant l'adresse IP dans laquelle vous essayez de ssh. Et puis vous pouvez bien vous connecter.la source
En effet, les paramètres de votre ordinateur distant ont changé. Retirez vos clés actuelles pour cela.
vim /root/.ssh/known_hosts
Supprimez la ligne de l'IP que vous connectez.
la source
Modifiez
/home/hostname /.ssh/known_hosts
et supprimez les 4 lignes, puis enregistrez-le.Ensuite, exécutez à
ssh root@pong
nouveau, vous verrez un message comme ceciAre you sure you want to continue connecting (yes/no)? yes
:, imprimez simplementyes
.la source
Les autres réponses ici sont bonnes et fonctionnent, de toute façon, j'ai résolu le problème en supprimant
~/.ssh/known_hosts
. Cela résout certainement le problème, mais ce n'est probablement pas la meilleure approche.la source
Dans mon cas, cela s'est produit parce que j'avais précédemment une connexion ssh avec une machine avec la même IP (disons 192.152.51.10) et que le système envisageait la clé RSA (stockée dans /home/user_name/.ssh/known_hosts) de l'hôte précédent, ce qui a entraîné en décalage.
Pour résoudre ce problème, vous devez supprimer la clé RSA précédemment stockée pour l'ip 192.152.51.10 .
la source
Solution simple doublure, testée sur mac:
Supprime uniquement l'IP hôte ssh cible des hôtes connus.
où 212.156.48.110 est remplacé par l'adresse IP de l'hôte cible.
Cause : cela s'est produit car l'adresse IP cible était déjà connue pour une autre machine en raison de la redirection de port. La suppression de l'adresse IP cible avant la connexion résoudra le problème.
la source
Utilisez cette commande:
la source
Supprimez cette entrée des hôtes connus en utilisant:
Cela supprimera l'adresse IP ou le nom d'hôte problématique des hôtes connus fichier et réessayera de se connecter.
Depuis les pages de manuel:
la source
Faites juste:
cd /home/user/.ssh/
-> voiciuser
votre nom d'utilisateur, c'est à dire/home/jon/
par exemple.alors
gedit known_hosts &
et supprimez le contenu qu'il contient.Maintenant ,
ssh
encore une fois, cela devrait fonctionner.la source
Si vous essayez de vous connecter au conteneur Docker en cours d'exécution sur le port 2222 avec la commande et que vous obtenez l'erreur
Ensuite, pour résoudre ce problème, sur votre ordinateur local (c'est-à-dire la machine hôte et non le conteneur), accédez à
cd ~/.ssh/
et ouvrez leknown_hosts
fichier avec l'éditeur de texte. Supprimez la ligne commençant par[localhost]:2222
et enregistrez le fichier. Maintenant, essayez à nouveau de sshL'erreur disparaîtra mais vous devrez le faire à chaque redémarrage du conteneur.
la source
Ma solution est:
vi ~/.ssh/known_hosts
C'est mieux que de supprimer tous les
known_hosts
la source
Seul problème côté client (clé en double pour ip):
Résoudre des variantes:
Pour effacer une adresse IP (port par défaut 22):
Pour une adresse IP ( port non par défaut ):
Effacement rapide de toutes les ips:
7.7.7.7 - SSH votre serveur IP Connect
333 - port non standard
la source
Parfois, si pour une raison quelconque, vous devez réinstaller un serveur, lors de la connexion par ssh, nous constaterons que votre serveur indique que l'identification a changé. Si nous savons que ce n'est pas une attaque , mais que nous avons rétabli le système, nous pouvons supprimer l'ancienne identification des hôtes connus en utilisant ssh-keygen:
Lors de la nouvelle connexion, nous vous demanderons de valider la nouvelle empreinte digitale:
la source
J'ai eu ce problème, et la raison est très simple, j'ai une adresse IP en double pour la connexion ssh, donc après avoir modifié ce problème, tout est résolu.
la source
J'ai eu la même erreur dans ma machine, et j'ai effacé le
known_hosts
fichier, et après cela, cela fonctionne bien.la source
authorized_keys
lorsque vous avez un problème avec leknown_hosts
fichierSOLUTION:
1- supprimer de "$ HOME / .ssh / known_hosts" la ligne faisant référence à l'hôte vers lequel il est impossible de se connecter.
2- Exécutez cette commande: ssh-keygen -R "IP_ADDRESSorHOSTNAME" (remplacez "IP_ADDRESSorHOSTNAME" par votre IP de destination ou votre nom d'hôte de destination)
3- Réessayer la connexion ssh (en cas d'échec, veuillez vérifier l'autorisation sur le répertoire .ssh, il doit s'agir de 700)
la source
Ma solution sur UBUNTU (linux):
1.Vous devez supprimer le contenu du fichier "known_hosts" qui se trouve dans "/home/YOUR_USERNAME/.ssh/known_hosts"
2.Générez une nouvelle clé ssh comme "ssh-keygen -t rsa -C" [email protected] "-b 4096"
3.Copiez-collez votre nouvelle clé ssh dans votre référentiel git (gitlab dans mon cas) clés SSH.
Ça marche pour moi !
la source
AWS EC2.
Trouvez l'ip dans le message qu'il vous donne.
courir
Utilisez les touches fléchées pour trouver l'ip dans le message et cliquez sur.
Cela supprimera cette ligne puis exécutera échapper
Cela vous fera économiser alors vous êtes prêt à partir.
la source