Estoy leyendo un artículo en Master Linux Now 2013 llamado OpenSSH: Easy Logins y usa ssh-agent para permitirle ingresar una frase de contraseña para su clave una vez, y luego podrá conectarse a una máquina remota libremente sin tener que volver a escribirla mientras se ejecuta el agente ssh.
La razón por la que me atrajo el artículo en primer lugar, además de no tener que volver a escribir mi contraseña un millón de veces; fue para poder hacer copias de seguridad desatendidas desde / hacia máquinas remotas llamando a rsync desde cron en una máquina remota al servidor a través de ssh;
Vi otro artículo en el que alguien simplemente omitió la frase de contraseña para que cron pudiera usar fácilmente la clave para iniciar sesión, no se siente bien, pero ¿está bien hacerlo en la práctica? Quiero decir, si alguien se apoderara de ese archivo clave, podría causar estragos en la copia de seguridad de la máquina.
Me parece que sería más seguro asegurarse de que el usuario haya iniciado sesión al reiniciar y que ingrese la frase de contraseña una vez, cuando inicie sesión para que el agente se ejecute y luego simplemente espere a que el trabajo cron se ejecute con la pantalla bloqueada; pero es probable que me esté perdiendo algo aquí, como con qué usuario o tipos de usuario se ejecutan los trabajos cron.
Respuesta aceptada:
Restringe los comandos que puede invocar la tecla
Si una clave SSH va a ser utilizada por cualquier tipo de tarea automatizada o desatendida, debe restringir qué comandos puede ejecutar en una máquina remota, sin importar la decisión que tome sobre cómo y dónde almacenar la clave.
Use algo como esto en ~/.ssh/authorized_keys :
command="/usr/sbin/the-backup-daemon" ssh-rsa AAAAAAAAAAAABBBBBXXXXXX.....
De esa manera, al menos la llave no debería poder, como dices, causar estragos. Solo puede acceder a lo que se supone que debe acceder, etc. Lo más probable es que todavía pueda causar daños, pero no debería tener acceso total al sistema remoto.
También puede restringir las direcciones IP a las que se les permite conectarse usando esa clave y deshabilitar un montón de otras funciones SSH como el reenvío de puertos para las conexiones donde se usa esa clave:
from="10.1.2.3",no-port-forwarding,no-X11-forwarding,no-agent-forwarding,no-pty,command="/usr/sbin/the-backup-daemon" ssh-rsa AAAAAAAAAAAAXXXXXX.....
Todo lo que tiene que ir en una sola línea en ~/.ssh/authorized_keys .
Proteger la llave
Depende de cuál sea su modelo de amenaza.
Si le preocupa que le roben la clave mientras está "fría", por ejemplo, que le roben físicamente la computadora donde se guardó, entonces no querrá guardarla sin una frase de contraseña en esa ubicación.
podrías inicie un tipo de agente SSH en segundo plano manualmente después de que se inicie el servidor, agregue la clave a ese agente y registre el $SSH_AUTH_SOCK del agente para uso futuro por parte del trabajo cron, pero honestamente eso parece más problemático de lo que vale. También puede almacenar la clave sin cifrar en un tmpfs sistema de archivos y haga que el trabajo cron acceda a él desde allí. De cualquier manera, la clave vive solo en la memoria (si no tiene intercambio o intercambio cifrado). Por supuesto que deberías chown y chmod el archivo para que solo el usuario objetivo pueda acceder a él.
Por otra parte, si está preocupado por eso, probablemente ya haya configurado esta computadora con un sistema de archivos raíz encriptado e intercambio (por ejemplo, luks), por lo que es posible que no tenga que preocuparse por eso.
Si le preocupa que le roben la clave mientras está "activa" (cargada en la memoria), entonces no hay mucho que pueda hacer al respecto. Si el trabajo cron puede acceder a él, también puede hacerlo otra cosa que haya logrado obtener el mismo acceso. Es eso, o renunciar a la comodidad de la ejecución del trabajo sin supervisión.
En conclusión, debe tratar un servidor de respaldo como un sistema muy privilegiado ya que, por necesidad, tendrá acceso de solo lectura a los sistemas de archivos completos de todas las computadoras de las que respalda. Su servidor de respaldo no debe ser accesible desde Internet, por ejemplo.