☰

SSH-Agent-Weiterleitung und Sudo an einen anderen Benutzer

tag-icon • tag-icon ssh sudo forwarding ssh-agent agent
SSH-Agent-Weiterleitung und Sudo an einen anderen Benutzer

Wenn ich einen Server A habe, bei dem ich mich mit meinem SSH-Schlüssel anmelden kann und die Möglichkeit habe, "sudo su - otheruser" auszuführen, verliere ich die Schlüsselweiterleitung, da die Umgebungsvariablen entfernt werdenUndder Socket ist nur für meinen ursprünglichen Benutzer lesbar. Gibt es eine Möglichkeit, die Schlüsselweiterleitung durch „sudo su - otheruser“ zu überbrücken, sodass ich mit meinem weitergeleiteten Schlüssel Dinge auf einem Server B tun kann (in meinem Fall git clone und rsync)?

Die einzige Möglichkeit, die mir einfällt, besteht darin, meinen Schlüssel zu den autorisierten Schlüsseln von otheruser und „ssh otheruser@localhost“ hinzuzufügen, aber das ist für jede mögliche Benutzer- und Serverkombination mühsam.

Zusamenfassend:

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

Antwort1

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

Aber glücklicherweise ist es ziemlich konfigurierbar: Dank der Konfigurationsoption in sudokönnen Sie genau angeben, welche Umgebungsvariablen Sie behalten möchten .env_keep/etc/sudoers

Für die Agentenweiterleitung müssen Sie die SSH_AUTH_SOCKUmgebungsvariable beibehalten. Bearbeiten Sie dazu einfach Ihre /etc/sudoersKonfigurationsdatei (immer mit visudo) und legen Sie die env_keepOption für die entsprechenden Benutzer fest. Wenn Sie möchten, dass diese Option für alle Benutzer festgelegt wird, verwenden Sie die Defaultsfolgende Zeile:

Defaults    env_keep+=SSH_AUTH_SOCK

man sudoersfür mehr Details.

Sie sollten jetzt in der Lage sein, etwa Folgendes zu tun (vorausgesetzt, user1der öffentliche Schlüssel von ist in und vorhanden ~/.ssh/authorized_keysund user1@serverAdie user2@serverBDatei serverAvon /etc/sudoersist 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

Antwort2

sudo -E -s
  • -E wird die Umwelt schützen
  • -s führt einen Befehl aus, standardmäßig eine Shell

Dadurch erhalten Sie eine Root-Shell mit den noch geladenen Originalschlüsseln.

Antwort3

ErlaubenandererBenutzerum auf $SSH_AUTH_SOCKdie Datei und ihr Verzeichnis zuzugreifen, beispielsweise durch die richtige ACL, bevor zu ihnen gewechselt wird.

Das Beispiel geht Defaults:user env_keep += SSH_AUTH_SOCKvon /etc/sudoerseiner Host-Maschine aus:

$ 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

Antwort4

Sie können jederzeit einfach per SSH mit Agent-Weiterleitung auf den lokalen Host zugreifen, anstatt sudo zu verwenden:

ssh -A otheruser@localhost

Der Nachteil ist, dass Sie sich erneut anmelden müssen, aber wenn Sie es in einem Screen/Tmux-Tab verwenden, ist das nur ein einmaliger Aufwand. Wenn Sie jedoch die Verbindung zum Server trennen, wird der Socket (natürlich) erneut unterbrochen. Es ist also nicht ideal, wenn Sie Ihre Screen/Tmux-Sitzung nicht immer offen halten können (Sie können Ihre SSH_AUTH_SOCKUmgebungsvariable jedoch manuell aktualisieren, wenn Sie damit einverstanden sind).

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

verwandte Informationen