%20con%20las%20claves%20ssh%20de%20un%20usuario%20normal%20pero%20con%20permisos%20de%20archivo%20sudo.png)
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 ssh
agente ejecutándose, haga:
sudo SSH_AUTH_SOCK="$SSH_AUTH_SOCK" git clone...
Básicamente, eso le dice al git
comando iniciado por root
(o al ssh
comando iniciado por ese git
comando) que use su ssh
agente (cómo conectarse a él, que root
deberí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_SOCK
a la env_keep
lista. En general, no desea contaminar root
el medio ambiente, ya que ese es el usuario con el que inicia los servicios. Por ejemplo, sudo sshd
iniciar un sshd
servicio significaría que todas ssh
las sesiones iniciadas a través de ese servicio heredarían su $SSH_AUTH_SOCK
entorno 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 root
heredar su configuración en su ~/.ssh/config
, no podría hacerlo con ssh
variables de entorno, pero podría hacerlo con git
variables de entorno. Por ejemplo, definir una sugit
funció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 git
que use un ssh
comando 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 git
que se ejecute ssh
como 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 sudo
que ejecuta no puede leer los archivos clave (o sockets). Esto definitivamente incluye root
si los archivos residen en un recurso compartido de red que root
no tiene permiso, o si el directorio de inicio debe estar cifrado, lo que nuevamente puede denegar root
el 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 webedit
grupo 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.