Copiez les clés ssh d'un serveur vers un autre serveur

J'ai un serveur (supposons que son adresse IP soit abcd) qui permet aux utilisateurs de se connecter via ssh. Maintenant, je veux changer la machine physique en gardant la même IP. Pour que la nouvelle machine soit toujours accessible par un utilisateur comme celui-ci

$ ssh abcd

Le problème est que chaque fois qu'un utilisateur essaie de se connecter, il obtient l'erreur de non-concordance de clé ssh suivante.

@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@ @@@@@@@@@@
@ AVERTISSEMENT: L'IDENTIFICATION DE L'HÔTE À DISTANCE A CHANGÉ! @
@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@ @@@@@@@@@@
IL EST POSSIBLE QUE QUELQU'UN FAIT QUELQUE CHOSE DE MÉCHANT!
Quelqu'un pourrait vous espionner en ce moment (attaque de l'homme du milieu)!
Il est également possible que la clé d'hôte RSA vient d'être modifiée.
L'empreinte digitale de la clé RSA envoyée par l'hôte distant est
02: dc: c6: 18: 1b: 34: b7: 1d: fa: 90: ab: e1: 95: 48: 69: 84.
Veuillez contacter votre administrateur système.
Ajoutez la clé d'hôte correcte dans /home/user/.ssh/known_hosts pour vous débarrasser de ce message.
Clé incriminée dans /home/user/.ssh/known_hosts:37
La clé d'hôte RSA pour les anciens a changé et vous avez demandé une vérification stricte.
La vérification de la clé d'hôte a échoué.

Je sais que l'utilisateur peut supprimer la ligne # 37 du fichier ~ / .ssh / known_hosts et la prochaine fois, elle recevra une invite oui / non. Ce que je veux, c'est que l'utilisateur ne soit pas tenu au courant de tout ce remplacement de machine et obtienne simplement un mot de passe.

Comment faire ça?

ssh

— Souvik Pal
source

Savez-vous que cela annulerait sshla seule protection contre l'homme au milieu des attaques et pourrait vous amener à envoyer votre mot de passe directement à l'attaquant au lieu de la machine prévue? Sauf si vous savez pertinemment que vous êtes invulnérable aux attaques actives (par exemple, vous êtes sur le même réseau interne sécurisé que la machine cible), cela détruit sshle modèle de sécurité de.

— David Schwartz

Oui. Les deux machines sont dans les mêmes réseaux internes. Même les utilisateurs sont à l'intérieur du même réseau interne. Compte tenu de cette situation, quelles sont mes options?

— Souvik Pal

Ce n'est pas assez. Ils doivent être dans le même réseau interne sécurisé . Autrement dit, ils doivent absolument, 100% avoir confiance qu'aucun appareil n'est connecté à ce réseau interne qui n'est pas 100% sécurisé, et ils doivent 100% faire confiance à tous ceux qui contrôlent ces appareils ou peuvent connecter un appareil à ce réseau. En d'autres termes, dans presque tous les scénarios réalistes, c'est une mauvaise idée.

— David Schwartz

C'est une chose parfaitement raisonnable à faire. Je réplique les clés du serveur ssh sur un autre serveur pour HA afin que lorsque je me connecte, je reçois ces erreurs. En plus, je reçois un e-mail lors du basculement

— Matt H

Je suis d'accord avec Matt. Si vous contrôlez les deux machines et donc le propriétaire des clés, déplacer la clé hôte d'une machine à une autre sous votre contrôle N'EST PAS un homme au milieu attaque ou risque. Si l'utilisateur qui se connecte fait confiance à votre clé d'hôte, cela ne devrait pas avoir d'importance.

— Ross

Réponses:

Comme Ethabell l'a mentionné, vous pouvez copier les clés d'hôte actuelles vers le nouveau serveur.

Vous pouvez trouver vos clés d'hôte en ouvrant votre sshd_configfichier (sur mon Ubuntu 12.04 box its /etc/ssh/sshd_config). Dans le fichier de configuration, recherchez les HostKeyentrées. Ces entrées vous indiqueront l'emplacement des fichiers de clés d'hôte. Vous devriez pouvoir copier ces fichiers sur le nouveau serveur et mettre à jour ceux du nouveau serveur sshd_configpour pointer vers les clés copiées (ou simplement remplacer les fichiers qui existent déjà sur le nouveau serveur).

Notez également cette section de la sshd_configpage de manuel, en particulier la partie sur les autorisations:

Spécifie un fichier contenant une clé d'hôte privée utilisée par SSH. La valeur par défaut est /etc/ssh/ssh_host_keypour le protocole version 1, et /etc/ssh/ssh_host_dsa_key, /etc/ssh/ssh_host_ecdsa_keyet /etc/ssh/ssh_host_rsa_keypour le protocole version 2. Notez que sshd (8) refusera d'utiliser un fichier s'il est accessible au groupe / au monde. Il est possible d'avoir plusieurs fichiers de clés d'hôte. Les clés «rsa1» sont utilisées pour la version 1 et «dsa», «ecdsa» ou «rsa» sont utilisées pour la version 2 du protocole SSH.

— lourd
source

Si vous aviez la clé d'hôte d'origine, vous pourriez la restaurer et cela arrêterait l'erreur.

Ou, vous pouvez désactiver StrictHostKeyChecking dans votre fichier de configuration sshd.

... Faire cela, cependant, est une très mauvaise idée. S'il existe un moyen pour vous de simplement exécuter ssh-keygen -R server.example.comsur les machines clientes, ce serait le meilleur moyen - car la désactivation de la vérification des clés d'hôte revient à dire: «Hé. Attaquez-moi». J'obtiens de l'obscurité quand les choses changent, mais la sécurité devrait être la priorité n ° 1 sur les changements d'obscurcissement.

— Ethabelle
source

Pouvez-vous expliquer comment restaurer les clés d'hôte sur une machine plus récente?

— Souvik Pal

Vous pouvez l'essayer comme ça

cat ~/.ssh/id_rsa.pub | ssh <user>@<hostname> 'cat >> .ssh/authorized_keys && echo "Key copied"'

Notez que si le dossier .ssh n'existe pas déjà, la commande ci-dessus échouera. En outre, il peut être préférable lors de la création du fichier de définir une autorisation minimale possible (essentiellement en lecture-écriture pour le propriétaire uniquement). Voici une commande plus avancée:

cat ~/.ssh/id_rsa.pub | ssh <user>@<hostname> 'umask 0077; mkdir -p .ssh; cat >> .ssh/authorized_keys && echo "Key copied"'

Pour plus d'informations sur ce problème, vous devez accéder à ce site Web: Erreur de changement de clé d'hôte SSH

— Govind Karamta
source