Utiliser une clé transférée spécifique de SSH-agent?

Disons que j'ai une clé pour Github, ainsi que d'autres clés. J'ai ajouté beaucoup de clés à mon agent ssh ( ssh-add -Lretourne beaucoup de lignes) sur mon ordinateur personnel A. Dans mon, .ssh/configj'ai configuré quelle clé utiliser avec quel hôte, par exemple

ssh -T -vvv git@github.com 2>&1 | grep Offering

donne

debug1: Offering RSA public key: /Users/doxna/.ssh/id_rsa.github

Une seule clé est offerte, comme prévu. Mais ensuite ssh-ing à un hôte B avec ForwardAgent yeset en répétant la même commande, je reçois

debug1: Offering RSA public key: /Users/doxna/.ssh/id_rsa.linode2
debug1: Offering RSA public key: /Users/doxna/.ssh/id_rsa.helium
debug1: Offering RSA public key: /Users/doxna/.ssh/id_rsa.github

ce qui signifie qu'il essaie toutes mes clés. Cela est problématique car seul un nombre limité de clés peut être essayé avant le retour des serveurs Too many authentication failures. J'ai donc essayé de modifier .ssh/configsur l'hôte B pour inclure

Host github.com
  IdentityFile /Users/doxna/.ssh/id_rsa.github
  IdentitiesOnly yes

mais je ne reçois aucune offre clé, mais plutôt

debug2: key: /Users/doxna/.ssh/id_rsa.github ((nil))

ce qui, je suppose, signifie que la clé n'a pas été trouvée (?) Et après tout, la clé se trouve sur mon ordinateur personnel A, pas sur l'hôte B, donc la question est de savoir comment s'y référer sur l'hôte B? J'espère que j'ai réussi à expliquer la question.

ssh ssh-agent

— danmichaelo
source

Réponses:

Tu as la bonne idée. La seule partie qui vous manque est que le fichier pointé par IdentityFiledoit exister. Il n'a pas besoin de contenir de clé privée, il suffit de disposer de la seule clé publique.

Sur l'hôte B, vous pouvez extraire la clé publique de l'agent en tapant ssh-add -L | grep /Users/doxna/.ssh/id_rsa.github > ~/.ssh/id_rsa.github.pubpuis pointer vers ce fichier depuis~/.ssh/config

— kasperd
source

Pour info le nom de la clé publique n'a pas d'importance. Il sélectionnera la clé appropriée de l'agent en fonction du contenu.

— akostadinov

@akostadinov True. Si vous pointez sshsur un fichier de clé publique sans fichier de clé privée associé, il doit simplement lire la clé publique du fichier et demander à l'agent d'utiliser la clé privée correspondante pour générer la signature.

— kasperd

Cela enregistre efficacement votre clé sur l'hôte B! Voir la réponse ci-dessous par @ mc0e pour une solution qui n'enregistre pas la clé sur le serveur.

— Pitt

@Pitt Non, ce n'est pas le cas. Il stocke uniquement la clé publique . Et ce n'est pas un problème car la clé publique ne devait jamais être gardée secrète en premier lieu. Le transfert d'agent donne à l'hôte l'accès à l'utilisation de la clé tant que le transfert d'agent est en place, mais l'agent n'enverra jamais la clé secrète nulle part.

— kasperd

@kasperd vous n'avez pas besoin d'une copie réelle de la clé privée pendant que vous disposez d'une connexion en direct à un agent utilisateur avec la clé. En tant que root, vous pouvez accéder aux connexions d'agent d'autres utilisateurs connectés.

— mc0e

Bonne réponse de @Kasperd, mais notez également que si l'hôte B est compromis ou si vous ne faites pas confiance à tous ceux qui ont les privilèges root, vous exposez toujours toutes vos clés à des abus aussi longtemps que vous êtes connecté sur cet hôte.

Une meilleure approche pourrait donc consister à transférer uniquement l'accès aux clés dont vous avez besoin. Essayez peut-être ssh-agent-filterqui se trouve dans les référentiels debian / Ubuntu, ou à partir de github .

EDIT: J'ai choisi ssh-identplutôt que ssh-agent-filterde transférer des clés de manière sélective, bien que ce ne soit pas une expérience aussi fluide que l'on pourrait l'espérer.

— mc0e
source

D'après le commentaire de @ kasperd sur sa réponse: "il ne le fait pas. Il ne stocke que la clé publique. Et ce n'est pas un problème car la clé publique ne devait jamais être gardée secrète en premier lieu. Le transfert d'agent donne à l'hôte l'accès à utiliser la clé tant que le transfert d'agent est en place, mais l'agent n'enverra jamais la clé secrète nulle part "

— Bdoserror

@Bdoserror En tant que root, vous pouvez abuser de la connexion ssh-agent pendant que l'utilisateur associé est connecté. Il vous suffit de copier les SSH_*variables d'environnement et de vous connecter où vous le souhaitez à l'aide de la clé, même si vous n'en avez jamais eu de copie réelle.

— mc0e

Pour clarifier: cette réponse est en effet fausse - bien que le scénario d'abus de mc0e soit réel, cela n'a rien à voir avec la sauvegarde de la clé publique - si l'hôte intermédiaire est compromis, votre connexion d'agent peut être utilisée pour s'authentifier avec votre clé privée, indépendamment si vous enregistrez la clé publique sur l'hôte intermédiaire ou non. Votre clé privée ne sera pas compromise, et la sauvegarde de la clé publique ne sera pas plus facile, car tout attaquant qui a une connexion avec l'agent peut simplement lui demander les clés publiques de toute façon.

— Rétablir Monica le

@ marc-lehmann a relu ce que j'ai écrit. Si vous transférez des clés, elles seront exposées, mais vous pouvez limiter les clés à transférer.

— mc0e

Je marche sur ce que vous avez écrit - veuillez aborder le fond de nos commentaires, pas la personne. Le problème est que votre réponse est tout simplement erronée car elle suppose, au moment où vous écrivez, que les clés "sont transmises" à l'hôte distant. Rien de tel ne se produit et les clés elles-mêmes ne sont pas exposées.

— Rétablir Monica