Weiterleitung von ssh-agent und sudo an einen anderen Benutzer

Wenn ich einen Server A habe, in den ich mich mit meinem SSH-Schlüssel einloggen kann und die Fähigkeit habe, "sudo su-otheruser" zu verwenden, verliere ich die Schlüsselweiterleitung, da die env-Variablen entfernt werden und der Socket nur von meinem ursprünglichen Benutzer gelesen werden kann . Gibt es eine Möglichkeit, die Schlüsselweiterleitung über den "sudo su - otheruser" zu überbrücken, damit ich mit meinem weitergeleiteten Schlüssel (in meinem Fall git clone und rsync) Dinge auf einem Server B erledigen kann?

Ich kann mir nur vorstellen, meinen Schlüssel zu authorized_keys von otheruser und "ssh otheruser @ localhost" hinzuzufügen, aber das ist umständlich für jede Benutzer- und Serverkombination, die ich habe.

Zusamenfassend:

$ sudo -HE ssh user@host
(success)
$ sudo -HE -u otheruser ssh user@host
Permission denied (publickey). 

Wie Sie bereits erwähnt haben, werden die Umgebungsvariablen sudoaus Sicherheitsgründen von entfernt.

Aber zum Glück sudoist es durchaus konfigurierbar: Sie können ihm dank der env_keepKonfigurationsoption in genau mitteilen, welche Umgebungsvariablen Sie behalten möchten /etc/sudoers.

Für die Agentenweiterleitung müssen Sie die SSH_AUTH_SOCKUmgebungsvariable beibehalten. Bearbeiten Sie dazu einfach Ihre /etc/sudoersKonfigurationsdatei (immer verwenden visudo) und stellen Sie die env_keepOption auf die entsprechenden Benutzer ein. Wenn Sie möchten, dass diese Option für alle Benutzer festgelegt wird, verwenden Sie die folgende DefaultsZeile:

Defaults    env_keep+=SSH_AUTH_SOCK

man sudoers für mehr Details.

Sie sollten nun in der Lage sein, so etwas zu tun (vorausgesetzt user1, der öffentliche Schlüssel ist ~/.ssh/authorized_keysin user1@serverAund vorhanden user2@serverBund serverAdie /etc/sudoersDatei ist wie oben angegeben eingerichtet):

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 schont die Umwelt
• -s führt einen Befehl aus, standardmäßig eine Shell

Dadurch erhalten Sie eine Root-Shell, in der die Originalschlüssel noch geladen sind.

Ermöglichen Sie anderen Benutzern den Zugriff auf $SSH_AUTH_SOCKDateien und deren Verzeichnis, z. B. durch korrekte Zugriffssteuerungsliste , bevor Sie zu ihnen wechseln. Das Beispiel geht davon Defaults:user env_keep += SSH_AUTH_SOCKin /etc/sudoersauf dem Host - Maschine:

$ 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$

Sicherer und funktioniert auch für Nicht-Root-Benutzer ;-)

Ich habe festgestellt, dass das auch funktioniert.

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

Wie andere angemerkt haben, funktioniert dies nicht, wenn der Benutzer, zu dem Sie wechseln, keine Leseberechtigung für $ SSH_AUTH_SOCK hat (was so ziemlich jeder Benutzer außer root ist). Sie können dies umgehen, indem Sie $ SSH_AUTH_SOCK und das Verzeichnis festlegen, in dem es die Berechtigungen 777 haben soll.

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

Das ist allerdings ziemlich riskant. Grundsätzlich erteilen Sie jedem anderen Benutzer im System die Erlaubnis, Ihren SSH-Agenten zu verwenden (bis Sie sich abmelden). Möglicherweise können Sie auch die Gruppe festlegen und die Berechtigungen auf 770 ändern, was möglicherweise sicherer ist. Als ich jedoch versuchte, die Gruppe zu wechseln, wurde die Meldung "Operation nicht zulässig" angezeigt.

Wenn Sie dazu berechtigt sind sudo su - $USER, haben Sie wahrscheinlich ein gutes Argument dafür, ssh -AY $USER@localhoststattdessen einen mit Ihrem gültigen öffentlichen Schlüssel im Home-Verzeichnis von $ USER ausführen zu dürfen. Dann wird Ihre Authentifizierungsweiterleitung mit Ihnen durchgeführt.

Sie können immer nur ssh an localhost mit Agent-Weiterleitung senden, anstatt sudo zu verwenden:

ssh -A otheruser@localhost

Nachteil ist, dass Sie sich erneut anmelden müssen, aber wenn Sie es in einem Screen / TMUX-Tab verwenden, ist dies nur ein einmaliger Aufwand. Wenn Sie jedoch die Verbindung zum Server trennen, wird der Socket (natürlich) wieder unterbrochen . Daher ist es nicht ideal, wenn Sie Ihren Bildschirm / Ihre tmux-Sitzung nicht immer offen halten können (Sie können jedoch Ihre SSH_AUTH_SOCKenv var manuell aktualisieren, wenn Sie cool sind).

Beachten Sie auch, dass Root bei Verwendung der SSH-Weiterleitung immer auf Ihren Socket zugreifen und Ihre SSH-Authentifizierung verwenden kann (sofern Sie mit SSH-Weiterleitung angemeldet sind). Stellen Sie also sicher, dass Sie root vertrauen können.

Verwenden Sie nicht sudo su - USER, sondern sudo -i -u USER. Funktioniert bei mir!

Kombiniere Informationen aus den anderen Antworten, die mir eingefallen sind:

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

Ich mag das, weil ich keine sudoersDatei bearbeiten muss .

Getestet auf Ubuntu 14.04 (musste aclPaket installieren ).

Ich denke, es gibt ein Problem mit der -(Bindestrich) -Option nach suin Ihrem Befehl:

sudo su - otheruser

Wenn Sie die Manpage von su lesen , werden Sie möglicherweise feststellen, dass die Option -, -l, --logindie Shell-Umgebung als Login-Shell startet. Dies wird die Umgebung für otheruserunabhängig von den Umgebungsvariablen , in denen Sie ausgeführt werden su.

Einfach ausgedrückt, untergräbt der Strich alles, was Sie passiert haben sudo.

Versuchen Sie stattdessen diesen Befehl:

sudo -E su otheruser

Wie @ joao-costa hervorhob, -Ewerden alle Variablen in der Umgebung, in der Sie ausgeführt haben, beibehalten sudo. Dann ohne den Bindestrich suwird diese Umgebung direkt verwendet.

Wenn Sie sich an einen anderen Benutzer wenden (oder sogar sudo verwenden), verlieren Sie leider die Möglichkeit, Ihre weitergeleiteten Schlüssel zu verwenden. Dies ist eine Sicherheitsfunktion: Sie möchten nicht, dass zufällige Benutzer eine Verbindung zu Ihrem ssh-agent herstellen und Ihre Schlüssel verwenden :)

Die Methode "ssh-Ay $ {USER} @localhost" ist etwas umständlich (und wie in meinem Kommentar zu Davids Antwort erwähnt, die zu Brüchen neigt), aber wahrscheinlich die beste, die Sie tun können.