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?

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)
   

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).

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.

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.

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.

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

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!

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.

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é.

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