Résolu Même fingerprint ssh sur 2 machines

[Akira78]

Bonjour à tous,

J'ai une machine cliente qui via sa crontab m'envoie en SSH un fichier tous les jours. En face j'ai 2 machines : la principale et la backup.

Mon problème : si je bascule sur ma machine backup (via un swap d'IP) mon client n'arrive plus à envoyer son fichier car il détecte que le fingerprint associé à l'IP a changé.

Solution manuelle : aller dans le known_hosts, effacer l'entrée correspondante, puis rétablir manuellement une première connexion. Nouveau problème, lors du retour à la normale je dois refaire cette action sur la machine cliente.

Solution que je souhaite mettre en place : Avoir le même fingerprint sur les 2 machines (Prod et Backup), par contre je ne sais pas faire (et google ne m'aide pas bcp).

Contrainte : Il y a déjà d'autre service qui tourne sur ces machines donc je ne peux pas faire un clone de la Prod, par contre je peux réinstaller le serveur SSH.

Merci d'avance pour les pistes que vous pourriez m'apporter.

 

[bebRito]

Salut !

A ma connaissance, le même fingerprint sur des machines différentes n'est pas faisable. En tout cas, même si ca l'est, ca ne doit pas être top niveau sécurité.

A mon avis, la meilleure solution serait de créer les clés pour tes machines et brider ton serveur SSH pour qu'il ne fournisse pas automatiquement de clé.

 

[batchy]

il n'y a pas de moyen propre de résoudre ce problème. faut choisir entre la méthode crade et la méthode ignoble :

crade : copier les clefs (/etc/ssh/ssh_host*) du premier serveur vers le deuxième. les deux serveurs devraient alors avoir le même fingerprint.
ignoble : désactiver l'authentification du serveur (CheckHostIp no dans la conf)

et ton serveur ssh est obligé de fournir une clef maître, sinon, il peut pas créer de clef de session.

 

[bebRito]

Ca me fait réviser mon ssh, merci batchy

Ma réponse précédente était plus que bof !!

 

[zeb]

Batchy, en quoi copier des clefs d'un serveur à l'autre est une méthode crade ?
Bien au contraire. On n'appelle plus ça une clef, mais un certificat, et on le balade là où on en a besoin.

 

[marsien]

Batchy, en quoi copier des clefs d'un serveur à l'autre est une méthode crade ?
Bien au contraire. On n'appelle plus ça une clef, mais un certificat, et on le balade là où on en a besoin.

Pour ta retraite, tu pourras te lancer en politique, tu maîtrises très bien la[strike] langue de bois[/strike] sémantique [:al0y]

 

[zeb]

Bah quoi ! :spamafote: ...

/private
(Je ferais sans doute un bon politicien : je ne rate jamais une occasion de faire un bon mot - même s'il faut parfois trier, je maîtriserais aux dires de Marsien la langue de bois, et pire que tout, je suis prêt à la plus grande mauvaise foi possible pour avoir toujours raison :sol: Votez pour moi \/ )

 

[batchy]

Batchy, en quoi copier des clefs d'un serveur à l'autre est une méthode crade ?
Bien au contraire. On n'appelle plus ça une clef, mais un certificat, et on le balade là où on en a besoin.

Parce que ça ressemble plus à une tentative de piratage qu'autre chose. Le but avoué est quand même de faire en sorte que des messages d'avertissement de problème de sécurité ne s'affichent pas.

mais pour la redondance, je comprend qu'il faudrai surtout pas qu'il y ai une différence entre la prod et le backup.

Et puis, ça ne sera toujours pas un certificat, car ssh stocke à la fois le nom de domaine, l'ip qui correspond et le fingerprint dans known_hosts. même si le serveur change d'ip, il faudra le réajouter dans known_hosts.

 

[Akira78]

Bonjour,

Merci Batchy.

Sur une distrib RedHat (mais c'est équivalent sur d'autre), il suffit de récupérer les clefs serveurs (ssh_host_*) qui se trouve dans /etc/ssh/ du serveur principale et de les transférer sur le 2nd serveur.

Attention : Pendant que les anciennes clefs du serveur secondaire sont effacé, on ne peut plus établir de nouvelle connexion ssh : Ayez une session stable sous peine de perdre l'accès ssh.

 

[Akira78]

Batchy, en quoi copier des clefs d'un serveur à l'autre est une méthode crade ?
Bien au contraire. On n'appelle plus ça une clef, mais un certificat, et on le balade là où on en a besoin.

Parce que ça ressemble plus à une tentative de piratage qu'autre chose. Le but avoué est quand même de faire en sorte que des messages d'avertissement de problème de sécurité ne s'affichent pas.

mais pour la redondance, je comprend qu'il faudrai surtout pas qu'il y ai une différence entre la prod et le backup.

Et puis, ça ne sera toujours pas un certificat, car ssh stocke à la fois le nom de domaine, l'ip qui correspond et le fingerprint dans known_hosts. même si le serveur change d'ip, il faudra le réajouter dans known_hosts.

Pour l'IP, j'ai un script Perl qui monte un IP aliasing sur la machine maître.

 

[VaderFR]

sinon, faire une "synchro" du serveur actif sur celui de backup avec rsync.... (désolé du déterrage de topic)
...avec un script qui en fonction de l'adresse mac, détermine si on est "par défaut" le nominal ou le backup, et en fonction de ça, effectue les tests de connectivité pour initialiser l'adresse ip.

 

[Akira78]

sinon, faire une "synchro" du serveur actif sur celui de backup avec rsync.... (désolé du déterrage de topic)
...avec un script qui en fonction de l'adresse mac, détermine si on est "par défaut" le nominal ou le backup, et en fonction de ça, effectue les tests de connectivité pour initialiser l'adresse ip.

Le problème avec une vérif d'adresse MAC est que tu dois être sur le même LAN (ou VLAN) et nécessite que le client soit "conscient" de la possibilité d'une bascule. Avec une IP Flottante tes clients peuvent être partout dans le monde et n'ont rien de particulier à faire de leur coté.

 

[VaderFR]

Le problème avec une vérif d'adresse MAC est que tu dois être sur le même LAN (ou VLAN) et nécessite que le client soit "conscient" de la possibilité d'une bascule. Avec une IP Flottante tes clients peuvent être partout dans le monde et n'ont rien de particulier à faire de leur coté.

en fait ce n'est pas de cela qu'il s'agit.
sur un site, j'ai deux serveurs. un nominal, l'autre en backup (sauvegarde)
donc en temps normal, utiliser rsync (ou scp) pour mettre sur le serveur de backup les données et la configuration du nominal.
pour ce faire, les serveurs sont capables de s'authentifier par clé l'un sur l'autre, les clés SSH étant les mêmes (copiées du nominal au backup) comme dans la solution crade de batchy "copier les clefs (/etc/ssh/ssh_host*) du premier serveur vers le deuxième"

c' est le sujet du topic à la base.

donc au démarrage, en fonction de sa propre adresse mac et en lisant un fichier de config commun aux 2, chaque machine détermine si elle est nominale ou backup et démarre avec soit l'adresse IP "privee" du backup, soit l'adresse IP "publique" que les clients vont interroger.
ensuite, le serveur backup vérifiera la présence sur le réseau (et donc le bon fonctionnement) du nominal, et prendra son adresse IP si besoin pour prendre le relais.