¿Por qué debería usar la autenticación de clave pública para SSH?

Estoy ejecutando un servidor SSH y todavía estoy usando una autenticación de contraseña simple. En todas partes que leo sobre seguridad me recomiendan usar la autenticación de clave pública. Pero no obtengo las ventajas. Usarlos es, en mi opinión, inseguro o un trabajo muy útil.

Por supuesto, si alguien intenta forzar el inicio de sesión en mi servidor SSH, la clave pública es mucho más segura que cualquier contraseña. Pero aparte de eso, es totalmente inseguro.

Los asesores sostienen principalmente que no es necesario recordar una contraseña. ¿Qué tan inseguro es eso? Entonces, si alguien piratea mi computadora, ¿no solo obtiene mi computadora, sino también mi servidor? Si estoy usando SSH de varios clientes diferentes, tengo que almacenar las claves públicas una a cada una de ellas, lo que multiplica la posibilidad de que caigan en manos falsas. Podría guardarlos en un dispositivo USB que llevo conmigo, pero se puede perder y el buscador tiene acceso a mi servidor.

Posiblemente me sirva mejor con la autenticación de dos factores.

¿Hay algún argumento que me falta? ¿Cuál es la mejor manera para mí?

si alguien piratea mi computadora, ¿no solo obtiene mi computadora, sino también mi servidor?

Esto es potencialmente cierto de todos modos con los keyloggers: tan pronto como inicies sesión en tu servidor desde la computadora comprometida, recibirán la contraseña.

Pero hay 3 ventajas para las claves:

1) Autenticación en caché. Ingrese su frase de contraseña una vez, ejecute múltiples comandos ssh. Esto es muy útil si está usando algo que usa ssh como transporte, como scp, rsync o git.

2) Autenticación escalable. Ingrese su frase de contraseña una vez, inicie sesión en varias máquinas . Cuantas más máquinas tenga, más útil será. Si tienes 100 máquinas, ¿qué haces? No puede usar la misma contraseña (a menos que sea una granja de clones), y no puede recordar tantos. Por lo tanto, tendría que usar un administrador de contraseñas y volvería al punto único de compromiso. Efectivamente, la contraseña clave es su administrador de contraseñas.

2b) Se escala de la otra manera si tiene varios administradores que usan los mismos sistemas, porque puede revocar las claves del usuario A sin tener que decirle a B, C, D, E, F ... que la contraseña ha cambiado.

(Esto también se puede hacer con cuentas individuales y sudo, pero luego debe aprovisionar esas cuentas de alguna manera)

3) Automatización y delegación parcial. Puede configurar SSH para ejecutar un comando particular cuando se conecta una tecla . Esto permite que un proceso automatizado en el sistema A haga algo en el sistema B sin tener plena confianza sin contraseña entre los dos.

(Es un reemplazo para rlogin / rsh, que era muy inseguro)

Editar: otra ventaja de las claves públicas en lugar de las contraseñas es el escenario común en el que el servidor se ve comprometido por una vulnerabilidad. En este caso, iniciar sesión con una contraseña compromete la contraseña de inmediato. ¡Iniciar sesión con una clave no lo hace! Diría que esto es más común que el escritorio de origen del administrador se vea comprometido.

Si está utilizando buenas contraseñas, esto puede ser lo suficientemente seguro. Normalmente limito al mínimo el número de servidores de acceso público y permito SSH desde IP (s) específicas siempre que sea posible.

Además, puede proteger sus claves mediante frase de contraseña (contraseña). Por lo tanto, esta frase de contraseña debe ingresarse cada vez que necesite iniciar sesión en sus servidores. Nadie puede usar su clave a menos que se proporcione la frase de contraseña correcta.

Hay publicaciones similares:

1. Publicar desde el servidor por defecto .
2. Publicar desde seguridad stackexchange .
3. Publicación del superusuario .

Una forma en que la autorización de clave pública es más segura es cuando el atacante logra ser un hombre en el medio (MitM) entre su computadora cliente y el servidor, y no nota la clave de host cambiante (posiblemente porque no lo hizo no tenga la clave anterior, por ejemplo, porque esta es la primera vez que usa esta computadora cliente específica).

(Lo mismo se aplica cuando el atacante logra tomar el control del servidor y hay otros servidores donde funcionan las mismas credenciales).

Con la autenticación estándar basada en contraseña, está enviando su contraseña (dentro de la conexión encriptada) en texto plano, el servidor genuino normalmente la codificará y comparará el resultado con una codificación almacenada en su base de datos de contraseñas. Un atacante de MitM podría tomar esta contraseña, abrir una conexión con el servidor real e iniciar sesión allí ... y reenviarle el contenido (para que no note nada), o simplemente hacer sus propias cosas malvadas en su servidor .

Con la autenticación de clave pública, el cliente básicamente firma algunos datos conocidos tanto por el servidor como por el cliente para demostrar que posee la clave privada y envía la firma al servidor. Estos datos firmados incluyen un identificador de sesión, que depende de números aleatorios elegidos por el cliente y el servidor, y por lo tanto es diferente para cada sesión. Si el MitM abre su propia conexión SSH al servidor real, ese tendrá una ID de sesión diferente y, por lo tanto, la firma proporcionada por el cliente no funcionará allí.

Por supuesto, como ya se dijo en otras respuestas, debe mantener su clave privada segura, por ejemplo, encriptada con una frase de contraseña, o posible en un dispositivo separado que solo crea firmas después de ingresar un PIN.

OpenSSH puede mantener su propia CA para administrar las claves de host y cliente SSH y puede usar listas de revocación en ellas. Esto podría aumentar la seguridad proporcionada por la autenticación basada en claves.

Tiene razón sobre el reclamo "no necesita una contraseña". Eso es realmente inseguro en el lado del cliente.

Lo que hace que permitir solo las claves públicas para iniciar sesión sea mucho más seguro es el hecho de que no hay forma de acceso por fuerza bruta a su servidor. Todo lo que un atacante podría lograr es poner algo de carga en su servidor; puede emplear fail2ban para mantener eso bajo control.

Para la seguridad en el lado del cliente, debe proteger la clave privada con una buena frase de contraseña. Por supuesto, ahora conectarse al servidor es más engorroso que con una contraseña. Para superar esto, puede utilizar el agente ssh para almacenar la clave privada en la memoria si tiene la intención de conectarse al servidor varias veces seguidas. Es una buena práctica limitar el tiempo durante el cual una clave se mantendrá en la memoria.

Posiblemente me sirva mejor con la autenticación de dos factores.

De hecho, una posibilidad para 2FA para SSH (y una que requiere relativamente poca configuración / complejidad) es usar una clave pública y una contraseña.

Creo que AuthenticationMethods publickey,keyboard-interactivese puede agregar algo similar para /etc/ssh/sshd_configque funcione.

En términos más generales, el problema es más que las contraseñas (solas) no son un gran método para la autenticación porque a menudo son de dudosa calidad. Un 'argumento' muy simple para las claves frente a las contraseñas es que una clave generalmente tendrá al menos 2048 bits y, a menudo, más (para las claves EC, esta sería la fuerza efectiva, en lugar del tamaño real). Esos bits también son generados por un mecanismo criptológicamente seguro (o apropiado).

Una contraseña suele tener menos de 2048 bits y, a menudo, no se deriva de una fuente criptográficamente segura.

También puede proteger sus claves con una contraseña, para protegerse contra los problemas relacionados con su pérdida (aunque alguien podría intentar forzar esa contraseña por fuerza bruta).

Básicamente, las diferencias pueden hacerse bastante transparentes entre las claves y las contraseñas, y el uso de las claves le proporciona una contraseña mejor de la que un humano podría manejar. Esto no quiere decir que sean una panacea, pero en promedio, brindan más seguridad que las contraseñas.