transfert de ssh-agent et sudo à un autre utilisateur

Si vous êtes autorisé à sudo su - $USER alors vous auriez probablement de bons arguments pour être autorisé à faire un ssh -AY $USER@localhost à la place, avec votre clé publique valide dans le répertoire personnel de $USER. Votre transfert d'authentification se fera alors avec vous.

En combinant les informations des autres réponses, j'ai trouvé ceci :

user=app
setfacl -m $user:x $(dirname "$SSH_AUTH_SOCK")
setfacl -m $user:rwx "$SSH_AUTH_SOCK"
sudo SSH_AUTH_SOCK="$SSH_AUTH_SOCK" -u $user -i

J'aime ça parce que je n'ai pas besoin d'éditer sudoers fichier.

Testé sur Ubuntu 14.04 (a dû installer acl paquet).

N'utilisez pas sudo su - USER mais plutôt sudo -i -u USER . Cela fonctionne pour moi !

Je pense qu'il y a un problème avec le - (tiret) après l'option su dans votre commandement :

sudo su - otheruser

Si vous lisez la page de manuel de su vous trouverez peut-être que l'option -, -l, --login démarre l'environnement Shell en tant que login Shell. Ceci chargera l'environnement pour otheruser indépendamment des variables d'environnement où vous exécutez su .

En termes simples, le tableau de bord va saper tout ce que vous avez passé de sudo .

A la place, vous devriez essayer cette commande :

sudo -E su otheruser

Comme l'a souligné @joao-costa, -E préservera toutes les variables dans l'environnement où vous avez exécuté sudo . Puis sans le tableau de bord, su utilisera directement cet environnement.

Malheureusement, si vous vous connectez à un autre utilisateur (ou même si vous utilisez sudo), vous perdrez la possibilité d'utiliser vos clés transférées. Il s'agit d'une fonctionnalité de sécurité : Vous ne voulez pas que des utilisateurs aléatoires se connectent à votre ssh-agent et utilisent vos clés :)

La méthode "ssh -Ay ${USER}@localhost" est un peu lourde (et, comme indiqué dans mon commentaire sur la réponse de David, sujette aux pannes), mais c'est probablement ce que vous pouvez faire de mieux.