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 claves, porque las variables env se eliminan y el usuario original solo puede leer el socket. ¿Hay alguna forma de que pueda unir el reenvío de claves a través del "sudo su - otheruser", para poder 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 las claves autorizadas de otheruser y "ssh otheruser @ localhost", pero eso es engorroso 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). 

Como mencionó, las variables de entorno se eliminan por sudorazones de seguridad.

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

Para el reenvío de agentes, debe mantener SSH_AUTH_SOCKvariable el entorno. Para hacerlo, simplemente edite su /etc/sudoersarchivo de configuración (siempre usando visudo) y configure la env_keepopción para los usuarios apropiados. Si desea que esta opción se configure para todos los usuarios, use la Defaultslí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 ~/.ssh/authorized_keysen user1@serverAy user2@serverB, y serverAel /etc/sudoersarchivo esté configurado como se indicó anteriormente):

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

sudo -E -s

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

Esto le dará un shell raíz con las claves originales aún cargadas.

Permita que otro usuario acceda al $SSH_AUTH_SOCKarchivo y su directorio, por ejemplo, mediante la ACL correcta, antes de cambiar a ellos. El ejemplo asume Defaults:user env_keep += SSH_AUTH_SOCKen la /etc/sudoersmá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 funciona también para usuarios no root ;-)

He descubierto que esto también funciona.

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

Como otros han señalado, esto no funcionará si el usuario al que se está cambiando no tiene permisos de lectura en $ SSH_AUTH_SOCK (que es prácticamente cualquier usuario además de root). Puede evitar esto estableciendo $ 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"

Sin embargo, 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 la 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".

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

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á utilizando en una pestaña screen / tmux, eso es solo un esfuerzo de una vez, sin embargo, si se desconecta del servidor, el socket se romperá (por supuesto) nuevamente . Por lo tanto, no es ideal si no puede mantener su sesión screen / tmux abierta en todo momento (sin embargo, puede actualizar manualmente su SSH_AUTH_SOCKenv var si es genial).

También tenga en cuenta que cuando usa el reenvío ssh, el root 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 poder confiar en la raíz.

No lo uses sudo su - USER, sino más bien sudo -i -u USER. ¡Funciona para mi!

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 el sudoersarchivo.

Probado en Ubuntu 14.04 (tuvo que instalar el aclpaquete).

Creo que hay un problema con la -opción (guión) después sude su comando:

sudo su - otheruser

Si lee la página de manual de su , puede encontrar que la opción -, -l, --logininicia el entorno de shell como shell de inicio de sesión. Este será el entorno otheruserindependientemente de las variables env donde se ejecute su.

En pocas palabras, el tablero socavará cualquier cosa de la que haya pasado sudo.

En su lugar, deberías probar este comando:

sudo -E su otheruser

Como señaló @ joao-costa, -Epreservará todas las variables en el entorno donde se ejecutó sudo. Luego, sin el tablero, suutilizará ese entorno directamente.

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

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