transfert de ssh-agent et sudo à un autre utilisateur

Comme vous l'avez mentionné, les variables d'environnement sont supprimées par sudo pour des raisons de sécurité.

Mais heureusement sudo est assez configurable : vous pouvez lui indiquer précisément les variables d'environnement que vous souhaitez conserver grâce à la fonction env_keep option de configuration dans /etc/sudoers .

Pour le transfert d'agent, vous devez conserver l'adresse de l'agent. SSH_AUTH_SOCK variable d'environnement. Pour ce faire, il suffit de modifier votre /etc/sudoers (toujours en utilisant visudo ) et définir le env_keep aux utilisateurs concernés. Si vous souhaitez que cette option soit définie pour tous les utilisateurs, utilisez l'option Defaults une ligne comme celle-ci :

Defaults    env_keep+=SSH_AUTH_SOCK

man sudoers pour plus de détails.

Vous devriez maintenant être en mesure de faire quelque chose comme ceci (pourvu que user1 La clé publique de l'utilisateur est présente dans ~/.ssh/authorized_keys en user1@serverA y user2@serverB et serverA 's /etc/sudoers est configuré comme indiqué ci-dessus) :

user1@mymachine> eval `ssh-agent`  # starts ssh-agent
user1@mymachine> ssh-add           # add user1's key to agent (requires pwd)
user1@mymachine> ssh -A serverA    # no pwd required + agent forwarding activated
user1@serverA> sudo su - user2     # sudo keeps agent forwarding active :-)
user2@serverA> ssh serverB         # goto user2@serverB w/o typing pwd again...
user2@serverB>                     # ...because forwarding still works

sudo -E -s

• -E préservera l'environnement
• -s lance une commande, par défaut un Shell.

Cela vous donnera une racine Shell avec les clés originales toujours chargées.

Autoriser autre utilisateur d'accéder $SSH_AUTH_SOCK le fichier et son répertoire, par exemple par une ACL correcte, avant d'y accéder.

L'exemple suppose que Defaults:user env_keep += SSH_AUTH_SOCK en /etc/sudoers sur la machine "hôte" :

$ ssh -A user@host
user@host$ setfacl -m otheruser:x   $(dirname "$SSH_AUTH_SOCK")
user@host$ setfacl -m otheruser:rwx "$SSH_AUTH_SOCK"
user@host$ sudo su - otheruser
otheruser@host$ ssh server
otheruser@server$

Plus sûr et fonctionne aussi pour les utilisateurs non rootés

J'ai constaté que cela fonctionne également.

sudo su -l -c "export SSH_AUTH_SOCK=$SSH_AUTH_SOCK; bash"

Comme d'autres l'ont noté, cela ne fonctionnera pas si l'utilisateur vers lequel vous basculez n'a pas les droits de lecture sur $SSH_AUTH_SOCK (ce qui correspond à peu près à tout utilisateur autre que root). Vous pouvez contourner ce problème en donnant à $SSH_AUTH_SOCK et au répertoire dans lequel il se trouve les permissions 777.

chmod 777 -R `dirname $SSH_AUTH_SOCK`
sudo su otheruser -l -c "export SSH_AUTH_SOCK=$SSH_AUTH_SOCK; bash"

C'est assez risqué cependant. En fait, vous donnez à tous les autres utilisateurs du système la permission d'utiliser votre agent SSH (jusqu'à ce que vous vous déconnectiez). Vous pouvez également définir le groupe et modifier les autorisations en 770, ce qui pourrait être plus sûr. Cependant, lorsque j'ai essayé de changer le groupe, j'ai obtenu "Operation not permitted".

Vous pouvez toujours simplement vous connecter à l'hôte local avec le transfert d'agent au lieu d'utiliser sudo :

ssh -A otheruser@localhost

L'inconvénient est que vous devez vous reconnecter, mais si vous l'utilisez dans un onglet écran/tmux, ce n'est qu'un effort unique, cependant, si vous vous déconnectez du serveur, le socket sera (bien sûr) à nouveau cassé. Ce n'est donc pas l'idéal si vous ne pouvez pas garder votre session écran/tmux ouverte à tout moment (vous pouvez cependant mettre à jour manuellement votre fichier SSH_AUTH_SOCK env var si vous êtes cool).

Notez également que lorsque vous utilisez la redirection ssh, root peut toujours accéder à votre socket et utiliser votre authentification ssh (tant que vous êtes connecté avec la redirection ssh). Assurez-vous donc que vous pouvez faire confiance à root.