web-dev-qa-db-fra.com

Ajouter une clé publique au fichier known_hosts

J'essaie de copier une clé publique du serveur A sur le fichier known_hosts du serveur B. Ce sont tous deux des serveurs linux. Initialement, je pensais ouvrir le fichier de clé publique et copier son contenu dans le fichier known_hosts mais je suppose que ce n’est pas la bonne méthode. Est-ce que quelqu'un sait quelle est la bonne façon de le faire?

Ma clé publique est au format ssh-rsa AADGD...

Quelqu'un peut aider?

Merci!

linuxsshkey
11
Trung Tran

J'ai répondu presque similaire sur SuperUser il y a quelques jours. Les parties importantes:

  • Le format diffère
  • Il existe différents types de clés d’hôte (types) sur chaque serveur (assurez-vous de coller celle qui est réellement utilisée)
  • Il y a ssh-keyscan qui peut créer le format pour vous

Sinon, il suffit de préfixer votre clé avec l'adresse IP du serveur (vous pouvez également ajouter un nom d'hôte, après une virgule), supprimez le commentaire de la fin de la ligne et tout va bien. Le format ressemble alors à ceci:

11.22.33.44 ssh-rsa AADGD...

Et encore une remarque, si vous utilisez HashKnownHosts yes (comme Debian et Ubuntu le font), vous devez re-hacher votre known_hosts tel que:

ssh-keygen -Hf ~/.ssh/known_hosts
6
Jakuje

Voici comment je l'ai fait.

  1. Générez une clé sur le serveur hôte. Utilisation de la commande ci-dessous. 

* ssh-keyscan -t rsa nom_serveur complet

Ligne de commande et sortie

  1. À présent, copiez la section en surbrillance (dans l’image) et ajoutez cette clé au fichier "hôte_connu" du serveur source. Bien entendu, l'emplacement de ce fichier peut être différent pour différents environnements.
2
user2373210

Comme je viens de tomber sur ce problème, voici comment je l’ai abordé:

Au fil du temps, copier les fichiers mécaniquement via

ssh-keyscan server-name >> ~/.ssh/known_hosts

m'a donné des entrées en double dans .ssh/known_hosts. 

D'autres méthodes manuelles m'ont obligé à créer le répertoire .ssh n'existaient pas, etc.

J'ai décidé de laisser ssh le gérer:

ssh -o StrictHostKeyChecking=no server-name ls

L’option -o StrictHostKeyChecking=no répond automatiquement «oui» à la

The authenticity of Host 'server-name (12.345.678.900)' can't be established.
RSA key fingerprint is XXXXXXX.
Are you sure you want to continue connecting (yes/no)?

message (insérez ici toutes les réserves de sécurité relatives à la connexion aléatoire à des machines que vous ne connaissez pas). 

La commande ls est juste une commande fluff qui va s'exécuter et forcer SSH à se déconnecter à la fin Vous pouvez le changer selon la commande de fluff que vous préférez. 

ssh se chargera de créer le répertoire .ssh (si nécessaire), d’ajouter une seule copie de la clé, etc.

Plate-forme: macOS 10.14

1
JS.