Comment modifier les hôtes connus lorsque plusieurs hôtes partagent le même nom IP et DNS?

Je ssh régulièrement dans 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 IP et DNS. Disons que l'IP est 192.168.0.9, et les noms sont hostnameethostname.domainname

D'après ce que j'ai compris, la solution pour pouvoir se connecter aux deux hôtes est de les ajouter tous les deux au ~/.ssh/know_hostsfichier. Cependant, il est plus facile à dire qu'à faire, car le fichier est haché, et a probablement plusieurs entrées par hôte ( 192.168.0.9, hostname, hostname.domainname). Par conséquent, 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 de modifier le known_hostsfichier, 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 permettra de vous connecter à toute transparence à cet ordinateur avec ssh, peu importe si je l' appelle 192.168.0.9, hostnameou hostname.domainname, ni si elle utilise son hostkey Linux ou OSX son hostkey. Cependant, je veux toujours recevoir un avertissement s'il y a une véritable attaque de l'homme du milieu, c'est -à- dire si une autre clé que ces deux-là est utilisée.

La solution la plus simple ici consiste simplement à utiliser les mêmes clés d'hôte pour Linux et OS X. Autrement dit, choisissez un ensemble de /etc/ssh/ssh_host_*_key*fichiers 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 dans lequel vous avez démarré, et le client SSH ne sera pas le 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 vous retrouvez avec deux clés pour la même host et ssh acceptera l'un ou l'autre.

(Vous pouvez également utiliser ssh-keygen -H -F <hostname>pour rechercher des lignes dans votre fichier known_hosts qui correspondent à ce nom d'hôte. L'exécution de cette opération après avoir recopié la ligne supprimée doit 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.

Source: /programming/733753/how-to-handle-ssh-host-key-verification-with-2-different-hosts-on-the-same-but

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 karl

Explication ci-dessous (de man ssh_config)

CheckHostIP

Si cet indicateur est défini sur "oui", 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 changé en raison d'une usurpation 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 vrai nom d'hôte 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 tunneliser les connexions SSH ou pour plusieurs serveurs exécutés sur un seul 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

La façon la plus simple de résoudre votre problème est de donner à chaque hôte une adresse IP propre / distincte. Avec 253 adresses disponibles dans votre réseau (privé) et IPv4, cela ne devrait pas être un problème. Donnez-leur des adresses IP fixes (car un serveur DHCP identifierait la machine en fonction de l'adresse MAC des cartes réseau, et les deux obtiendraient la même adresse). Je ne vois pas d'autre solution si vous voulez garder les mesures de sécurité (que je ne laisserais pas pour ce petit "confort" non plus).

Je ne rencontre pas ce problème lors de la connexion à diverses boîtes VPS partageant la même IP, car chacune a un port SSH différent (20022,30022, etc.), elles sont donc enregistrées en tant qu'hôtes connus avec des clés différentes.

Serait-ce une solution de contournement pour vous?

Un autre article , qui décrit plusieurs façons de gérer votre problème:

La deuxième méthode utilise deux paramètres openSSH:, StrictHostKeyCheckinet UserKnownHostsFile. Cette méthode trompe SSH en le configurant pour utiliser un fichier empty_hosts vide et NON pour vous demander de confirmer la clé d'identité de l'hôte distant.

Puisque vous voulez garder la vérification stricte de la clé hôte, je leur demanderais d'utiliser des known_hostsfichiers différents . Pour ce faire, configurez votre ~/.ssh/configfichier (ou le /etc/ssh/ssh_configfichier si vous en avez besoin pour travailler sur plusieurs comptes d'utilisateurs locaux) comme ceci:

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 $REALHOSTNAMEpar le nom d'hôte ou l'adresse IP réelle, bien sûr. (Peu importe ce que vous choisissez, tant que vous choisissez quelque chose après "Hostname" qui résoudrait en adresse IP, mais j'utiliserais le nom d'hôte de préférence à une adresse IP, juste sur des principes généraux.)

Ensuite, ssh myserver.linuxet ssh myserver.osxpeut donc avoir différentes clés d'hôte, mais vous obtenez toujours la vérification. Si c'est Linux qui fonctionne et que vous tapez OS X (ou vice versa), vous obtiendrez l'avertissement (qui, je crois, est l'effet souhaité).

Si j'avais ce problème, je m'assurerais qu'il y avait quelque chose de complètement faux dans le known_hostsfichier principal qui ne correspond à aucun des deux, de sorte que si vous tapez $REALHOSTNAMEau lieu de myserver.osxvous obtenez l'avertissement. :-) Je ferais ça en mettant quelque chose comme

<ip-address-of-github.com> $REALHOSTNAME

dans mon /etc/hosts, puis faire un ssh $REALHOSTNAMEet accepter la nouvelle clé, puis retirer cette entrée.