“Ajouter la clé d’hôte correcte dans known_hosts” / plusieurs clés d’hôte ssh par nom d’hôte?


147

En essayant de ssh dans un ordinateur que je contrôle, je reçois le message familier:

@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@
@    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
[...].
Please contact your system administrator.
Add correct host key in /home/sward/.ssh/known_hosts to get rid of this message.
Offending RSA key in /home/sward/.ssh/known_hosts:86
RSA host key for [...] has changed and you have requested strict checking.
Host key verification failed.

J'ai effectivement changé la clé. Et j'ai lu quelques douzaines de messages disant que la solution du problème consiste à supprimer l'ancienne clé du known_hostsfichier.

Mais ce que je voudrais, c’est que SSH accepte à la fois l’ancienne clé et la nouvelle clé. La langue dans le message d'erreur (" Add correct host key") suggère qu'il devrait exister un moyen d'ajouter la clé d'hôte correcte sans supprimer l'ancienne.

Je n'ai pas été capable de comprendre comment ajouter la nouvelle clé d'hôte sans supprimer l'ancienne.

Est-ce possible ou le message d'erreur est-il extrêmement trompeur?


9
C'est la clé de l'hôte qui génère l'erreur. Un hôte doit avoir une et une seule clé. Cela n'a rien à voir avec les clés client ou utilisateur. Avez-vous une adresse IP qui flotte entre des hôtes distincts ou quelque chose?
David Schwartz

4
Dans mon cas, je sais que je vais basculer beaucoup entre les deux touches dans un proche avenir tout en jouant avec certaines choses. Il semble que cela serait également utile dans le cas d'une adresse IP avec plusieurs hôtes que vous suggérez. En gros, je veux simplement savoir si cela est possible pour ma propre éducation en dehors de toute application pratique particulière.
Samuel Edwin Ward

Réponses:


148
  1. récupérez la clé rsa de votre serveur, où se server_iptrouve l'adresse IP de votre serveur, telle que 192.168.2.1:

    $ ssh-keyscan -t rsa server_ip
    

    Exemple de réponse:

    # server_ip SSH-2.0-OpenSSH_4.3
    server_ip ssh-rsa AAAAB3NzaC1yc2EAAAABIwAAAQEAwH5EXZG...
    
  2. et sur le client, copiez toute la ligne de réponse server_ip ssh-rsa AAAAB3NzaC1yc2EAAAABIwAAAQEAwH5EXZG...et ajoutez cette clé au bas de votre ~/.ssh/known_hostsfichier:

    server_ip ssh-rsa AAAAB3NzaC1yc2EAAAABIwAAAQEAqx9m529...(the offending key, and/or the very bottom of the `known_hosts` file)
    server_ip ssh-rsa AAAAB3NzaC1yc2EAAAABIwAAAQEAwH5EXZG... (line you're adding, copied and pasted from above)
    

12
Cela a fonctionné! Cependant, j'utilise "HashKnownHosts", donc l'entrée semblait un peu déplacée. Heureusement, ssh_config (5) m'a indiqué ssh-keygen (1) qui m'a expliqué que je pouvais utiliser "ssh-keygen -H" pour hacher les entrées non hachées. Je vous remercie!
Samuel Edwin Ward

2
Cela "fonctionne" mais vous ne vérifiez pas la clé, vous êtes donc vulnérable aux attaques à mitaines ...
JasperWallace

3
@JasperWallace, tant que première étape est réalisée sur une connexion sécurisée (par exemple en utilisant localhost) il devrait être assez sûr, je pense
ony

3
Est-il possible de rassembler tous les types de clé à partir du serveur? Parfois, vous ne savez pas s'ils sont RSA, DSA, ECDSA, RSA1, etc.
Sopalajo de Arrierez

3
@SopalajodeArrierez même manpage dit aussi que vous pouvez séparer par des virgules types, donc ne ssh-keyscan -t rsa1,dsa,rsa,ecdsa,ed25519 server_ip- mais la seule raison de trouver rsa1et dsaclés est d'identifier les serveurs qui doivent être mis à niveau / reconfiguré
kbolino

94

Supprimez cette entrée de known_hosts en utilisant:

ssh-keygen -R *ip_address_or_hostname*

Cela supprimera l'adresse IP ou le nom d'hôte problématique du fichier known_hosts et essaiera de vous reconnecter.

À partir des pages de manuel:

-R hostname
Supprime toutes les clés appartenant à hostname d'un fichier known_hosts. Cette option est utile pour supprimer les hôtes hachés (voir l’option -H ci-dessus).


11
"comment ajouter la nouvelle clé d’hôte sans supprimer l’ancienne."
Samuel Edwin Ward

4
C'est la meilleure solution !
Thomas Decaux

8
Comment cela a-t-il 19 votes? La réponse à la question posée n'est pas proche.
Molomby

2
Votre question revient au deuxième rang lorsque je recherche sur Google "la clé d’hôte de mise à jour git ssh automatiquement". Cette réponse est ce que je cherchais. Ouvrir une nouvelle question avec exactement ce que je veux pourrait permettre de la dupliquer.
Jason Goemaat

Nom d'hôte fonctionne aussi
mardi

18

Un moyen très simple est:

cp ~/.ssh/known_hosts ~/.ssh/known_hosts.bak

Puis éditez known_hosts pour effacer la clé d'origine, puis ssh vers l'hôte en utilisant:

ssh name@computer

La nouvelle clé sera ajoutée automatiquement. puis comparez les deux fichiers. Un programme tel que meld est un bon moyen de comparer les deux fichiers. Puis fusionnez les fichiers pour que unknown_hosts contienne les deux clés

La raison pour laquelle je garde deux clés est que le système de destination est multiboot. Même si j'ose dire qu'il existe un moyen de synchroniser les clés entre les installations, il semble plus simple d'autoriser plusieurs clés.

EDIT 2015/06

J'ajouterais, en y repensant maintenant, que je remarque un moyen encore plus simple [tant que l'entrée est identifiable, normalement à partir du nom d'hôte / adresse IP, indépendamment du message d'erreur faisant référence à son emplacement spécifique];

  1. Modifiez le fichier known_hosts pour ajouter temporairement # au début de l'entrée 'ancienne' dans le fichier known_hosts
  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 #.

Il y a même l'option HostKeyAlias ​​comme dans

ssh -o HostKeyAlias=mynewaliasforthemachine name@computer

ensuite, une fois que le client ssh a ajouté la nouvelle clé sous l'alias, vous pouvez soit éditer known_hosts pour substituer le nom d'hôte / l'adresse IP "réel" à l'alias, ou vous connecter à cette incarnation de cet hôte avec l'option d'alias evermore.



c'est le mélange :) Le nom d'installation d'apt-get / yum est simplement un mélange
Mark

J'ai fait une variante de votre suggestion qui a bien fonctionné - au lieu de cp, mv, puis ssh, puis cat ~ / .ssh / known_hosts.bak ~ / .ssh / known_hosts> tmp; mv tmp ~ / .ssh / known_hosts
Peter N Lewis Le

6

J'ai le même problème avec un Raspberry Pi que je démarre avec plusieurs systèmes différents (système de développement pour la compilation de binaires de bras, projet, xbmc, etc.) et j'ai rencontré le même problème. Ils utilisent DHCP sur un réseau local et mon routeur a toujours utilisé la même adresse IP, l'adresse MAC étant la même. Je l'ai résolu en utilisant différents noms de domaine dans mon fichier hosts:

10.10.10.110 pi-dev
10.10.10.110 pi-xbmc
10.10.10.110 pi-etc

Le fichier known_hosts enregistre les empreintes digitales par nom d'hôte. Ainsi, même s'il s'agit de la même adresse IP, chaque nom d'hôte unique obtient une entrée différente.

J'en avais marre d'ajouter les noms aux fichiers hosts à chaque fois que j'utilisais un nouveau système, alors je suis venu avec une méthode encore plus paresseuse en utilisant des zéros non significatifs sur des adresses ip telles que:

$ ssh pi@10.10.10.110
$ ssh pi@010.10.10.110
$ ssh pi@10.010.10.110

Chaque variante de l'adresse IP (non analysée) obtient sa propre entrée dans known_hosts.


1
Les gens d’OpenSSH sont devenus sages à mon avis, cette échappatoire ne fonctionne plus dans les versions les plus récentes.
Mike

Vous pouvez utiliser CheckHostIP noen ~/.ssh/configêtre en mesure d'utiliser encore l'échappatoire. Vous pouvez même définir vos alias là pour que vous n'avez pas à jouer avec /etc/hostset définir CheckHostIP nouniquement pour ce 3 hostname.
GnP

3

Si OpenSSH 6.8 ou version ultérieure est installé sur votre client et sur votre serveur, vous pouvez utiliser l’ UpdateHostKeys yesoption de votre ssh_configou ~/.ssh/config. Par exemple:

Host *
    UpdateHostKeys yes

Cela permet à SSH de stocker toutes les clés d’hôte auxquelles le serveur est soumis known_hosts, et lorsqu’un serveur modifie ou supprime une clé d’hôte, la clé est également modifiée ou supprimée dans votre known_hosts.


C'est de loin la réponse la plus utile! Bien que cela n'offre pas explicitement un moyen de résoudre la question initiale si une clé d'hôte a déjà été modifiée, toutes les autres réponses ne sont pas sécurisées puisqu'elles ne vérifient pas la nouvelle clé d'hôte. Cette option vous permet d'effectuer un basculement sécurisé vers de nouvelles clés d'hôte.
Jaap Eldering

1

Je ne vois pas pourquoi vous souhaitez utiliser deux clés, mais vous pouvez certainement ajouter plusieurs clés valides au ~/.ssh/known_hostsfichier, mais vous devrez le faire manuellement.

Une autre solution pourrait être d'utiliser l' StrictHostKeyChecking=nooption pour cet hôte spécifique:

ssh -o StrictHostKeyChecking=no user@host

que vous pourriez mettre dans un alias dans votre ~/.profileou quelque chose de similaire.

alias hc=ssh -o StrictHostKeyChecking=no user@host

StrictHostKeyChecking ne semble pas aider dans ce cas; apparemment, il ne spécifie le comportement que lorsque l'hôte ne se trouve pas dans le fichier known_hosts. Mentionné ici: gossamer-threads.com/lists/openssh/dev/45349#45349
Samuel Edwin Ward

Ça marche ici. Vous recevrez l'avertissement, mais la connexion continue.
Sven

C'est étrange. Utilisez-vous une authentification par mot de passe? Utilisez-vous OpenSSH?
Samuel Edwin Ward

1

Si vous ne faites que SSH sur un réseau local, alors ...

Une solution simple consiste à effacer l'ancien fichier de clé et à le remplacer par un fichier vierge. Cela vous permettra de réautoriser toutes vos connexions avec de nouvelles clés. Si vous avez des clés ssh stockées pour des sites extérieurs à votre réseau local, vous devez vous assurer que votre connexion initiale est sécurisée comme vous l'avez fait lors de votre première connexion à ce serveur.

par exemple

cp known_hosts known_hosts.old
rm known_hosts
nano known_hosts

Puis appuyez sur espace, ctrl + x et 'y' pour sauvegarder le nouveau tampon (fichier). C'est une mauvaise pratique, mais d'accord, à condition que vous ne soyez pas régulièrement en dehors de votre réseau local (par exemple, un serveur uni ou professionnel).

Sur un réseau local sécurisé, cela est sans danger car vous ne pouvez tout simplement pas attaquer un homme au milieu.

C'est toujours mieux d'utiliser un code que vous comprenez!


4
Effacer le known_hostsfichier entier à chaque fois annulera la majeure partie de la sécurité fournie par ssh.
Kasperd

En fait, je dirais que sur un réseau interne sécurisé, il est plus sûr de comprendre votre code et de contourner la sécurité que de le copier sans réfléchir. Sur un réseau externe, la situation serait alors différente.
Aaron

-1

Autant de réponses, mais autant de réponses qui renoncent à la protection en désactivant totalement la vérification stricte de l'hôte, en détruisant les informations d'hôte sans lien ou en obligeant simplement l'utilisateur à accepter de manière interactive les clés, éventuellement ultérieurement, lorsqu'elles sont inattendues.

Voici une technique simple pour vous permettre de laisser une vérification stricte de l'hôte, mais de mettre à jour la clé de manière contrôlée, lorsque vous vous attendez à ce qu'elle change:

  • Supprimer l'ancienne clé et mettre à jour en une seule commande

    ssh-keygen -R server.example.com && \
        ssh -o StrictHostKeyChecking=no server.example.com echo SSH host key updated.
    
  • Répétez l'opération avec une ou plusieurs adresses IP ou d'autres noms d'hôte si vous les utilisez.

L’avantage de cette approche est qu’il retape le serveur exactement une fois. La plupart des versions de ssh-keygen ne semblent pas renvoyer d'erreur si le serveur que vous essayez de supprimer n'existe pas dans le fichier hosts connu. Si cela vous pose problème, utilisez les deux commandes en séquence.

Cette approche vérifie également la connectivité et émet un message intéressant pour les journaux de la commande ssh (qui se connecte, met à jour la clé d'hôte et affiche la clé d'hôte SSH mise à jour, puis se ferme immédiatement.

Si votre version de ssh-keygen renvoie un code de sortie différent de zéro et que vous préférez le gérer sans erreur, peu importe la connexion ou la connexion précédente, utilisez simplement les deux commandes en séquence, en ignorant les erreurs éventuelles de la commande ssh-keygen.

Si vous utilisez cette technique, vous n'avez jamais besoin de modifier votre commande ssh ou de désactiver la vérification d'hôte, sauf pendant cette commande ssh. Vous pouvez être sûr que les futures sessions ssh fonctionneront sans conflit ni nécessiter d'accepter explicitement une nouvelle clé, tant que la commande ssh ci-dessus s'exécutera sans erreur.


-3

J'ai eu le même problème.

Tout ce que j'ai fait était d' sudo nano /home/user/.ssh/ host_alloweffacer la clé.

Lorsque je ssh retourne sur le serveur, il ajoute une nouvelle clé.


2
Quelques informations supplémentaires sur les raisons pour lesquelles cela se produit seraient utiles à la réponse.
Drew Khoury

-4

Utilisez la commande sed pour supprimer la ligne incriminée

OUTPUT: as show in above example
Offending key in /home/user/.ssh/known_hosts:86

Supprimez la ligne 86 comme mentionné dans les hôtes connus.

CODE: 
sed -i '86d' /home/user/.ssh/known_hosts

Lors de la prochaine utilisation de ssh, le système ajoutera automatiquement une nouvelle clé.

nouvelles versions de ssh

utilisation:

ssh-keygen -R <hostname|ip address>

Il va supprimer l'entrée du nom d'hôte et de prendre la sauvegarde de vieux .known_hostcommeknown_hosts.old


4
"Mais ce que j'aimerais, c'est que SSH accepte à la fois l'ancienne clé et la nouvelle clé." Votre réponse ne fait pas cela.
Samuel Edwin Ward
En utilisant notre site, vous reconnaissez avoir lu et compris notre politique liée aux cookies et notre politique de confidentialité.
Licensed under cc by-sa 3.0 with attribution required.