Question ssh-agent forwarding et sudo à un autre utilisateur


Si j'ai un serveur A sur lequel je peux me connecter avec ma clé ssh et que j'ai la possibilité de "sudo su - otheruser", je perds le transfert de clé, car les variables d'environnement sont supprimées. et le socket n'est lisible que par mon utilisateur d'origine. Existe-t-il un moyen de relier la transmission de clé via "sudo su - otheruser", de manière à pouvoir effectuer des tâches sur un serveur B avec ma clé transférée (git clone et rsync dans mon cas)?

La seule façon dont je puisse penser est d’ajouter ma clé à allowed_keys d’autre utilisateur et de "ssh otheruser @ localhost", mais c’est difficile à 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). 

144
2018-01-28 13:52


origine




Réponses:


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

Mais heureusement sudo est tout à fait configurable: vous pouvez indiquer précisément les variables d’environnement que vous souhaitez conserver grâce au env_keep option de configuration dans /etc/sudoers.

Pour le transfert d’agent, vous devez conserver le SSH_AUTH_SOCK variable d'environnement. Pour ce faire, éditez simplement votre /etc/sudoers fichier de configuration (toujours en utilisant visudo) et régler le env_keep option aux utilisateurs appropriés. Si vous souhaitez que cette option soit définie pour tous les utilisateurs, utilisez la commande Defaults ligne 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 user1La clé publique de est présente dans ~/.ssh/authorized_keys dans user1@serverA et user2@serverB, et serverAde /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

168
2018-03-03 21:24



C'est la bonne réponse, devrait être marquée. - Xealot
Ce seulement fonctionne, si user2 ci-dessus est root! Autrement, user2 SSH_AUTH_SOCK sera configuré correctement, mais le user2 ne sera pas en mesure d'accéder par exemple / tmp / ssh-GjglIJ9337 /. root a cet accès. Donc, cela peut résoudre une partie du problème, mais pas les PO: "et le socket n'est lisible que par mon utilisateur d'origine " - Peter V. Mørch
Defaults>root env_keep+=SSH_AUTH_SOCK Devrait s’assurer qu’il n’avance que lorsque à racine. De toute façon, vous ne voulez pas faire cela à d’autres utilisateurs pour des raisons de sécurité. Mieux vaut exécuter un agent ssh distinct pour autrui et ajouter les clés appropriées. - Paul Schyska
sudo su - ne fonctionne pas pour moi, vraisemblablement il ne peut pas préserver l'environnement parce que ce n'est pas sudo au moment du démarrage du shell. sudo su semble fonctionner. - Alex Fortuna
Je n'ai jamais compris pourquoi les gens utilisent sudo su en tous cas. Si vous avez besoin d'un shell root, c'est ce que sudo -s ou sudo -i est pour. - eaj


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

Cela vous donnera un shell root avec les clés d'origine encore chargées.


54
2018-01-01 15:31



Comme pour le commentaire ci-dessus, cela ne concerne que la question de savoir si vous devenez root, car dans ce cas, il est capable de contourner les autorisations d'accès habituelles sur $ SSH_AUTH_SOCK. - doshea


Permettre autre utilisateur accéder $SSH_AUTH_SOCK fichier et son répertoire, par exemple par une liste de contrôle d'accès correcte, avant de passer à eux. L'exemple suppose 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 aussi pour les utilisateurs non root ;-)


33
2017-11-15 10:58



Rappelez-vous que lorsque vous utilisez cette méthode, les autres personnes connectées en tant que otheruser pouvez également utiliser votre authentification SSH. - gitaarik
Cela fonctionne pour moi sauf que je devais changer "sudo su - otheruser" en "sudo su otheruser" (en enlevant le -). - Charles Finkel
Pourquoi rwx et pas rw (ou r du tout)? - anatoly techtonik
@anatolytechtonik À partir de man 7 unix - sous Linux, la connexion à un socket nécessite des autorisations de lecture et d'écriture sur ce socket. En outre, vous devez disposer des autorisations de recherche (exécuter) et d’écriture sur le répertoire dans lequel vous créez le socket ou uniquement de l’autorisation de recherche (exécuter) lorsque vous vous connectez à ce socket. Donc, dans la réponse ci-dessus, l'autorisation d'exécution sur le socket est redondante. - mixel


J'ai trouvé que cela fonctionne aussi.

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

Comme d'autres l'ont fait remarquer, cela ne fonctionnera pas si l'utilisateur vers lequel vous basculez n'a pas de permission de lecture sur $ SSH_AUTH_SOCK (ce qui correspond à peu près à n'importe quel utilisateur à part root). Vous pouvez contourner ce problème en définissant $ SSH_AUTH_SOCK et le répertoire dans lequel se trouvent les 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 à tous les autres utilisateurs du système l'autorisation d'utiliser votre agent SSH (jusqu'à ce que vous vous déconnectiez). Vous pouvez également pouvoir définir le groupe et modifier les autorisations sur 770, ce qui pourrait être plus sécurisé. Cependant, lorsque j'ai essayé de changer de groupe, j'ai reçu "Opération non autorisée".


16
2018-03-21 00:01



C'est extrêmement risqué. Donner à tous les autres utilisateurs la permission d'utiliser votre agent SSH revient à leur donner toutes vos informations d'identification (et si vous utilisez jamais sudo ou su, leur donner le pouvoir root sur tous les autres utilisateurs du système, ainsi que sur tous les autres systèmes auxquels vous êtes connecté!) . Cela ne doit JAMAIS être fait! - Matija Nalis
Je ne suis pas d'accord avec l'affirmation selon laquelle "cela ne doit JAMAIS être fait!" Il existe de nombreux cas où ce risque est acceptable. Par exemple, une petite équipe où tout le monde a les mêmes autorisations et où vous faites confiance à tous les autres utilisateurs. Cela ne devrait jamais être fait sans comprendre les risques que cela comporte. Mais une fois que ces risques sont compris, il est parfois acceptable. - phylae


Si vous êtes autorisé à sudo su - $USER, alors vous auriez probablement un bon argument pour être autorisé à faire une ssh -AY $USER@localhost au lieu de cela, avec votre clé publique valide dans le répertoire de base de $ USER. Ensuite, votre transfert d'authentification sera effectué avec vous.


6
2018-01-28 14:08



Il a mentionné cela au bas de sa question et a déclaré que ce serait difficile à faire. - Fahad Sadah
C'est probablement la meilleure solution, mais cela devient difficile si $ USER est une vraie personne (tm) - ils peuvent supprimer la clé de la SA de la fonction allowed_keys ou changer leur mot de passe ... - voretaq7
Vous pouvez supprimer leur accès en écriture à authorised_keys (cependant, s'ils sont vraiment configurés pour refuser l'accès à Florian, ils peuvent le supprimer et le recréer, que ce soit dans un répertoire qu'ils possèdent). - Fahad Sadah


Vous pouvez toujours simplement faire ssh sur 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 ponctuel. Cependant, si vous vous déconnectez du serveur, le socket sera (bien sûr) cassé à nouveau. . Ce n’est donc pas idéal si vous ne pouvez pas garder votre session screen / tmux ouverte à tout moment (cependant, vous pouvez mettre à jour manuellement votre SSH_AUTH_SOCKenv var si tu es cool).

Notez également qu'en utilisant 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.


4
2017-11-27 14:56





Ne pas utiliser sudo su - USER, mais plutôt sudo -i -u USER. Travaille pour moi!


3
2018-01-28 16:51



Quelle version de sudo avez-vous? Mine (1.6.7p5, CentOS 4.8) n'a pas de -i dans sa page de manuel. - David Mackintosh
Sudo version 1.6.9p17 en cours d'exécution sur Debian Lenny. Essayer sudo -s? - Fahad Sadah
Ca ne marche pas pour moi
Sur Ubuntu, en utilisant Sudo 1.8.9p5, ni sudo -s ni sudo -i travaille pour moi... - Jon L.


En combinant les informations des autres réponses, je suis arrivé à 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).


2
2018-06-10 17:39