Considere el siguiente escenario:
He iniciado sesión en el servidor A como usuario "común". La clave sobrecomún usuario es que un grupo de personas tiene acceso a él; no tiene restricciones y no es seguro por diseño.
Digamos que periódicamente necesito iniciar sesión desde este usuario/servidor paraservidorBcomo usuarioseguro- es decir, necesito escanear archivos propiedad deseguro@servidorB.
Si bien tengo pleno acceso y control sobresegurousuario, ciertamente no quiero agregarcomúnde la clave pública a claves confiables parasegurousuario: no quiero que nadie pueda iniciar sesión comocomúnpara poder iniciar sesión comosegurotambién.
Tampoco quiero escribirseguroLa contraseña de 5 veces por hora. Idealmente, me gustaría escribirlo una vez, que algún agente lo recuerde mágicamente, pero solo para esta sesión de inicio de sesión, y luego usarlo cada vez que me conecte desde esta sesión hasta que expire el tiempo de espera. kinitEn realidad, no muy diferente .
¿Existe algo que pueda lograr este objetivo?
Respuesta1
No es tan fácil si tiene un usuario compartido en un servidor intermedio y ese usuario tiene acceso de shell, ya que casi todo lo que hay allí es accesible de forma predeterminada para cada otra sesión.
Por supuesto, hay formas en los núcleos modernos.
O bien podría haber una herramienta que utilice conjuntos de claves de sesión (proceso/hilo) para almacenar los datos privados en el kernel o probablemente el sistema pueda hacerse lo suficientemente seguro como para no permitir que los diferentes procesos del mismo usuario accedan entre sí para que un programa pueda mantener la seguridad. información de autenticación también en la memoria del espacio de usuario normal protegida de otras sesiones. De todos modos, ambos tuvieron que identificar solicitudes para realizar la autenticación basándose en cierta información PID/SID que funcionará para un uso básico. Al final, necesita un demonio que configure la sesión por usted o entregue las contraseñas almacenadas a su proceso para que pueda usarla con la herramienta sshpass o similar.
Otro enfoque es utilizar espacios de nombres y montar un tmpfs o tmpdir privado (mientras que tmpfs está mejor protegido o al menos es menos accesible para los usuarios root que tmpdir).
Podría usar sshd en un puerto separado con un contenedor que configure el entorno del espacio de nombres para ese usuario, o al menos más fácilmente en un sistema moderno. Puede usar pam y pam_namespace.so para configurar un usuario privado tmpdir o tmpfs. Allí podría almacenar su contraseña en texto sin cifrar para que la utilice sshpass o algo así o, mejor aún, podría colocar el socket para ssh-agent en ese directorio y cargar su clave privada personal en ese agente mientras garantiza que el acceso al agente esté protegido del acceso por otras sesiones del mismo usuario. Si tiene una clave privada con una contraseña segura, también puede almacenarla en la máquina. De lo contrario, tuviste que transferirlo. También puede hacer que todo el directorio /tmp sea un directorio privado (posiblemente con algunos subdirectorios compartidos) y utilizar el reenvío del agente SSH de una manera bastante segura (realmente no puede protegerlo para que el usuario root abuse de él, pero al menos si usa tmpfs es difícil para el root y no es posible para un usuario normal utilizar Auth-Sock).
De todos modos, debe poder configurar el servidor lo suficiente o debe configurarse lo suficiente, al menos hasta el punto de que los procesos de los usuarios no puedan conectarse entre sí.
Respuesta2
Probablemente estés buscandossh-agent, que viene con OpenSSH. Utilice la -topción para establecer un tiempo de espera.