riesgo de usar claves públicas ssh

Tengo el servidor A y el servidor B (copia de seguridad), y me preguntaba, si alguien entra en el servidor A, ¿podría ser potencialmente peligroso entrar en el servidor B si configuré el inicio de sesión sin contraseña utilizando las claves públicas ssh?

Estoy tratando de configurar rsnapshot.

Gracias

Sí, este es uno de los problemas con las claves SSH sin contraseña. Si almacena una clave privada en el servidor A que le permite conectarse al servidor B, obtener acceso al servidor A está efectivamente obteniendo acceso al servidor B. (No es lo contrario, no es cierto: obtener acceso al servidor B no daría como resultado un compromiso inmediato del servidor A, suponiendo que no haya configurado las claves SSH para permitir inicios de sesión sin contraseña en esa dirección.

Hay algunas cosas que puede hacer para mitigar esto:

• Si el proceso no necesita ser completamente automatizado, agregue una contraseña a sus claves SSH. (Esto probablemente no funcionará para usted, ya que nota que es para una copia de seguridad)
• Para inicios de sesión sin contraseña bajo su propia cuenta en varias máquinas, le recomiendo crear una clave con contraseña para cada máquina que escriba físicamente, y use un agente SSH para almacenar la clave en la memoria mientras la usa. El reenvío de agentes debería permitirle "saltar" de host a host sin crear claves en cada host remoto.
• Para las claves SSH automáticas y sin contraseña, recomiendo restringir los comandos que la clave puede ejecutar. En su authorized_keysarchivo, prefije cada una de sus claves con:
  command="<allowed command line here>",no-port-forwarding,no-X11-forwarding,no-agent-forwarding,no-pty

Hace 8-9 años trabajé en un entorno de usuario compartido con cientos de usuarios locales, y los inicios de sesión basados ​​en claves SSH se deshabilitaron porque no había forma de aplicar políticas de contraseña en las claves. Mientras controle el escenario por completo, hoy en día las claves SSH son definitivamente mejores que solo usar contraseñas.

Sí, la mayoría de las guías en Internet dejan de hacer que ssh sin contraseña funcione, en lugar de hacerlo funcionar de manera segura. Esta guía hace un buen trabajo al mostrar lo que se puede hacer para reducir los riesgos. Básicamente (para citar el artículo):

• crear una cuenta de rol de un solo propósito para el trabajo: es decir, un usuario dnssyncen cada máquina
• si es posible, haga que los archivos puedan ser escritos por ese usuario, en lugar de confiar en ser root
• para esos bits que realmente necesitan acceso privilegiado, cree un script para hacerlo y use sudo
• uso command=y from=opciones en authorized_keysarchivos para restringir las claves sin contraseña
• para realizar la transferencia de archivos, escriba un script para hacerlo usando rsync, en la máquina receptora , de modo que el acceso remoto pueda ser de solo lectura
• Si esto significa que se necesita acceso a la máquina iniciadora desde la máquina remota, use en ssh-agentlugar de crear una segunda clave sin contraseña

Hay un par de problemas con las claves ssh:

No hay forma centralizada de revocar una clave.

No hay forma de aplicar políticas de contraseña en las claves (¿está encriptada su clave privada, y si es así, está encriptada con una buena contraseña?).

Estos son los problemas que resuelve kerberos. Sin embargo, presenta otros, es decir, es más complejo de implementar y requiere una infraestructura real de administración de usuarios para implementar y administrar.

En cualquier caso, aunque las claves autorizadas ssh permiten ataques de tipo gusano morris , aún es mejor que los servicios .r y telnet por millas (años luz)

En cualquier entorno sobre el que he tenido control, siempre he sido muy exigente con el mínimo privilegio posible para las cuentas de servicio.

En este caso, sugeriría asegurarse de que la cuenta de usuario en el servidor remoto solo pueda ejecutar un conjunto pequeño y bien definido de ejecutables. Puede usar varias cuentas en el lado remoto y sudo para lograr esto.

Incluso en este caso, aún está sujeto a los errores de escalada de privilegios locales, así que sea meticuloso y realice un seguimiento estricto de los errores de seguridad.