Question Comment éditer known_hosts lorsque plusieurs hôtes partagent la même adresse IP et le même nom 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 vues comme deux hôtes partageant les mêmes adresses IP et DNS. Disons que l'IP est 192.168.0.9, et les noms sont hostname et hostname.domainname

Pour autant que je sache, la solution pour pouvoir se connecter aux deux hôtes est de les ajouter tous les deux à la ~/.ssh/know_hosts fichier. Cependant, il est plus facile à dire qu'à faire, car le fichier est haché et possède 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 facile de modifier le known_hosts fichier, tout en gardant les hashes. Par exemple, comment trouver les lignes correspondant à un hostame donné? Comment puis-je générer les hachages pour certains hôtes connus?

La solution idéale me permettrait de me connecter facilement à cet ordinateur avec ssh, que je l'appelle ou non 192.168.0.9, hostname ou hostname.domainname, ni si elle utilise sa hostkey Linux ou son hostkey OSX. Cependant, je veux quand même recevoir un avertissement s'il y a une véritable attaque de type "man-in-the-middle", c'est à dire. si une autre clé que ces deux est utilisée.


23
2017-07-05 12:32


origine


Qu'est-ce que tu veux faire? Modifiez-le pour quoi? - Rhyuk
@Rhyuk: Modifiez-le pour pouvoir reconnaître la clé hôte OSX et la clé hôte Linux pour l'adresse IP, le nom d'hôte et le nom d'hôte.domaine. - Frédéric Grosshans
@Rhyuk: J'ai édité cette question. Est-ce plus clair maintenant? - Frédéric Grosshans
Avez-vous simplement pensé à faire en sorte que les deux installations aient la même clé? - Zoredache
Il y a quelques cas où il est raisonnable d'utiliser une adresse IP pour accéder à plusieurs entités (chacune avec des clés hôtes SSH individuelles) tout en conservant un contrôle strict sur le fait que SEULES ces clés hôtes sont celles vues par le client SSH. Par exemple, certaines configurations à haute disponibilité où un cluster d'unités est accessible via une adresse IP partagée, mais où (pour une raison quelconque) la clé d'hôte SSH vue par les clients change en fonction de l'unité de cluster actuellement active. Un autre cas est que lorsque plusieurs hôtes SSH se trouvent derrière un pare-feu NAT et sont accessibles de l'extérieur, ils semblent tous avoir la même adresse IP. - IllvilJa


Réponses:


La solution la plus simple consiste à utiliser les mêmes clés d’hôte pour Linux et OS X. C’est-à-dire choisir un jeu de /etc/ssh/ssh_host_*_key* fichiers et les copier sur l'autre système d'exploitation. La même clé hôte sera alors présentée à un client SSH, quel que soit le système d'exploitation sur lequel vous avez démarré, et le client SSH ne sera pas le plus avisé.


11
2017-07-05 16:40



Je préférerais une version client, mais je vais essayer celle-ci si je n'en trouve pas. Par ailleurs, la localisation OSX (non standard) des fichiers est /private/etc/ssh_host*, ne pas /etc/ssh/ssh_host*. - Frédéric Grosshans
La copie des fichiers d’une machine à une autre (deux machines Linux) ne fonctionnait pas pour moi. Bien que le contenu du fichier soit identique, le hachage ne l'était pas. J'avais encore le problème (peut-être l'heure de la modification?). La solution ci-dessous est bien meilleure. - Stav
sshd charge les clés de l'hôte une fois au démarrage, vous devez donc probablement redémarrer sshd. Je vais ajouter cela à la réponse. Quant aux autres solutions étant meilleures, cela dépend de votre situation. Je dirais que les principaux avantages de cette méthode sont qu’elle ne nécessite qu’une installation unique et qu’elle est plus susceptible de fonctionner avec plusieurs implémentations de clients SSH. - jjlin
Curieusement, il semble que mon OpenSSH 7.4p1 relativement récent sshd charge les clés d'hôte sur chaque nouvelle connexion. Peut-être a-t-il été ainsi depuis longtemps et j'ai juste supposé que les clés des hôtes étaient traitées comme les autres sshd configuration. Donc, de toute façon, cela peut être ou ne pas être votre problème. - jjlin
Serait-ce une mauvaise idée de faire cela à deux hôtes dans un cluster qui partagent la même adresse VRRP? En cas de basculement, l'hôte qui répond sera différent. Je voudrais ne pas recevoir l'avertissement. - Colin 't Hart


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é et en recopiant la ligne supprimée, vous obtenez deux clés identiques. host, et ssh acceptera non plus.

(Vous pouvez aussi utiliser ssh-keygen -H -F <hostname> pour trouver des lignes dans votre fichier known_hosts correspondant à 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.


24
2018-01-06 23:55



En fait, si vous avez un client linux, vous n'avez même pas besoin de supprimer la ligne incriminée, il vous suffit de la commenter avec un caractère de hachage ('#') au premier plan. Ensuite, une fois que vous avez accepté la nouvelle clé, vous pouvez simplement éditer le fichier known_hosts et décommenter la ligne avec l'ancienne clé. Mais oui, cela serait également utile dans Putty. - IllvilJa
S'il existe deux hôtes portant le même nom, mais une adresse IP et une clé d'hôte différentes, cette solution de contournement fonctionne également: Commentez (ou supprimez temporairement) les deux lignes pour cet hôte (celle basée sur l'adresse IP et celle basée sur l'hôte) nom), connectez-vous à l'hôte non encore connu, puis rajoutez les lignes qui ont été mises en commentaire ou supprimées. - Kai Petzke


J'ai trouvé cela qui peut vous aider avec ce que vous voulez réaliser.

La source: https://stackoverflow.com/questions/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 l'homme ssh_config)

CheckHostIP

Si cet indicateur est défini sur "yes", ssh (1) vérifie également l'hôte   Adresse IP dans le fichier known_hosts. Cela permet à ssh de détecter si un   la clé de l'hôte a été modifiée en raison de l'usurpation de DNS. Si l'option est définie sur "non",   le chèque ne sera pas exécuté. 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 la clé hôte.   Cette option est utile pour le tunneling des connexions SSH ou pour plusieurs   serveurs s'exécutant sur un seul hôte.

La ligne Username and Port vous évite d'avoir à donner ces options   la ligne de commande aussi, vous pouvez donc utiliser:

% ssh server1
% ssh server2

8
2017-07-05 15:30



J'ai vu cet article, mais il ne correspond pas à mon cas: les deux serveurs se distinguent par numéro de port dans l'article, pas dans mon cas. En outre, je voudrais garder les couches de sécurité supplémentaires apportées par les hachages salés dans known_hosts et CheckHostIP. - Frédéric Grosshans
@ FrédéricGrosshans, je coche vérifié. Vous n'avez pas besoin d'avoir des ports séparés et l'option HashKnownHosts fonctionne bien avec HostKeyAlias. - Zoredache
L'inconvénient de ceci, à moins que je ne me trompe, c'est configuré pour chaque client, la réponse acceptée n'étant configurée que sur les serveurs ssh acceptants. - FreeSoftwareServers


Le moyen le plus simple de résoudre votre problème consiste à 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 une grosse affaire. 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 aucune autre solution si vous voulez garder les mesures de sécurité (que je ne laisserais pas tomber pour ce petit "réconfort" non plus).


2
2017-07-05 16:24



En fait, l'adresse IP n'est pas 192.168.0.xx et n'est pas privé. C'est une «vraie» adresse IPv4, donnée par mon université que je ne suis pas libre de changer. - Frédéric Grosshans
Si vous vérifiez avec Wikipédia, vous verrez 192.168.0.0 - 192.168.255.255 (votre question spécifiée 192.168.0.9, qui tombe dans cette gamme) appartient aux "espaces d’adresse IPv4 privés". Donc, par "privé" je ne vous ai pas parlé de "posséder", mais aux spécifications du IETF. Dans votre question, vous n'avez pas indiqué que vous ne pouviez pas modifier l'adresse IP, désolé - mais avec les informations fournies, ma réponse était appropriée. - Izzy
Désolé pour la question mal formulée. Je n'ai pas descendu - Frédéric Grosshans
Pas de problème, et tnx pour me le faire savoir - rend la descente moins décourageante. Mais une autre idée: je ne suis pas sûr de savoir où le fichier known_hosts prend le nom d'hôte de, renverser DNS ou offert par le client. Vous pouvez essayer de renommer l'un de vos "hôtes" afin qu'il présente un nom d'hôte différent. Ou pour avoir les deux clés d'hôte ajoutées: ssh vous indique la "ligne incriminée" dans votre fichier known_hosts (lorsque # 1 est contenu et que vous vous connectez avec # 2). Vous pouvez alors copier cette ligne dans un autre fichier, la supprimer de known_hosts, laisser la connexion n ° 2 se connecter et ajouter sa ligne, puis ajouter la ligne supprimée. Je ne sais pas si cela fonctionne, mais vous pouvez essayer. - Izzy


Je ne rencontre pas ce problème lorsque je me connecte à différentes boîtes VPS partageant la même adresse IP, car chacune a un port SSH différent (20022, 30022, etc.), elles sont donc enregistrées comme hôtes connus avec des clés différentes.

Est-ce que ce pourrait être une solution de contournement pour vous?


2
2018-04-09 16:16



Salut @Pyheme, bienvenue à Super User! Notez que cette question a presque 4 ans. Il n'y a rien de mal à y répondre, mais gardez à l'esprit qu'il est possible que vous n'obteniez pas de réponse. - Hewbot
Je n'ai plus de machine OS X, mais votre réponse pourrait être utile pour quelqu'un d'autre. C'est tout l'intérêt de l'échange de piles - Frédéric Grosshans
@Hewbot ... en effet, je le vois maintenant. Je ne sais pas pourquoi, il est apparu dans la liste des questions récentes ... - Pyheme


Un autre article, qui décrit plusieurs manières de gérer votre problème:

La seconde méthode utilise deux paramètres openSSH: StrictHostKeyCheckin, et UserKnownHostsFile. Cette méthode astuce SSH en la configurant pour utiliser un fichier known_hosts vide et ne PAS vous demander de confirmer la clé d'identité de l'hôte distant.


1
2017-07-05 15:36



Cet article traite de la non-vérification des clés. Je veux garder la clé de vérification et je ne veux pas la refuser à chaque fois hostname est redémarré dans Linut ou OSX - Frédéric Grosshans
Bienvenue sur Super User! Bien que cela puisse théoriquement répondre à la question, ce serait préférable inclure les parties essentielles de la réponse ici, et fournir le lien pour référence. J'ai inclus une petite partie, mais ce n'est peut-être pas ce que vous vouliez ... - Tom Wijsman


Étant donné que vous souhaitez conserver la vérification stricte de la clé de l'hôte, je lui demanderais d'utiliser known_hosts des dossiers. Pour ce faire, configurez votre ~/.ssh/config fichier (ou le /etc/ssh/ssh_config fichier 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

, remplacement $REALHOSTNAME avec le nom d'hôte ou l'adresse IP, bien sûr. (Cela n'a pas d'importance que vous choisissiez, aussi longtemps que vous choisissez quelque chose après "Hostname" qui se résoudrait à l'adresse IP, mais j'utiliserais le nom d'hôte de préférence à une adresse IP, juste sur des principes généraux.)

alors ssh myserver.linux et ssh myserver.osx peut donc avoir des clés d'hôte différentes, mais vous obtenez toujours la vérification. Si c'est Linux qui est en marche et que vous tapez OS X (ou vice versa), vous recevrez l'avertissement (qui, je pense, est l'effet désiré).

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

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

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


1
2018-04-09 15:34