☰

So verwenden Sie einen beliebigen Befehl (z. B. Git) mit den SSH-Schlüsseln eines normalen Benutzers, aber mit Sudo-Dateiberechtigungen

tag-icon • tag-icon files permissions sudo git
So verwenden Sie einen beliebigen Befehl (z. B. Git) mit den SSH-Schlüsseln eines normalen Benutzers, aber mit Sudo-Dateiberechtigungen

Ich kann ein Projekt wie folgt klonen:

$ git clone [email protected]:root/myproject.git ~/bla

Aber jetzt möchte ich es klonen /var/www. Also versuche ich

$ git clone [email protected]:root/myproject.git ~/var/www

Aber leider habe ich keine Schreibberechtigung /var/www. Sudo kommt zur Rettung!

$ sudo git clone [email protected]:root/myproject.git ~/var/www
Cloning into 'www'...
[email protected]'s password:

Was soll das? Ich werde nach einem Passwort gefragt? Wir sollten keine beschissenen Passwörter brauchen!

Ich sende offensichtlich die SSH-Schlüssel des Root-Benutzers mit der Anfrage, und da sie nicht in das Git-Repository importiert wurden, wird mir die Anfrage verweigert. In der Vergangenheit bestand meine Lösung darin, die Berechtigungen des Ordners vorübergehend zu ändern oder ihn zuerst an einen Ort zu klonen, an dem ich Zugriff habe, und ihn dann mit sudo zu verschieben, aber ich möchte lernen, wie das richtig geht.

Also ... wie verwende ich Git mit den SSH-Schlüsseln meines normalen Benutzers, aber mit Sudo-Dateiberechtigungen?

Antwort1

Wenn Sie einen sshAgenten ausführen, gehen Sie wie folgt vor:

sudo SSH_AUTH_SOCK="$SSH_AUTH_SOCK" git clone...

Dies weist den gitvon root(oder dem sshvon diesem Befehl gestarteten Befehl git) grundsätzlich an, Ihren Agenten zu verwenden ssh(wie eine Verbindung zu ihm hergestellt werden kann, was rootmöglich sein sollte, da er dazu alle Rechte hat).

Wenn Sie keinen laufenden SSH-Agenten haben, können Sie vorab einen mit folgendem Befehl starten:

eval "$(ssh-agent)"

(und fügen Sie bei Bedarf mit Schlüssel hinzu ssh-add).

Alternativ können Sie

sudo -E git clone...

BestehenjedenUmgebungsvariable über sudo, nicht nur $SSH_AUTH_SOCK.

Ich würdenichthabe @NgOon-Ees Vorschlag im Kommentar $SSH_AUTH_SOCKzur env_keepListe hinzugefügt. Im Allgemeinen möchten Sie rootdie Umgebung von nicht verunreinigen, da dies der Benutzer ist, als der Sie Dienste starten. Wenn Sie beispielsweise sudo sshdeinen Dienst starten, würden sshdalle sshüber diesen Dienst gestarteten Sitzungen Ihre erben $SSH_AUTH_SOCKund die Umgebung der Benutzer mit etwas verunreinigen, das sie nicht verwenden können und sollten. Selbst für andere Zielbenutzer als rootwäre die Weitergabe dieser Variable nicht sinnvoll, da der Zielbenutzer diesen Authentifizierungsagenten nicht verwenden könnte.

Damit ist nur die Schlüsselauthentifizierung angesprochen. Wenn Sie rootIhre Einstellungen auch in Ihrem übernehmen möchten, können Sie das nicht mit Umgebungsvariablen ~/.ssh/configtun , aber Sie können das mit Umgebungsvariablen tun. Zum Beispiel können Sie eine Funktion wie folgt definieren:sshgitsugit

sugit() {
  sudo "GIT_SSH_COMMAND=
    exec ssh -o IdentityAgent='$SSH_AUTH_SOCK' \
             -o User=$LOGNAME \
             -F ~$LOGNAME/.ssh/config" git "$@"
}

Das heißt, weisen Sie an, giteinen sshBefehl zu verwenden, der Ihre SSH-Konfigurationsdatei, Ihren Agenten und Ihren Benutzernamen anstelle von Root verwendet.

Oder noch besser: Geben Sie an, gitdass die Ausführung sshals ursprünglicher Benutzer erfolgen soll:

sugit() {
  sudo "GIT_SSH_COMMAND=
    exec sudo -Hu $LOGNAME SSH_AUTH_SOCK='$SSH_AUTH_SOCK' ssh" git "$@"
}

Antwort2

Datei- (oder Socket-)Berechtigungen können kompliziert sein, wenn die Schlüsseldateien (oder der Socket) vom Benutzer, der sie sudoausführt, nicht gelesen werden können. Dies gilt insbesondere, rootwenn sich die Dateien auf einer Netzwerkfreigabe befinden, rootfür die keine Berechtigung vorliegt, oder wenn das Home-Verzeichnis verschlüsselt ist, was rootden Zugriff ebenfalls verweigern kann.

Auf Unix-Systemen, die erweiterte ACLs unterstützen, können Sie diese auch verwenden. In diesem Fall können Sie zusätzlich zu den üblichen Basisberechtigungen weiteren Schreibzugriff gewähren:

$ sudo chown apache:www /var/www/html
$ sudo chmod g+s /var/www/html
$ sudo setfacl -m g:webedit:rwx /var/www/html
$ groups
jdoe webedit
$ ls -ld /var/www/html
drwxrwsr-x+ 4 apache www 25 Nov 21 19:42 /var/www/html
$

aber die webeditGruppe hat Berechtigungen dank dersetfacl

$ git clone ~/repo /var/www/html
Cloning into '/var/www/html'...
done.
$ ls -al /var/www/html
total 0
drwxrwsr-x+ 4 apache www   25 Nov 21 19:42 .
drwxr-xr-x  4 root   root  31 Oct 19 20:39 ..
drwxrwsr-x  3 jdoe   www   14 Nov 21 19:42 a
drwxrwsr-x  8 jdoe   www  152 Nov 21 19:42 .git
$

Es gibt jedoch verschiedene Fallstricke bei erweiterten ACLs. Überprüfen Sie beispielsweise, wie Ihre Backup-Software damit umgeht usw.

verwandte Informationen