transfert ssh-agent et Sudo à un autre utilisateur
Si j'ai un serveur A dans lequel je peux me connecter avec ma clé ssh et que j'ai la possibilité de "Sudo su - autre utilisateur", je perds le transfert de clé, car les variables env sont supprimées et le socket est uniquement lisible par mon utilisateur d'origine. Existe-t-il un moyen de relier le transfert de clé via le "Sudo su - otheruser", donc je peux faire des trucs sur un serveur B avec ma clé transférée (git clone et rsync dans mon cas)?
La seule façon dont je peux penser est d'ajouter ma clé aux clés autorisées de otheruser et "ssh otheruser @ localhost", mais c'est lourd à faire pour chaque combinaison utilisateur/serveur que je peux avoir.
En bref:
$ Sudo -HE ssh user@Host
(success)
$ Sudo -HE -u otheruser ssh user@Host
Permission denied (publickey).
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 dire précisément quelles variables d'environnement vous souhaitez conserver grâce à l'option de configuration env_keep dans /etc/sudoers.
Pour le transfert d'agent, vous devez conserver la variable d'environnement SSH_AUTH_SOCK. Pour ce faire, modifiez simplement votre fichier de configuration /etc/sudoers (toujours en utilisant visudo) et définissez l'option env_keep sur les utilisateurs appropriés. Si vous souhaitez que cette option soit définie pour tous les utilisateurs, utilisez la ligne Defaults comme ceci:
Defaults env_keep+=SSH_AUTH_SOCK
man sudoers pour plus de détails.
Vous devriez maintenant pouvoir faire quelque chose comme ça (à condition que la clé publique de user1 soit présente dans ~/.ssh/authorized_keys dans user1@serverA et user2@serverB, et serverA's _ /etc/sudoers le fichier 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 exécute une commande, par défaut un Shell
Cela vous donnera un shell racine avec les clés d'origine toujours chargées.
Autorisez autre utilisateur à accéder à $SSH_AUTH_SOCK fichier et son répertoire, par exemple par ACL correct, avant de passer à eux. L'exemple suppose que Defaults:user env_keep += SSH_AUTH_SOCK dans /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écurisé et fonctionne également pour les utilisateurs non root ;-)
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 passez n'a pas d'autorisations de lecture sur $ SSH_AUTH_SOCK (qui est à peu près n'importe quel utilisateur en plus de root). Vous pouvez contourner ce problème en définissant $ SSH_AUTH_SOCK et le répertoire dans lequel il se trouve pour disposer des autorisations 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. Vous donnez essentiellement à tous les autres utilisateurs du système l'autorisation d'utiliser votre agent SSH (jusqu'à votre déconnexion). Vous pouvez également définir le groupe et modifier les autorisations sur 770, ce qui pourrait être plus sécurisé. Cependant, quand j'ai essayé de changer de groupe, j'ai eu "Opération non autorisée".
Si vous êtes autorisé à Sudo su - $USER, alors vous auriez probablement un bon argument pour être autorisé à faire un ssh -AY $USER@localhost à la place, avec votre clé publique valide dans le répertoire personnel de $ USER. Ensuite, votre transfert d'authentification serait effectué avec vous.
Vous pouvez toujours simplement ssh to localhost 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 screen/tmux, ce n'est qu'un effort unique, cependant, si vous vous déconnectez du serveur, le socket sera (bien sûr) à nouveau cassé . Il n'est donc pas idéal si vous ne pouvez pas garder votre session écran/tmux ouverte à tout moment (cependant, vous pouvez mettre à jour manuellement votre SSH_AUTH_SOCK env var si vous êtes cool).
Notez également que lorsque vous utilisez le transfert ssh, root peut toujours accéder à votre socket et utiliser votre authentification ssh (tant que vous êtes connecté avec le transfert ssh). Assurez-vous donc que vous pouvez faire confiance à root.
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 le fichier sudoers.
Testé sur Ubuntu 14.04 (a dû installer le package acl).
N'utilisez pas Sudo su - USER, mais plutôt Sudo -i -u USER. Travaille pour moi!
Je pense qu'il y a un problème avec le - (tiret) option après su dans votre commande:
Sudo su - otheruser
Si vous lisez la page de manuel de s , vous pouvez constater que l'option -, -l, --login démarre l'environnement Shell en tant que Shell de connexion. Ce sera l'environnement pour otheruser quelles que soient les variables env où vous exécutez su.
Autrement dit, le tiret minera tout ce que vous avez passé de Sudo.
Au lieu de cela, vous devriez essayer cette commande:
Sudo -E su otheruser
Comme l'a souligné @ joao-costa, -E conservera toutes les variables de l'environnement dans lequel vous avez exécuté Sudo. Sans le tiret, su utilisera directement cet environnement.
Malheureusement, lorsque vous passez à un autre utilisateur (ou même utilisez Sudo), vous perdrez la possibilité d'utiliser vos clés transférées. Ceci est une fonction de sécurité: vous ne voulez pas que des utilisateurs aléatoires se connectent à votre agent ssh 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 à la rupture), mais c'est probablement le mieux que vous puissiez faire.