¿Hay algún punto en la contraseña que protege una clave privada SSH que utiliza una cuenta de servicio?

En este tipo de escenarios, dejo la clave privada sin cifrar (excepto quizás sentarme en un disco que está cifrado), con los permisos de lectura restringidos a root y el cronjob ejecutado como root, pero hago todo lo posible para restringir la utilidad de este clave para la tarea muy específica (en lugar de permitir que inicie sesión en la máquina remota con acceso completo).

Esto se puede hacer bastante sencillo configurando ~/.ssh/authorized_keys para ejecutar automáticamente un comando específico cuando inicie sesión con la tecla específica.

command="/usr/bin/remote_commands_to_run.sh",no-port-forwarding,no-X11-forwarding,no-agent-forwarding,no-pty
ssh-rsa AAAAB3Nz...DfE= root@some_client

Consulte esta respuesta para más . Debe tener cuidado de que los comandos en /usr/bin/remote_commands_to_run.sh no permitan que un atacante se escape a un shell. También puede tener sentido crear una cuenta limitada en la máquina remota con, por ejemplo, un shell de /bin/false que ejecute el comando remoto (p. Ej., Coloque la clave pública asociada con la clave privada en ese usuario limitado authorized_keys ).

Como siempre después de configurarlo, intente y pruebe para asegurarse de que la clave no tenga más privilegios de los que espera (p. ej., que sftp no funciona, que rsync no funciona, etc.).

En otra notificación, veo que su tarea particular es sincronizar los datos (probablemente en directorios específicos). Probablemente esto sea factible con cuentas limitadas (por ejemplo, chroot'd para poder ver solo esos directorios específicos sin acceso a un shell). Creo que se pueden usar herramientas como rssh para hacer esto; Consulte al superusuario o serverfault para obtener los mejores consejos.

Concedido, lo que hago en este escenario es montar los directorios específicos como una unidad de red (por ejemplo, a través de NFS / sshfs) y luego hacer rsync a ese directorio montado en un script cron.

Creo que la protección de contraseña es sabia. Mejor tenerlo que no. Pero, como usted dijo, si la máquina de Alice está comprometida, incluso con la clave privada no se puede usar sin la contraseña. Sin embargo, si la máquina está comprometida, el atacante podría simplemente esperar a que Alice ingrese la contraseña, y se capturaría fácilmente con un registrador de teclas.