Problèmes de vérification des clés de l'hôte SSH à l'aide de VIP

Nous avons 2 serveurs de production sur un VIP, un seul est utilisé à la fois, par exemple:

myservice.mycompany.uk pointe normalement vers server1, dans le cas où server1 échoue, il est modifié pour pointer vers server2.

Il y a d'autres serveurs qui doivent envoyer des fichiers à myservice.mycompany.uk via SFTP et cela devrait être totalement transparent pour eux si nous basculons vers server2.

Le problème est que, tandis que les clés sont installées à la fois sur server1 et server2, les autres serveurs auront des problèmes de vérification de clé d'hôte, car la clé d'hôte de server2 est différente de la clé d'hôte de server1. Cela provoque une erreur de sécurité (car la vérification stricte est activée) et une ligne doit être supprimée des hôtes connus pour que cela fonctionne.

Notre informaticien a suggéré que nous puissions créer 2 entrées dans known_hosts, une avec la clé pour server1 et une avec server2, toutes deux avec l'hôte myservice.mycompany.uk.

Cela est-il susceptible de fonctionner? Comment cela peut-il être fait avec putty / psftp sur Windows? Étant donné que la clé d'hôte est stockée dans le registre et les noms en double ne sont pas autorisés. Existe-t-il un meilleur moyen, peut-on par exemple, forcer les serveurs à avoir la même clé d'hôte?

ssh cluster sftp

— Paul Creasey
source

Réponses:

Pour le rendre plus facile pour les clients, j'utiliserais simplement la même clé d'hôte sur les deux machines. Copiez simplement l'une des clés (celle du serveur actuellement utilisé) sur la deuxième machine. Ils ont les clés /etc/ssh/ssh_host_*.

Une autre option consiste à désactiver la vérification des clés d'hôte sur les clients. Cela peut être fait en réglant leur ssh_configutilisation:

Host myservice.mycompany.uk
    StrictHostKeyChecking

— ℝaphink
source

La désactivation de la vérification de la clé hôte sape plutôt l'intérêt d'utiliser SSH pour transférer ces fichiers, la duplication de la clé hôte est probablement la meilleure solution.

— James Yale

La désactivation de la vérification de la clé hôte ne signifie pas que la communication n'est pas correctement cryptée, ce qui est le principal point de SSH. Cela dit, comme je l'ai dit, je suis moi-même favorable à la première solution.

— ℝaphink

Dans la version client (avec différentes clés de serveur) de la solution, vous devez également ajouter UserKnownHostsFile=/dev/nullsinon la première clé ira dans les hôtes connus et la seconde entraînera un avertissement "homme au milieu".

— Nils

@Nils ce n'est pas nécessaire; Ce paramètre StrictHostKeyChecking yesrendra le fichier UserKnownHosts ignoré au profit du fichier d'hôtes connu du système. Donc, tout ce qui modifie les UserKnownHosts est plutôt inutile.

— Michael Lowman

Ok - je dois clarifier ceci: je parle du cas où vous avez deux clés de serveur différentes. Là, vous devez spécifier StrictHostKeyChecking noet définir en outre le UserKnownHostsFile/ dev / null. Dans ce cas, toutes les clés d'hôte seront acceptées (ce qui rendra ce niveau de sécurité inutile, bien sûr).

— Nils

J'ai archivé cela de cette manière, l'utilisateur root exécute un script à 23h00 qui se connecte à l'adresse IP logique du cluster Linux, donc en cas de basculement de l'adresse IP, mon changement d'empreinte digitale ssh

echo "StrictHostKeyChecking no" >> /root/.ssh/config 
echo "UserKnownHostsFile /dev/null" >> /root/.ssh/config

De cette façon, le paramètre est pour root uniquement

— c4f4t0r
source