Même fingerprint ssh sur 2 machines
Dernière réponse : dans Le monde de Linux
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.
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.
Autres pages sur : fingerprint ssh machines
Lassé par la pub ? Créez un compte
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é.
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é.
Meilleure solution
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.
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.
- Akira78 a sélectionné cette solution comme la meilleure réponse
Contenus similaires
- Iptables port ssh - Forum
- Logiciel de sauvegarde backup - Forum
- Desinstaller ssh linux - Forum
- Backup sous linux - Forum
zeb a dit :
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.
![[:al0y]](http://m.bestofmedia.com/sfp/design/usr/fr/smilies/f1/59/al0y.gif "[:al0y]")
Bah quoi ! ![:spamafote:]( ":spamafote:")
... ![:whistle:]( ":whistle:")
/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:]( ":sol:")
Votez pour moi \![:o]( ":o")
/ )
... 
/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
Votez pour moi \
/ ) zeb a dit :
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.
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.
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.
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 a édité ce message
- Akira78 a édité ce message
batchy a dit :
zeb a dit :
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.
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.
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.
...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.
- VaderFR a édité ce message
VaderFR a dit :
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é.
Lassé par la pub ? Créez un compte
