Cómo configurar los cronjobs que hacen scp sin guardar el archivo .pem en ninguna de las máquinas

Question

Cómo configurar los cronjobs que hacen scp sin guardar el archivo .pem en ninguna de las máquinas

#1 de gowenfawr (2 votos)
#2 de tylerl (0 votos)

1

Tengo la siguiente situación y quiero saber cuáles son las mejores prácticas para hacer esas cosas sin exponerme a los problemas de seguridad

Tengo dos servidores que usan la misma clave privada para iniciar sesión.
El servidor 2 copia los archivos al servidor 1 a través de scp (actualmente guardo la clave privada en el servidor 2)

Si algún pirata informático obtiene el control del servidor 2, también obtendrá la clave privada y, por lo tanto, ambos servidores se verán comprometidos.

Estoy bastante seguro de que este es un escenario muy común para la mayoría de las configuraciones y quiero saber cuáles son las mejores prácticas en estos casos.

authentication key-management ssh

pregunta Eastern Monk 18.03.2014 - 01:05

fuente

2 respuestas

Lea otras preguntas en las etiquetas authentication key-management ssh

¿Puede escuchar su última llamada GSM grabada cuando devuelve la llamada a un usuario? error de autenticación OpenSSL dgst

score 2 · Answer 1

Las mejores prácticas que deberían preocuparte aquí son:

No reutilizar las credenciales para múltiples propósitos. Los dos servidores no deben compartir una clave privada.
Procesos automatizados de Hobble. Asegúrese de que el canal SSH que está abriendo el servidor 2 está limitado a solo copiar archivos, y solo al árbol de directorios deseado.

Lo último es importante. Si está guardando la clave privada en el servidor 2 para que pueda usarse a través de cron, debe limitar el daño que puede ocurrir en el servidor 1 si alguien toma el control del servidor 2 y trata de usar esa clave. ¿Darles un inicio de sesión interactivo? Muy mal. ¿Sobrescribir archivos arbitrarios? Muy mal. ¿Sobrescribir archivos en un árbol, usando un comando predeterminado? Mucho mejor. Se puede escribir sshd_config moderno para limitar poderosamente un inicio de sesión específico. Cree un inicio de sesión especial para esto, de modo que pueda bloquearlo firmemente. No uses la raíz. No, en serio, no uses root.

score 0 · Answer 2

Guardar el archivo .pem en el servidor de conexión es realmente la única opción en esta instancia.

Pero puede mitigar cualquier amenaza (a) creando una clave ssh dedicada que se use para nada más que este proceso, y (b) agregando restricciones en su archivo authorized_keys para que no haya ninguna acción, incluso permitido en el servidor remoto que no sea este proceso.

Estás acostumbrado a que tu archivo authorized_keys se vea así:

ssh-rsa AAAAB3NzaC1yc2EAAAADAQA... user@host

Pero puede agregar parámetros para limitar lo que puede suceder durante esa conexión. Así:

command="/bin/myproc -foo" ssh-rsa AAAAB3NzaC1yc2EAAAADAQA... user@host

También puedes aplicar otras restricciones:

from="1.2.3.4",tunnel=0,no-pty,command="/bin/foo" ssh-rsa AAAAB3NzaC1yc2EAAAADAQA... user@host

Puede restringir aún más el comportamiento restringiendo los permisos del usuario, utilizando chroot , process control groups , capacidades de proceso , etc.