Cómo usar cualquier comando (como git) con las claves ssh de un usuario normal pero con permisos de archivo sudo

Cómo usar cualquier comando (como git) con las claves ssh de un usuario normal pero con permisos de archivo sudo

Puedo clonar un proyecto de la siguiente manera:

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

Pero ahora deseo clonarlo /var/www. entonces lo intento

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

Pero, por desgracia, no tengo permiso para escribir /var/www. ¡Sudo al rescate!

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

¿Qué es esto? ¿Me piden una contraseña? ¡No deberíamos necesitar contraseñas apestosas!

Obviamente estoy enviando las claves ssh del usuario root con la solicitud y, como no se han importado al repositorio de git, se me niega. En el pasado, mi solución ha sido cambiar temporalmente los permisos de la carpeta o clonarla primero en algún lugar al que tenga acceso y luego moverla usando sudo, pero me gustaría aprender la forma correcta de hacerlo.

Entonces... ¿Cómo uso git con las claves ssh de mi usuario normal pero con permisos de archivos sudo?

Respuesta1

Si tiene un sshagente ejecutándose, haga:

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

Básicamente, eso le dice al gitcomando iniciado por root(o al sshcomando iniciado por ese gitcomando) que use su sshagente (cómo conectarse a él, que rootdebería poder hacerlo, ya que tiene todos los derechos).

Si no tiene un agente ssh en ejecución, puede iniciar uno de antemano con:

eval "$(ssh-agent)"

(y agréguele claves según sea necesario con ssh-add).

Alternativamente, puedes usar

sudo -E git clone...

Pasarcadavariable de entorno en todo sudo, no solo $SSH_AUTH_SOCK.

me gustaríanoRecibí la sugerencia de @ NgOon-Ee en el comentario para agregarlo $SSH_AUTH_SOCKa la env_keeplista. En general, no desea contaminar rootel medio ambiente, ya que ese es el usuario con el que inicia los servicios. Por ejemplo, sudo sshdiniciar un sshdservicio significaría que todas sshlas sesiones iniciadas a través de ese servicio heredarían su $SSH_AUTH_SOCKentorno de usuario contaminante con algo que no pueden ni deben usar. Incluso para otros usuarios de destino distintos de root, pasar esa variable no tendría sentido ya que el usuario de destino no podría utilizar ese agente de autenticación.

Ahora, eso sólo aborda la autenticación de claves. Si también quisiera rootheredar su configuración en su ~/.ssh/config, no podría hacerlo con sshvariables de entorno, pero podría hacerlo con gitvariables de entorno. Por ejemplo, definir una sugitfunción como:

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

Es decir, indique gitque use un sshcomando que use su archivo de configuración ssh, su agente y su nombre de usuario en lugar de los de root.

O tal vez incluso mejor, indique gitque se ejecute sshcomo el usuario original:

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

Respuesta2

Los permisos de archivos (o sockets) pueden ser complicados si el usuario sudoque ejecuta no puede leer los archivos clave (o sockets). Esto definitivamente incluye rootsi los archivos residen en un recurso compartido de red que rootno tiene permiso, o si el directorio de inicio debe estar cifrado, lo que nuevamente puede denegar rootel acceso.

Otra forma en los sistemas Unix que admiten ACL extendidas es usarlas, en cuyo caso puede otorgar acceso de escritura adicional además de los permisos básicos habituales:

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

pero el webeditgrupo tiene permisos gracias alsetfacl

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

Sin embargo, existen varios errores en torno a las ACL extendidas, por ejemplo, comprobar cómo las maneja su software de copia de seguridad, etc.

información relacionada