web-dev-qa-db-fra.com

"Ajouter la clé d'hôte correcte dans les hôtes connus" / 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 en effet changé la clé. Et j'ai lu quelques dizaines de publications disant que la façon de résoudre ce problème était de supprimer l'ancienne clé de known_hosts fichier.

Mais ce que je voudrais, c'est que ssh accepte à la fois l'ancienne clé et la nouvelle clé. La langue du message d'erreur ("Add correct Host key ") suggère qu'il devrait y avoir 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?

sshssh-keys
159
Samuel Edwin Ward

  1. récupérez la clé rsa de votre serveur, où server_ip est 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 l'intégralité de la ligne de réponse server_ip ssh-rsa AAAAB3NzaC1yc2EAAAABIwAAAQEAwH5EXZG..., et ajoutez cette clé au bas de votre ~/.ssh/known_hosts fichier:

    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)
153
quanta

Supprimez cette entrée des hôtes connus en utilisant:

ssh-keygen -R *ip_address_or_hostname*

Cela supprimera l'IP ou le nom d'hôte problématique du fichier known_hosts et réessayera de se connecter.

Depuis les pages 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).

101
Luis Abarca

Un moyen très simple est:

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

Modifiez ensuite known_hosts pour effacer la clé d'origine, puis passez à l'hôte en utilisant:

ssh name@computer

Il ajoutera automatiquement la nouvelle clé; puis comparez les deux fichiers. Un programme tel que meld est une belle façon de comparer les deux fichiers. Fusionnez ensuite les fichiers pour que les hôtes connus contiennent les deux clés

Ma `` raison '' de conserver 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.

MODIFIER 2015/06

Je devrais ajouter, en le revoyant maintenant, que je remarque une manière encore plus simple [tant que l'entrée est identifiable, normalement à partir du nom d'hôte/de l'adresse IP, indépendamment du message d'erreur faisant référence à son emplacement spécifique];

  1. Modifiez unknown_hosts pour ajouter # au début de la "vieille" entrée dans known_hosts temporairement
  2. Connectez [ssh à l'hôte], acceptez l'invite pour ajouter la nouvelle clé "automatiquement"
  3. Ré-éditez ensuite known_hosts pour supprimer le #

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

ssh -o HostKeyAlias=mynewaliasforthemachine name@computer

puis par la suite, après que le client ssh ait ajouté la nouvelle clé sous l'alias, vous pouvez soit modifier les hôtes connus pour substituer le "vrai" nom d'hôte/adresse IP à l'alias, soit vous connecter à cette incarnation de cet hôte avec l'option d'alias pour toujours

19
Mark

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 compiler les 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 réutilisé la même IP car l'adresse MAC était la même. Je l'ai résolu en utilisant différents noms de domaine dans mon fichier d'hôtes:

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. 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 ai eu marre d'ajouter les noms aux fichiers hôtes à chaque fois que j'utilisais un nouveau système, j'ai donc trouvé un moyen encore plus paresseux en utilisant des zéros de tête sur les adresses IP comme:

$ ssh [email protected]
$ ssh [email protected]
$ ssh [email protected]

Chaque variation de l'adresse IP (non canalisée) obtient sa propre entrée dans unknown_hosts.

6
Mike

Si votre client et votre serveur ont 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_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.

3
Mikaela

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

Une solution simple consiste à effacer l'ancien fichier de clés 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 en dehors de votre réseau local, vous devez vous assurer que votre connexion initiale est sûre comme vous l'avez fait la première fois que vous vous êtes connecté à ce serveur.

par exemple

cp known_hosts known_hosts.old
rm known_hosts
nano known_hosts

Appuyez ensuite sur espace, retour arrière cntl + x et "y" pour enregistrer le nouveau tampon (fichier). C'est une mauvaise pratique, mais d'accord, à condition que vous ne vous échappiez pas régulièrement en dehors de votre réseau local (par exemple, un serveur uni ou de travail)

Sur un réseau local sécurisé, cela est sûr car vous ne pouvez tout simplement pas avoir un homme au milieu de l'attaque.

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

1
Aaron

Je ne vois pas pourquoi vous voulez travailler avec deux clés, mais vous pouvez certainement ajouter plus d'une clé valide au ~/.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
Sven