Comment exporter la clé publique de mon SSH?


12

J'ai besoin de configurer des sessions ssh entre deux serveurs et je ne veux pas que le script remplisse à chaque fois le nom d'utilisateur et le mot de passe.

Cependant, je n'arrive pas à savoir d'où le serveur SSH utilise sa configuration.

bash-2.05# ssh -V
Sun_SSH_1.1, SSH protocols 1.5/2.0, OpenSSL 0x0090700f

J'ai un fichier de fichiers de certificats dans / etc / ssh / et ~ / .ssh /. Je ne peux trouver qu'un seul fichier de configuration pour SSH et il se trouve dans / etc / ssh / ssh_config, mais il ne contient aucune donnée (tout est commenté).

Est-ce que quelqu'un sait comment je peux savoir où le certificat est stocké, ou comment l'exporter pour pouvoir le transférer sur l'autre serveur? J'espérais que les fichiers de configuration me donneraient la réponse, mais ils ne fournissent que peu ou pas d'aide.

Réponses:


17

En supposant que vous entendez l'authentification par clé publique au niveau utilisateur par «certificat» et que vous les avez créés en utilisant ssh-keygenl'emplacement par défaut, ils devraient être à l'endroit où votre client ssh les trouvera. La clé se compose d'une partie privée, généralement stockée dans ~/.ssh/id_rsaet d'une partie publique dans ~/.ssh/id_rsa.pub. Le dernier devra être transféré vers le serveur distant, généralement vers ~/.ssh/authorized_keys.

La manière la plus simple de transférer la clé vers un autre serveur est d'utiliser ssh-copy-idavec la machine cible. Si vous avez utilisé l'emplacement par défaut lors de la création, cette clé sera automatiquement utilisée.

Notez que /etc/ssh/ssh_configc'est pour le client. Sur le serveur, vous devrez regarder /etc/ssh/sshd_config. Dans votre configuration, les deux serveurs serviront à la fois de client ssh et de serveur ssh, vous devrez donc regarder les deux fichiers aux deux extrémités.


Je l'ai fait fonctionner. Je vous remercie. La seule chose que je devais faire était sur mon client, je devais spécifier le paramètre -i (identité) pointant vers la clé privée.
Chris Dale

2

Vous devez trouver la clé publique ssh de l'utilisateur qui sera l'utilisateur de connexion pour le script.

Par exemple, si j'ai serverA et serverB, je ferais ce qui suit.

sudo adduser scriptrunner
...
sudo su - scriptrunner
ssh-keygen
...
cat .ssh/id_rsa.pub
ssh-rsa AAAAB3Nza...... scriptrunner@serverA

puis faites quelque chose de similaire sur ServerB

Ensuite, sur serverA, injectez la clé publique de l'utilisateur de scripttrunner de serverB dans /home/scriptrunner/.ssh/authorized_keys

et faites le contraire sur serverB (en utilisant l'utilisateur de scripttrunner de serverA sur en /home/scriptrunner/.ssh/authorized_keystouches_autorisées sur serverB)

Ensuite, vous devriez pouvoir faire à ssh scriptrunner@serverApartir de serverB en utilisant la clé, et vice versa.

Vous pouvez également utiliser ssh-copy-idpour effectuer le bit authorized_keys.


1

Afin d'établir une connexion ssh avec authentification par clé publique, l'utilisateur qui initie la connexion doit avoir une paire de clés publique / privée. Sur de nombreuses distributions Linux, ces clés ne sont pas générées par défaut et doivent être générées par l'utilisateur lui-même (ou par l'administrateur en son nom).

Si vous êtes connecté en tant qu'utilisateur concerné, accédez à votre répertoire personnel et exécutez

ssh-keygen

Acceptez toutes les valeurs par défaut et une nouvelle paire de clés sera créée dans ~ / .ssh / id_rsa et ~ / .ssh / id_rsa.pub. Copiez maintenant la clé publique et collez-la dans le fichier ~ / .ssh / authorized_keys du compte d'utilisateur cible sur la machine cible. Activez ensuite l'authentification par clé publique sur la machine cible (dans / etc / ssh / sshd_config) et vous devriez être prêt à partir.

REMARQUE : il existe de nombreux pièges possibles dans ce processus lorsque vous le faites pour la première fois. Toutes les autorisations doivent être correctes et les fichiers doivent être au bon endroit. Il est probablement préférable de suivre un HowTo comme celui-ci .

En utilisant notre site, vous reconnaissez avoir lu et compris notre politique liée aux cookies et notre politique de confidentialité.
Licensed under cc by-sa 3.0 with attribution required.