Comment éditer known_hosts lorsque plusieurs hôtes partagent les mêmes noms IP et DNS?
Je ssh régulièrement sur un ordinateur qui est un ordinateur OS X/Linux à double démarrage. Les deux instances de système d'exploitation ne partagent pas la même clé d'hôte, elles peuvent donc être considérées comme deux hôtes partageant les mêmes adresses IP et DNS. Supposons que l'IP est 192.168.0.9 et que les noms sont hostname et hostname.domainname
Autant que je sache, la solution pour pouvoir se connecter aux deux hôtes consiste à les ajouter tous les deux au fichier ~/.ssh/know_hosts. Cependant, c'est plus facile à dire qu'à faire, car le fichier est haché et contient probablement plusieurs entrées par hôte (192.168.0.9, hostname, hostname.domainname). En conséquence, j'ai l'avertissement suivant
Warning: the ECDSA Host key for 'hostname' differs from the key for the IP address '192.168.0.9'
Existe-t-il un moyen simple d’éditer le fichier known_hosts tout en conservant les hachages. Par exemple, comment trouver les lignes correspondant à un nom d’hôte donné? Comment puis-je générer les hachages pour certains hôtes connus?
La solution idéale me permettrait de me connecter de manière transparente à cet ordinateur avec ssh, peu importe que je l’appelle 192.168.0.9, hostname ou hostname.domainname, qu’elle utilise sa clé d’hôte Linux ou sa clé d’hôte OSX. Cependant, je souhaite quand même recevoir un avertissement s’il ya une véritable attaque de type homme du milieu , c’est-à-dire si une autre clé est utilisée.
La solution la plus simple consiste simplement à utiliser les mêmes clés d’hôte pour Linux et OS X. En d’autres termes, choisissez un ensemble de fichiers /etc/ssh/ssh_Host_*_key* et copiez-les sur l’autre système d’exploitation. Ensuite, la même clé d'hôte sera présentée à un client SSH, quel que soit le système d'exploitation sous lequel vous avez démarré, et le client SSH n'en sera pas plus sage.
Comme @Izzy l'a suggéré dans un commentaire ci-dessus, ssh vous indique la ligne incriminée et en supprimant cette ligne (en l'enregistrant ailleurs), en acceptant la nouvelle clé, puis en recopiant la ligne supprimée, vous obtenez deux clés identiques Host, et SSH acceptera soit.
(Vous pouvez également utiliser ssh-keygen -H -F <hostname> pour rechercher dans votre fichier known_hosts des lignes qui correspondent à ce nom d'hôte. L'exécution de cette opération après la copie de la ligne supprimée devrait répertorier deux entrées.)
Si quelqu'un sait comment faire en sorte que PuTTY fasse la même chose, je serais très intéressé d'en entendre parler.
J'ai trouvé cela qui peut vous aider avec ce que vous voulez réaliser.
Créez un fichier de configuration dans votre répertoire .ssh comme suit:
Host server1 Hostname x1.example.com HostKeyAlias server1 CheckHostIP no Port 22001 User karl Host server2 Hostname x2.example.com HostKeyAlias server2 CheckHostIP no Port 22002 User karlExplication ci-dessous (de man ssh_config)
CheckHostIP
Si cet indicateur est défini sur "yes", ssh (1) vérifiera en outre l'adresse IP de l'hôte dans le fichier known_hosts. Cela permet à ssh de détecter si une clé d’hôte a été modifiée en raison d’une usurpation de contenu DNS. Si l'option est définie sur "non", la vérification ne sera pas exécutée. La valeur par défaut est "oui".
HostKeyAlias
Spécifie un alias à utiliser à la place du nom d'hôte réel lors de la recherche ou de l'enregistrement de la clé d'hôte dans les fichiers de base de données de clés d'hôte. Cette option est utile pour la mise en tunnel de connexions SSH ou pour plusieurs serveurs s'exécutant sur un même hôte.
La ligne Nom d'utilisateur et Port vous évite d'avoir à donner ces options sur la ligne de commande, vous pouvez donc simplement utiliser:
% ssh server1 % ssh server2
Je ne rencontre pas ce problème lorsque je me connecte à plusieurs boîtiers VPS partageant la même adresse IP, car chacun possède un port SSH différent (20022,30022, etc.). Ils sont donc enregistrés comme hôtes connus avec des clés différentes.
Cela pourrait-il être une solution de contournement pour vous?
Le moyen le plus simple de résoudre votre problème consiste à attribuer à chaque hôte une adresse IP propre/distincte. Avec 253 adresses disponibles dans votre réseau (privé) et IPv4, cela ne devrait pas poser de problème. Donnez-leur des adresses IP fixes (car un serveur DHCP identifierait la machine en fonction de l'adresse MAC de la carte réseau et les deux obtiendraient la même adresse). Je ne vois pas d'autre solution si vous souhaitez conserver les mesures de sécurité (que je ne lâcherais pas pour ce "confort" non plus).
Puisque vous voulez conserver la vérification stricte de la clé de l'hôte, je leur demanderais d'utiliser des fichiers known_hosts différents. Pour ce faire, configurez votre fichier ~/.ssh/config (ou le fichier /etc/ssh/ssh_config si vous avez besoin que cela fonctionne sur plusieurs comptes d'utilisateurs locaux) comme suit:
Host myserver.osx
UserKnownHostsFile ~/.ssh/known_hosts.dual.osx
# default is ~/.ssh/known_hosts
Hostname $REALHOSTNAME
Host myserver.linux
UserKnownHostsFile ~/.ssh/known_hosts.dual.linux
Hostname $REALHOSTNAME
, en remplaçant $REALHOSTNAME par le nom d’hôte ou l’adresse IP réelle, bien sûr. (Peu importe ce que vous choisissez, aussi longtemps que vous choisissez quelque chose après "nom d'hôte" qui résoudrait en adresse IP, mais j'utiliserais le nom d'hôte plutôt qu'une adresse IP, uniquement sur des principes généraux.)
Alors ssh myserver.linux et ssh myserver.osx peuvent donc avoir différentes clés d’hôte, mais vous obtenez toujours la vérification. Si c'est Linux qui est en place et que vous tapez OS X (ou vice versa), vous recevrez l'avertissement (qui, je crois, est l'effet recherché).
Si j'avais ce problème, je m'assurerais qu'il y a quelque chose de complètement faux dans le fichier known_hosts principal qui ne correspond à aucun des deux. Ainsi, si vous tapez $REALHOSTNAME au lieu de myserver.osx, vous recevez l'avertissement. :-) Je le ferais en mettant quelque chose comme
<ip-address-of-github.com> $REALHOSTNAME
dans mon /etc/hosts, puis en faisant un ssh $REALHOSTNAME et en acceptant la nouvelle clé, puis en retirant cette entrée.
Un autre article qui décrit plusieurs manières de traiter votre problème:
La deuxième méthode utilise deux paramètres openSSH:
StrictHostKeyCheckinetUserKnownHostsFile. Cette méthode aide SSH en la configurant pour utiliser un fichier known_hosts vide et non pour vous demander de confirmer la clé d'identité de l'hôte distant.