Hay algunas breves discusiones sobre la ssh-agent -tcaracterística existente en [1], y hubo una publicación ya en 2001 sobre debian-devel [2] que deseaba una característica de tiempo de espera de inactividad. Hay una discusión similar aquí en SE [3] para el concurso.
Tengo que preguntarme cómo el resto del planeta está protegiendo las teclas ssh: ¿me estoy perdiendo algo obvio para que esto sea un punto tan doloroso para mí, y aparentemente nadie más? Específicamente estoy pensando en interacciones ssh con scripts, como con ansible. Parece que hoy, sus opciones son:
- Establezca la vida útil de su clave en el agente en un período de tiempo preocupantemente largo, por ej. 1h o lo que el tiempo máximo de secuencias de comandos se ejecuta puede pasar a ser (dudo que muchas personas permiten que su tiempo de espera sudo re-autenticación al estiramiento tanto tiempo!) - pero
seahorse/gnome-keyring-daemonapenas si admite esta cantidad [4] - Cuide sus scripts de larga duración y vuelva a ingresar su frase de contraseña cada 5/10/15 minutos: ahora puede ser visto fácilmente ingresando su frase de contraseña 20 veces al día
- Hackea tu propia solución casera para imitar esta característica que falta, tal vez junto con la shell de
TMOUTshell de tu shell (gracias amigos en freenode #openssh IRC por esa sugerencia) - No tiene una duración de clave establecida, es decir, su agente mantiene su clave cargada para siempre o hasta que finalice / reinicie
Si está utilizando breves tiempos de espera de agente ssh, frases de contraseña fuertes y diferentes archivos de claves para cada tipo de rol que autentica: ¡esto lleva a un día muy frustrante!
Experimenté con gpgkey2ssh y tarjetas inteligentes, pero esto realmente no resuelve este problema en particular: todavía quiero la funcionalidad de ssh-agent y no quiero tener que volver a autenticar cada 5 minutos solo para evitar que mis claves privadas estén expuestas en la memoria mientras mi computadora está inactiva.
¿Lo estoy haciendo mal?
[1] Configuración del tiempo de espera predeterminado para el agente SSH
[2] https://lists.debian.org/debian-devel/2001/09/msg00851.html
[3] /server/518312/putty-pageant-forget-keys-after-period-of-inactivity
[4] https://bugs.launchpad.net/ubuntu/+source/gnome-keyring/+bug/129231
fuente
ssh-agentes independiente del tipo de sesión de la que forma parte (p. Ej., Sesión tty, sesión X11 u otra cosa). La única cosa que habría gustaría decir si es que sus secuencias de comandos automatizadas probablemente no deberían ser en función de la clave cargada en su agente. Probablemente cada uno debería tener su propia clave privada, que está autorizada mediante comandos forzados en los servidores apropiados para ejecutar solo los comandos remotos específicos que cada script necesita ejecutar. Eso, por supuesto, te permitirá ejecutarlos desde cron, etc ...ssh-agentsaber cuándo una sesión está inactiva, pero al menos iniciar el tiempo de espera desde que se produjo la última operación de firma, no solo cuandossh-agentse inició. Además, ya utilizo cuentas de usuario y archivos de claves separados para cada rol de script, sudoers solo permite sudo 1 o 2 comandos si es necesario, y he buscadolshellbloquear aún más las cosas. Pero todo eso todavía no me exime de la necesidad de proteger mis archivos de claves: solo porquesudo zfs sendes el único comando permitido para una clave determinada, ¡es un comando bastante poderoso para quien maneja esa clave!ControlMaster/ControlPath/ControlPersist(verman ssh_config) para su script. Al menos si solo se conecta a un host.ssh-agentmis llaves cargadas hasta que reinicie (lo que podría llevar semanas).Respuestas:
Si esto le preocupa, puede usar fácilmente la
xscreensaver-command -watchinterfaz para ejecutarssh-add -Dcuando la pantalla está bloqueada. Consulte la página del manual para ver un ejemplo muy simple.fuente