¿Pueden las claves públicas ser un riesgo de seguridad al realizar inicios de sesión SSH sin contraseña?

Los valores en .ssh/authorized_keys son claves públicas : son objetos matemáticos, cada uno de ellos está vinculado a otro objeto matemático llamado clave privada . Cuando el servidor nagios se conecta a uno de los servidores monitoreados, utiliza su clave private : el servidor nagios demuestra su conocimiento de la clave privada a través de una operación matemática (a firma digital ), que el servidor de destino verifica con la clave pública correspondiente.

La magia de la construcción es que la clave pública se puede hacer pública: aunque la clave pública y la privada comparten una estructura común, esa estructura está "oculta" y no se puede reconstruir solo a partir de la clave pública (aquí, "no se puede" significa "necesitaría una computadora más grande que todo el estado de Wyoming y programada por Chuck Norris").

Por lo tanto, para iniciar sesión en los servidores de destino, no necesita agarrar la clave pública , sino la clave privada , y esa nunca deja las entrañas de el servidor de nagios.

(Por otro lado, si puede obtener un acceso de lectura al servidor nagios, por ejemplo, puede ver una cinta de respaldo, puede obtener la clave privada y acceder a todos los servidores. Nirvāṇa del atacante. < em> Eso puede ser un grave problema de seguridad: ¡protege tus copias de seguridad!)

No sé si lo entiendo bien, pero la autenticación del certificado SSH funciona de una manera que tiene que configurar su SSHD con certificados confiables, por lo que, para agregar su certificado como lo confía el servidor, debe ser capaz de acceder a ella en primer lugar.

Supongamos que, de alguna manera, obtiene acceso al servidor en cuestión (ya sea física o remotamente). Puede haber un archivo nagios.pub en /root/.ssh/authorized_keys/ y su pregunta es, ¿qué sucede si reemplaza el archivo nagios.pub con attacker.pub (solo obviamente renombrado)? La respuesta es que luego podría iniciar sesión en ese servidor utilizando la clave privada del atacante (también le negaría al usuario el acceso legítimo al sistema).

La pregunta entonces es, ¿qué has ganado? Bueno, nada realmente, ya que en primer lugar ya tenías acceso al sistema. Tal vez haya obtenido acceso remoto, pero hay un millón de formas de hacerlo una vez que tenga acceso físico. Tal vez haya obtenido acceso persistente, pero nuevamente hay muchos otros métodos para hacer esto que son menos rastreables (por ejemplo, rootkits).

Es seguro porque para iniciar sesión necesita las claves pública y privada, y el servidor solo necesita la clave pública para verificar que tiene la clave privada. Por lo tanto, si el servidor está configurado correctamente, solo puede obtener la clave pública, pero aún no tendrá la clave privada. Y por diseño, no es posible calcular la clave privada solo a partir de la clave pública.