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


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é de la known_hosts fichier.

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 bonne clé d'hôte sans supprimer l'ancienne.

Je n'ai pas pu 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?


121
2017-10-13 14:01


origine


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
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 la situation 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:


  1. récupérez la clé rsa de votre serveur:

    $ ssh-keyscan -t rsa server_ip
    # server_ip SSH-2.0-OpenSSH_4.3
    server_ip ssh-rsa AAAAB3NzaC1yc2EAAAABIwAAAQEAwH5EXZG...
    
  2. et sur le client, ajoutez cette clé à ~/.ssh/known_hosts:

    server_ip ssh-rsa AAAAB3NzaC1yc2EAAAABIwAAAQEAqx9m529...(the offending key)
    server_ip ssh-rsa AAAAB3NzaC1yc2EAAAABIwAAAQEAwH5EXZG...
    

126
2017-10-13 14:38



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
Cela "fonctionne" mais vous ne vérifiez pas la clé, vous êtes donc vulnérable aux attaques par mitM ... - JasperWallace
@JasperWallace, tant que la première étape est effectuée sur une connexion sécurisée (par exemple, en utilisant localhost), elle devrait être assez sécurisée, je pense - ony
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
@SopalajodeArrierez, la même page de manuel indique également que vous pouvez séparer les types par des virgules. ssh-keyscan -t rsa1,dsa,rsa,ecdsa,ed25519 server_ip - mais la seule raison de trouver rsa1 et dsa clés consiste à identifier les serveurs devant être mis à niveau / reconfigurés - kbolino


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 de connus_hôtes fichier et essayez de vous connecter à nouveau.

À 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   au dessus de).


74
2018-02-09 06:49



"comment ajouter la nouvelle clé d’hôte sans supprimer l’ancienne." - Samuel Edwin Ward
C'est la meilleure solution ! - Thomas Decaux
Comment cela a-t-il 19 votes? Ce n'est pas près de répondre à la question posée. - Molomby
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
Le nom d'hôte fonctionne aussi - damluar


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. Fusionner ensuite 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 sur toutes les installations, il semble plus simple d'autoriser plusieurs clés.

MODIFIER 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. Editez les unknown_hosts pour ajouter # au début de la 'vieille' entrée dans connus_hôtes temporairement
  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, après que le client ssh ait 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.


16
2018-04-30 22:29



Ce "mélange"? meldmerge.org - Samuel Edwin Ward
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


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.


7
2017-11-04 02:28



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 no dans ~/.ssh/config pour pouvoir toujours utiliser la faille. Vous pouvez même définir vos alias pour ne pas avoir à jouer avec /etc/hosts et définir CheckHostIP no seulement pour ces 3 noms d'hôtes. - GnP


Si votre client et votre serveur utilisent OpenSSH 6.8 ou une version plus récente, vous pouvez utiliser le UpdateHostKeys yes option dans votre ssh_config ou ~/.ssh/config. Par exemple:

Host *
    UpdateHostKeys yes

Cela fait que SSH stocke toutes les clés d’hôte que le serveur doit known_hostset lorsqu'un serveur modifie ou supprime une clé d'hôte, celle-ci est également modifiée ou supprimée dans votre ordinateur. known_hosts.


2
2017-09-22 04:28



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


Je ne vois pas pourquoi vous voulez travailler avec deux clés, mais vous pouvez certainement ajouter plus d’une clé valide à la ~/.ssh/known_hosts fichier, mais vous devrez le faire manuellement.

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

ssh -o StrictHostKeyChecking=no user@host

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

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

1
2017-10-13 14:49



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
Cela fonctionne ici. Vous recevrez l'avertissement, mais la connexion se poursuivra. - Sven♦
C'est étrange. Utilisez-vous une authentification par mot de passe? Utilisez-vous OpenSSH? - Samuel Edwin Ward


Si vous seulement ssh sur un réseau local puis ...

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

Appuyez ensuite 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 sûr car vous ne pouvez tout simplement pas attaquer un homme au milieu.

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


0
2018-06-15 21:44



Essuyant le tout known_hosts fichier à 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


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 rapport ou en forçant 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 attendre ça 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ôtes 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 génère Clé d'hôte SSH mise à jour puis quitte immédiatement.

Si votre version de ssh-keygen renvoie un code de sortie non nul, et que vous préférez le gérer sans erreur, quelle que soit 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 ni 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.


-1
2017-09-18 01:56