Pregunta ssh-agent reenvío y sudo a otro usuario


Si tengo un servidor A en el que puedo iniciar sesión con mi clave ssh y tengo la capacidad de "sudo su - otheruser", pierdo el reenvío de clave, porque las variables env se eliminan y el socket solo es legible por mi usuario original. ¿Hay alguna manera de poder unir el reenvío de claves a través del "sudo su - otheruser", así que puedo hacer cosas en un servidor B con mi clave reenviada (git clone y rsync en mi caso)?

La única forma en que puedo pensar es agregar mi clave a authorized_keys de otheruser y "ssh otheruser @ localhost", pero es una tarea complicada para cada combinación de usuario y servidor que pueda tener.

En breve:

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

144
2018-01-28 13:52


origen




Respuestas:


Como mencionaste, las variables de entorno son eliminadas por sudo, por razones de seguridad.

Pero afortunadamente sudo es bastante configurable: puede decirle con precisión qué variables de entorno desea mantener gracias a la env_keep opción de configuración en /etc/sudoers.

Para el reenvío de agente, debe mantener el SSH_AUTH_SOCK Variable ambiental. Para hacerlo, simplemente edita tu /etc/sudoers archivo de configuración (siempre usando visudo) y establece el env_keep Opción a los usuarios adecuados. Si desea que esta opción se establezca para todos los usuarios, use la Defaults línea como esta:

Defaults    env_keep+=SSH_AUTH_SOCK

man sudoers para más detalles.

Ahora debería poder hacer algo como esto (siempre que user1La clave pública está presente en ~/.ssh/authorized_keys en user1@serverA y user2@serverBy serverAes /etc/sudoers el archivo se configura como se indica arriba):

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

168
2018-03-03 21:24



Esta es la respuesta correcta, debe estar marcada. - Xealot
Esta solamente trabaja, si user2 arriba es root! De otra manera, user2 tendrá SSH_AUTH_SOCK configurado correctamente, pero el user2 no podrá acceder por ej. / tmp / ssh-GjglIJ9337 /. root tiene ese acceso Así que esto puede resolver parte del problema, pero no los OP: "y el socket solo es legible por mi usuario original " - Peter V. Mørch
Defaults>root env_keep+=SSH_AUTH_SOCK Debe asegurarse de que sólo se reenvía al sudoing a raíz. No quiere hacer eso de todos modos a otros usuarios por razones de seguridad. Mejor ejecute un ssh-agent separado para otro, y agregue las claves apropiadas. - Paul Schyska
sudo su - no funciona para mí, probablemente no puede preservar el medio ambiente porque no lo es sudo en el momento de inicio de shell. sudo su parece funcionar. - Alex Fortuna
Nunca he entendido por qué la gente usa sudo su de todas formas. Si necesitas una shell de root, eso es lo que sudo -s o sudo -i es para. - eaj


sudo -E -s
  • -E preservará el medio ambiente
  • -s ejecuta un comando, por defecto a un shell

Esto te dará un shell de root con las claves originales aún cargadas.


54
2018-01-01 15:31



Al igual que con el comentario anterior, esto solo responde a la pregunta si te estás convirtiendo en root, porque en ese caso root puede sortear los permisos de acceso habituales en el $ SSH_AUTH_SOCK. - doshea


Permitir otro usuario acceder $SSH_AUTH_SOCK archivo y su directorio, por ejemplo, mediante ACL correcta, antes de cambiar a ellos. El ejemplo asume Defaults:user env_keep += SSH_AUTH_SOCK en /etc/sudoers en la máquina host:

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

Más seguro y también funciona para usuarios no root ;-)


33
2017-11-15 10:58



Recuerde que al usar este método, otras personas que iniciaron sesión como otheruser También puede utilizar su autenticación ssh. - gitaarik
Esto funciona para mí, excepto que tuve que cambiar "sudo su - otheruser" a "sudo su otheruser" (eliminando el -). - Charles Finkel
Por qué rwx y no rw (o r en absoluto)? - anatoly techtonik
@anatolytechtonik De man 7 unix - en Linux, la conexión a un socket requiere permisos de lectura y escritura en ese socket. También necesita buscar (ejecutar) y permiso de escritura en el directorio donde crea el socket o solo buscar (ejecutar) el permiso cuando se conecta a este socket. Entonces, en la respuesta anterior, el permiso de ejecución en el socket es redundante. - mixel


He encontrado que esto también funciona.

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

Como han señalado otros, esto no funcionará si el usuario al que está cambiando no tiene permisos de lectura en $ SSH_AUTH_SOCK (que es prácticamente cualquier usuario que no sea root). Puede solucionar esto configurando $ SSH_AUTH_SOCK y el directorio en el que se encuentra para tener los permisos 777.

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

Aunque esto es bastante arriesgado. Básicamente, le está dando permiso a todos los demás usuarios del sistema para usar su Agente SSH (hasta que cierre sesión). También puede configurar el grupo y cambiar los permisos a 770, lo que podría ser más seguro. Sin embargo, cuando intenté cambiar el grupo, obtuve "Operación no permitida".


16
2018-03-21 00:01



Esto es extremadamente arriesgado. Darle permiso a todos los demás usuarios para usar su agente de SSH es equivalente a darles todas sus credenciales (y si alguna vez usa sudo o su, déles el poder de root sobre todos los demás usuarios del sistema, ¡como también a todos los demás sistemas a los que pueda acceder!) . ¡NUNCA se debe hacer NUNCA! - Matija Nalis
No estoy de acuerdo con la afirmación de que "¡Esto NUNCA debe hacerse NUNCA!" Hay muchos casos donde este riesgo es aceptable. Por ejemplo, un pequeño equipo donde todos tienen los mismos permisos y confías en todos los demás usuarios. Nunca debe hacerse sin comprender los riesgos que implica. Pero una vez que se entienden esos riesgos, hay ocasiones en que el riesgo es aceptable. - phylae


Si estás autorizado para sudo su - $USER, entonces es probable que tenga un buen argumento para que le permitan hacer una ssh -AY $USER@localhost en su lugar, con su clave pública válida en el directorio principal de $ USER. Entonces su reenvío de autenticación se llevará a cabo con usted.


6
2018-01-28 14:08



Mencionó eso al final de su pregunta y dijo que sería difícil de hacer. - Fahad Sadah
Esta es probablemente la mejor solución, pero se vuelve difícil si $ USER es una persona real (tm); podrían eliminar la clave de SA de authorized_keys o cambiar su contraseña ... - voretaq7
Puede eliminar su acceso de escritura a authorized_keys (aunque si realmente están configurados para denegar el acceso a Florian, pueden eliminarlo y volver a crearlo, ya que está en un directorio que posee) - Fahad Sadah


Siempre puede simplemente ssh a localhost con reenvío de agente en lugar de usar sudo:

ssh -A otheruser@localhost

La desventaja es que necesita iniciar sesión nuevamente, pero si lo está usando en una pestaña de pantalla / tmux, eso es solo un esfuerzo, sin embargo, si se desconecta del servidor, el zócalo se volverá a romper (por supuesto) . Por lo tanto, no es ideal si no puede mantener su sesión de pantalla / tmux abierta en todo momento (sin embargo, puede actualizar manualmente su SSH_AUTH_SOCKenv var si eres cool).

También tenga en cuenta que al usar el reenvío ssh, la raíz siempre puede acceder a su socket y usar su autenticación ssh (siempre que haya iniciado sesión con el reenvío ssh). Así que asegúrese de que puede confiar en la raíz.


4
2017-11-27 14:56





No usar sudo su - USERpero mas bien sudo -i -u USER. ¡Funciona para mi!


3
2018-01-28 16:51



¿Qué versión de sudo tienes? Mine (1.6.7p5, CentOS 4.8) no tiene -i en su página de manual. - David Mackintosh
Sudo version 1.6.9p17 corriendo en debian lenny Tratar sudo -s? - Fahad Sadah
No funciona para mi
En Ubuntu, usando Sudo 1.8.9p5, tampoco sudo -s ni sudo -i trabaja para mi... - Jon L.


Combinando información de las otras respuestas se me ocurrió esto:

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

Me gusta esto porque no necesito editar sudoers expediente.

Probado en Ubuntu 14.04 (tuvo que instalar acl paquete).


2
2018-06-10 17:39





Desafortunadamente, cuando se someta a otro usuario (o incluso use sudo) perderá la capacidad de usar sus claves reenviadas. Esta es una característica de seguridad: no desea que usuarios aleatorios se conecten a su agente ssh y utilicen sus teclas :)

El método "ssh -Ay $ {USER} @localhost" es un poco engorroso (y como se señala en mi comentario sobre la respuesta de David propenso a la rotura), pero es probablemente lo mejor que puedes hacer.


1
2018-01-28 16:52



Hmm, pero si hago esto con ssh, mi agente podrá acceder a mi agente de todas formas, ¿o me equivoco?
Si ingresa SSH en el usuario objetivo con el agente que reenvía sus solicitudes de agente, la cadena rebotará hasta donde sea que se encuentre el agente "real". Cuando se encuentre fuera del usuario original, su socket de agente SSH no será (o no debería) accesible: el directorio en el que se encuentra es el modo 700 y es propiedad del usuario original. (Advertencia obvia: si está cambiando a root y reinicie el entorno SSH_AUTH_SOCK, podría funcionar, pero no confiaría en él) - voretaq7
En mi servidor (Ubuntu 12.04, versión ssh OpenSSH_5.9p1 Debian-5ubuntu1.1, OpenSSL 1.0.1 14 de marzo de 2012), ssh tiene -a y -A argumentos -a hace exactamente lo contrario de lo que se pretende, deshabilita el reenvío de agentes! Entonces, bajo la versión reciente (y posiblemente toda) de Ubuntu, use -A para habilitar el reenvío de agentes. - knite
@knite Tienes razón, ¡es un error tipográfico (de 3 años!) en mi respuesta. Arreglado ahora :-) - voretaq7