Comment les clés publiques sont-elles «envoyées» aux serveurs et comment les clés privées sont-elles «utilisées» pour SSH?

Il y a deux machines Linux, A et B. Les scripts s'exécutant sur A doivent pouvoir SSH dans B. Donc A génère une clé publique (probablement une ssh-keygengénération id_rsa.pub), puis utilise sa clé privée respective (encore une fois probablement id_rsa) pour faire cette connexion SSH.

Si quelque chose que j'ai dit ci-dessus est incorrect ou trompé, veuillez commencer par me corriger!

En supposant que je suis plus ou moins sur la cible:

Comment A «donne-t-il» à B sa clé publique ( id_rsa.pub)? Doit-il s'agir d'un processus manuel ou peut-il être automatisé? Si c'est manuel, quel est le processus? S'il est automatisé, quelle est la commande? Lorsque B "obtient" cette clé publique, où va-t-elle ou est-elle stockée?
Lors du lancement de la connexion SSH vers B, comment A «utilise-t-il» sa clé privée ( id_rsa) dans le cadre de cette connexion?

linux ssh public-key-encryption

— user3178622
source

Pourquoi le downvote sans explication? Il montre que la recherche est un SSCCE et, à ma connaissance, n'est pas un doublon. Si vous n'êtes pas d'accord et pensez qu'il s'agit d'un doublon, veuillez fournir un lien vers la question dont vous pensez qu'il s'agit d'un doublon!

— user3178622

Bien que je n'aie pas déçu et que je ne pense pas que cette question soit mauvaise en aucune façon, la pile de sécurité de l'information serait peut-être un endroit plus approprié.

— MC10

Je n'ai pas non plus voté, mais je comprends pourquoi quelqu'un l'a fait. Il s'agit d'une méthode de connexion largement utilisée, bien que je convienne que les résultats de recherche Google sont encombrés de la façon de le faire fonctionner, et non de la façon dont cela fonctionne. Les articles sont possibles. Il est possible de trouver les informations que vous recherchez.

— Tyson

La notion de SSCCE n'est pas vraiment applicable aux questions qui ne concernent pas le code.

— Scott

Pas un doublon mais lié: superuser.com/questions/383732/how-does-ssh-encryption-work . Pourrait répondre à la deuxième partie de la question (comment les clés privées sont utilisées)

— Jay

Réponses:

ssh-keygengénère à la fois les clés publiques et privées, qui résident initialement uniquement localement. Donner la clé publique à un autre hôte est quelque chose que l'utilisateur devrait faire manuellement, soit en l'envoyant à un responsable du serveur B, soit si vous avez un compte avec un mot de passe, vous pouvez vous connecter et le mettre vous-même. Afin de permettre la connexion sans mot de passe au serveur B, vous devez ajouter votre clé publique au fichier ~ / .ssh / authorized_keys sur le serveur B (une clé publique par ligne, il peut y avoir un nombre quelconque de clés dans ce fichier). Il existe une commande linux ssh-copy-idqui copiera l'ID pour vous et le mettra dans le fichier.

Par défaut, ssh utilisera le fichier ~ / .ssh / id_XXX comme clé privée. XXX peut être rsa, dsa ou tout autre protocole pour lequel une clé a été générée. IIRC, dsa est vieux et ne doit pas être utilisé. Si vous souhaitez utiliser une autre clé privée, vous pouvez la spécifier dans votre commande ssh à l'aide de -i. Tant que la clé privée utilisée correspond à une clé publique sur la machine distante (dans le fichier authorized_keys du compte de l'utilisateur auquel vous vous connectez), vous n'aurez pas besoin de fournir un mot de passe.

— BamaPookie
source

Merci @BamaPookie - quelques suivis: (1) quand ssh-keygenest exécuté, vous mentionnez que les deux clés "résident uniquement localement"? Où?!? Comme dans, dans quel dossier puis-je naviguer et voir id_rsa.pubet id_rsa? (2) Je pensais que ssh-addc'était la commande pour ajouter une clé publique à authorized_keys, non? Quelle est la différence entre ssh-copy-idet ssh-add? Merci encore!

— user3178622

@ user3178622 re '1' Je ne l'ai pas devant moi mais ça ressemble à ~/.ssh/id_rsa re '2', ssh-add n'est pas pour l'ajout à des clés autorisées, c'est pour l'ajout à un trousseau .. Je n'ai pas utilisé ssh -ajoute quand même. ssh-add consiste à vous permettre de ne pas avoir à saisir de phrase clé à chaque fois que vous utilisez une clé qui nécessite une phrase clé. Donc, si vos clés ssh ne nécessitent pas de phrase clé, je suppose qu'il n'y a aucune raison d'utiliser ssh-add et je pense que vous devrez toujours utiliser ssh-copy-id ou faire la copie manuelle de la clé publique dans authorized_keys

— barlop

ssh-keygen vous demandera où enregistrer le fichier, mais l'emplacement par défaut est dans ~ / .ssh / ssh-copy-id copie la clé publique sur un hôte distant. ssh-add ajoute une clé privée à votre trousseau de clés local. L'ajout d'une clé privée à votre trousseau de clés local signifie qu'elle sera vérifiée par défaut lors d'une tentative de connexion ssh (c'est-à-dire sans avoir à la spécifier avec -i).

— BamaPookie

@BamaPookie Où vous écrivez "L'ajout d'une clé privée à votre trousseau de clés local signifie qu'elle sera vérifiée par défaut lors d'une tentative de connexion ssh (c'est-à-dire sans avoir à la spécifier avec -i)." <--- Il vaut la peine de préciser que Je pense que vous voulez dire que cela change la clé privée par défaut qui est choisie, de sorte qu'au lieu d'être id_rsa, c'est à partir du trousseau de clés. (Bien sûr, sans ssh-add, vous n'avez toujours pas besoin de spécifier une clé privée avec -i, elle aura toujours une valeur par défaut, juste une valeur par défaut différente).

— barlop

Il y a deux machines Linux, A et B. Les scripts s'exécutant sur A doivent être capables de SSH dans B. Donc A génère une clé publique (probablement un id_rsa.pub généré par ssh-keygen), puis utilise sa clé privée respective ( encore une fois, probablement id_rsa) pour établir cette connexion SSH.

Si quelque chose que j'ai dit ci-dessus est incorrect ou trompé, veuillez commencer par me corriger!

En supposant que je suis plus ou moins sur la cible:

Ouais

mais B a besoin que la clé publique de A soit répertoriée dans le fichier des clés autorisées de B pour que A puisse se connecter à B

vous pouvez également supprimer id_rsa.pub et ssh en B et cela fonctionnera toujours, car la clé publique est générée à chaque connexion ssh et n'est stockée dans aucun id_rsa.pub

Comment A «donne-t-il» à B sa clé publique (id_rsa.pub)? Doit-il s'agir d'un processus manuel ou peut-il être automatisé? Si c'est manuel, quel est le processus? S'il est automatisé, quelle est la commande?

manuel - quelque chose comme

de-

cat ~/.ssh/id_rsa.pub | ssh USER@HOST "mkdir -p ~/.ssh && cat >> ~/.ssh/authorized_keys"

ou encore plus manuellement, pour décomposer la commande

A $ cat id_rsa.pub | ssh user@host 'cat>~/a.a'

puis sur B, assurez-vous que ~ / .ssh existe puis faites cat a.a >> ~/.ssh/authorized_keys

et vous pouvez attraper les clés autorisées de B avant et après pour vous assurer que la clé est répertoriée.

Ou vous pouvez envoyer id_rsa.pub par e-mail à un compte de messagerie, puis à partir de B, B peut vérifier l'e-mail et ajouter le contenu de id_rsa.pub dans son fichier authorized_keys

automatiquement

La commande ssh-copy-id

Vous devez pouvoir entrer ssh, vous avez donc besoin d'un accès par mot de passe

Au lieu de faire ssh user @ host, vous faites ssh-copy-id user @ host et vous êtes invité à entrer un mot de passe, vous le saisissez, vous y êtes, il copiera la clé publique. Et la prochaine fois que vous utiliserez ssh user @ host, il utilisera la clé.

Lorsque B "obtient" cette clé publique, où va-t-elle ou est-elle stockée?

B's ~ / .ssh / authorized_keys

Lors du lancement de la connexion SSH à B, comment A «utilise-t-il» sa clé privée (id_rsa) dans le cadre de cette connexion?

eh bien, je ne sais pas grand-chose à ce sujet, du haut de ma tête, mais tout ce qui est crypté avec une clé peut être décrypté avec l'autre clé, et s'identifier est un peu différent de l'envoi de données .. et il peut y avoir quelque chose sur une clé temporaire aussi.

— barlop
source

Merci @barlop! Veuillez voir mes questions sous la réponse de BamaPookie; J'ai les mêmes questions pour vous!

— user3178622