☰

Reenvío de agente ssh y sudo a otro usuario

tag-icon • tag-icon ssh sudo forwarding ssh-agent agent
Reenvío de agente ssh 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 eliminanyel socket solo es legible por mi usuario original. ¿Hay alguna manera de puentear el reenvío de claves a través de "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 que se me ocurre es agregar mi clave a las claves_autorizadas de otro usuario y "ssh otrousuario@localhost", pero eso es complicado de hacer 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).

Respuesta1

Como mencionó, las variables de entorno se eliminan sudopor razones de seguridad.

Pero, afortunadamente, sudoes bastante configurable: puedes indicarle con precisión qué variables de entorno deseas conservar gracias a la env_keepopción de configuración en /etc/sudoers.

Para el reenvío de agentes, debe mantener la SSH_AUTH_SOCKvariable de 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 esté configurada para todos los usuarios, use una Defaultslínea como esta:

Defaults    env_keep+=SSH_AUTH_SOCK

man sudoerspara más detalles.

Ahora debería poder hacer algo como esto (siempre que user1la clave pública de esté presente en ~/.ssh/authorized_keysy user1@serverAy user2@serverBel serverAarchivo /etc/sudoersesté 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

Respuesta2

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.

Respuesta3

Permitirotro usuariopara acceder $SSH_AUTH_SOCKal archivo y su directorio, por ejemplo mediante la ACL correcta, antes de cambiar a ellos.

El ejemplo asume Defaults:user env_keep += SSH_AUTH_SOCKen /etc/sudoersla 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

Respuesta4

Siempre puedes simplemente enviar 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 de una vez; sin embargo, si se desconecta del servidor, el socket (por supuesto) se romperá nuevamente. . Por lo tanto, no es ideal si no puede mantener abierta su sesión de pantalla/tmux en todo momento (sin embargo, puede actualizar manualmente su SSH_AUTH_SOCKvar env si está bien).

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

información relacionada