¿Qué tan malo es tener múltiples dispositivos con las mismas claves de servidor SSH?

Estoy trabajando en un dispositivo integrado que ejecuta FreeBSD y SSH.

Como sabes, a sshd le gusta generar aleatoriamente un conjunto de claves de servidor cuando se inicia por primera vez. El problema es que enviaremos el producto con un sistema de archivos de tarjeta SD de solo lectura (no negociable).

Mis dos opciones como las veo son:

• Envíe las mismas claves de servidor sshd en todos los dispositivos
• Montar un sistema de archivos de memoria y generar las claves del servidor en cada arranque (lento ...)

¿Es un problema de seguridad importante enviar las mismas claves de servidor en todos los dispositivos? Estos artículos no estarán directamente en internet. Ocasionalmente habrá múltiples dispositivos propiedad de la misma persona y en la misma red.

La mayoría de las veces el dispositivo no estará conectado a internet.

Iniciar sesión con SSH no es parte de la operación normal. Es principalmente para la conveniencia de los programadores y técnicos. Los clientes no iniciarán sesión en el dispositivo con SSH.

¿Cuáles son las ramificaciones de usar las mismas claves de servidor en múltiples dispositivos de hardware?

PD: ¿alguien podría crear una etiqueta de internet de las cosas?

EDITAR : estoy hablando de instalar las mismas claves privadas de host en todos los servidores (dispositivos). En lo que respecta a las claves públicas / privadas del usuario, actualmente no hay planes para usar el inicio de sesión basado en claves: sería un inicio de sesión con contraseña. Nuevamente, la misma contraseña en todos los servidores (dispositivos).

Sé que esta es probablemente una mala idea. Sin embargo, me gustaría saber por qué precisamente es una mala idea para poder entender las compensaciones.

En lugar de almacenar datos específicos del host, como las claves de host ssh en la tarjeta SD u otros medios de solo lectura, puede almacenarlos en NVRAM, que es para lo que sirve en un sistema integrado. Deberá realizar algunos scripts personalizados para almacenar y recuperar las claves en el momento del arranque, pero los scripts serán exactamente los mismos para cada dispositivo.

El impacto de enviar el mismo par de claves con todos sus dispositivos está directamente relacionado con la seguridad de los clientes que se conectan a ellos, ya que significa que no hay forma (desde un cliente SSH) de identificar de manera única el dispositivo al que se puede conectar. En caso de que su par de claves se filtre, podría usarse para ataques MITM.

Por otro lado, la regeneración de las claves en cada arranque también activará una alerta en los clientes.

Como referencia, de man ssh(1):

sshmantiene y verifica automáticamente una base de datos que contiene identificación para todos los hosts con los que alguna vez se ha utilizado. Las claves de host se almacenan en ~/.ssh/known_hostsel directorio de inicio del usuario. Además, el archivo /etc/ssh/ssh_known_hostsse verifica automáticamente en busca de hosts conocidos. Cualquier nuevo host se agrega automáticamente al archivo del usuario. Si la identificación de un host cambia alguna vez, sshadvierte sobre esto y deshabilita la autenticación de contraseña para evitar la suplantación de servidores o ataques de intermediarios, que de otro modo podrían usarse para eludir el cifrado. La StrictHostKeyCheckingopción se puede usar para controlar los inicios de sesión en máquinas cuya clave de host no se conoce o ha cambiado.

Parece que en la primera opción, las claves SSH estarían disponibles en la tarjeta SD. Por lo tanto, cualquier usuario podría tomar la tarjeta y leerla. Entonces, básicamente, sus claves privadas se han convertido (en su mayoría) en públicas.

Esto permitirá ataques de hombre en el medio, como los siguientes:

1. Un usuario configura un servidor SSH con las claves privadas obtenidas de su dispositivo y le da esa dirección IP a su técnico.
2. Su técnico ingresa la contraseña de root a través de la conexión SSH.
3. El usuario ahora conoce la contraseña de root que es válida para todos sus dispositivos.

Sin embargo, no debe usar contraseñas raíz en primer lugar, use las claves ssh para la autenticación. Entonces, el impacto de las claves del servidor compartido es bastante pequeño si solo inicia sesión desde una LAN.

SSH también proporciona confidencialidad, por lo que un atacante debe poder configurar un servidor falso para beneficiarse de las claves; oler pasivamente el tráfico no permitirá descifrarlo.

¡Leí esto con horror! Yo, que he hecho varias máquinas en el mismo clúster con la misma clave de host ssh, nunca me atrevería a hacer esto. Bajo ninguna circunstancia permita que máquinas con diferentes conjuntos de administradores compartan claves de host ssh. De esa manera se encuentra la locura y el horror cuando gritas cuando te publican por tu falta de seguridad.

He aquí, te digo la verdad, el que compromete un dispositivo los compromete a todos. Una vez que obtenga uno, espere que las personas malas salten de uno a otro a voluntad y la seguridad retroceda como si fuera papel delgado.

Como usted menciona que el acceso al SSH no es utilizado por el usuario / cliente final, es posible que desee desactivar el acceso SSH de manera predeterminada y solo habilitarlo temporalmente cuando el dispositivo se pone en modo "depuración".

Luego puede enviar todos los dispositivos con la misma clave, suponiendo que haya protegido el modo de "depuración" para que alguien que intente piratear el dispositivo no pueda activarlo de forma remota.

O tiene una nueva clave generada cuando el dispositivo entra en modo de "depuración", por lo que no tiene que perder el tiempo de arranque generando las claves cada vez que se enciende el dispositivo.

Aquí hay un escenario de ataque de muestra basado en las restricciones que tiene:

Si sus dispositivos son, digamos un Raspberry Pi por ejemplo. Si subo y saco la tarjeta SD de una, puedo pegar la tarjeta SD en mi propia computadora, encontrar la clave sshd y copiarla a donde quiera. Tal vez tomo mi propia frambuesa pi y una tarjeta ethernet USB. Ahora puedo pegar eso entre un dispositivo objetivo y donde sea que vayan y monitorear las conexiones ssh. Cuando veo que el dispositivo de destino está intentando establecer una conexión ssh, hago esto:

(target) <---> (my evil sshd <--> decrypted traffic <--> ssh) <---> (real server)
                                       |
                                       V
                                    log file

¿Oh, qué es eso? ¿Tu contraseña es "Me gustan los gatos"? Chico, este es un correo electrónico interesante que enviaste a tu esposa. Apuesto a que sería aún más interesante si ella leyera este correo electrónico que le envió a la esposa de su vecino de al lado.

Las posibilidades son infinitas . Y el objetivo nunca lo sabría, porque la clave sshd es idéntica a la que se encuentra en el servidor real. Dependiendo de la seguridad física de las instalaciones que reciben su dispositivo, esto podría ser increíblemente trivial. No hagas esto.

En cambio, haz lo que ya propones pero arréglalo . Antes de escribir su imagen, ejecute algo como esto:

ssh-keygen -f some-new-server
cp some-new-server /path/to/the/mounted/image/sshd/key
cp some-new-server.pub /path/to/the/mounted/image/sshd/key.pub

Y ahora cada servidor tiene una nueva clave. Porque realmente, realmente no quiere ser la distribución de copias de una clave. Quiero decir, sinceramente, es al menos tan malo como tomar una foto de las llaves de su casa y subirlas a Internet con la dirección de su casa.