Accès à SSH_AUTH_SOCK à partir d'un autre utilisateur non root


11

Le scénario:

J'exécute ssh-agent sur mon PC local et tous mes serveurs / clients sont configurés pour transférer l'authentification de l'agent SSH. Je peux sauter entre toutes mes machines en utilisant l'agent ssh sur mon PC local. Ça marche.

Je dois pouvoir SSH sur une machine en tant que moi-même (utilisateur1) , changer pour un autre utilisateur nommé utilisateur2 ( sudo -i -u utilisateur2 ), puis ssh dans une autre boîte en utilisant l'agent ssh que j'exécute sur mon PC local. Disons que je veux faire quelque chose comme ssh user3 @ machine2 (en supposant que user3 a ma clé SSH publique dans leur fichier authorized_keys).

J'ai sudo configuré pour conserver la variable d'environnement SSH_AUTH_SOCK .

Tous les utilisateurs impliqués (utilisateur [1-3]) sont des utilisateurs non privilégiés (pas root).

Le problème:

Lorsque je passe à un autre utilisateur, même si la variable SSH_AUTH_SOCK est définie correctement, (disons son ensemble sur: /tmp/ssh-HbKVFL7799/agent.13799) user2 n'a pas accès au socket créé par user1 - Lequel de est logique, sinon l'utilisateur2 pourrait détourner la clé privée de l'utilisateur1 et sauter en tant qu'utilisateur.

Ce scénario fonctionne très bien si au lieu d'obtenir un shell via sudo pour user2, j'obtiens un shell via sudo pour root. Car naturellement root a accès à tous les fichiers de la machine.

La question:

En utilisant de préférence sudo, comment puis-je passer de l'utilisateur1 à l'utilisateur2, mais avoir toujours accès à SSH_AUTH_SOCK de l'utilisateur1?

Réponses:


12

Il y a deux choses que vous devez faire:

  1. définissez la SSH_AUTH_SOCKvariable pour qu'elle pointe vers le fichier correct
  2. permettre à l'autre utilisateur de se connecter au socket (en utilisant les autorisations du système de fichiers)

Par conséquent, ce que vous pourriez faire, c'est:

En tant qu'utilisateur1, autorisez l'utilisateur2 à se connecter au socket (accès complet au socket et autorisations d'accès au répertoire). J'espère que vous /tmpautorisez les ACL.

setfacl -m u:user2:rw $SSH_AUTH_SOCK
setfacl -m u:user2:x $(dirname $SSH_AUTH_SOCK)

Passez à l'autre utilisateur et exportez la variable correctement.

sudo -u user2 env SSH_AUTH_SOCK=$SSH_AUTH_SOCK ssh user3@machine2

Si vous souhaitez ouvrir un shell interactif à l'aide sudo, vous devrez exporter la SSH_AUTH_SOCKvariable vous-même après avoir obtenu le shell.


Merci d'avoir répondu. Cela fonctionne parfaitement et est parfaitement logique. Désolé pour la réponse tardive, je n'ai pas reçu d'avis que quelqu'un avait répondu.
Danny F
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.