¿Los inicios de sesión SSH sin contraseña son más seguros? [duplicar]

El inicio de sesión basado en clave se considera mucho más seguro que el inicio de sesión basado en contraseña cuando se mira desde la perspectiva de un intento de fuerza bruta para obtener acceso desde un sistema de terceros: las posibilidades de descifrar una clave son efectivamente cero, mientras que las contraseñas malas son todas Muy común.

Desde la perspectiva de un sistema cliente comprometido (su estación de trabajo), no habrá una diferencia porque si los atacantes pueden obtener su clave privada y / o secuestrar una sesión, es probable que también instalen algún tipo de registrador de claves, haciendo inútil la ventaja percibida de las contraseñas.

Es tan seguro como su computadora. La clave está sentada, sin cifrar, en la memoria RAM; un atacante con acceso físico a su máquina, o acceso remoto a la raíz, podría obtenerlo.

Piénselo en los mismos términos como si sus compañeros de trabajo usaran un programa seguro para contraseñas y lo dejaran en la pantalla con la base de datos disponible sin entrada de contraseña; Si bloquea su estación de trabajo cuando se aleja y la mantiene protegida de la actividad remota hostil, entonces es razonablemente seguro, pero un ataque de RAM congelada aún podría en teoría obtener la clave.

Pero alguien en esas posiciones también podría instalar fácilmente un registrador de teclas, como usted señaló. Mientras tenga cuidado con la seguridad de su estación de trabajo, no lo llamaría menos seguro que las contraseñas; pero los beneficios reales de los inicios de sesión basados en claves son realmente la protección contra, por ejemplo, ataques de contraseñas de fuerza bruta contra el servidor (ya que las claves son casi imposibles de forzar).

En realidad, sus compañeros de trabajo tienen razón. Piense en esto ... Sus estaciones de trabajo se resquebrajan, han estado funcionando durante un par de días y ahora los piratas informáticos pwn su red entera porque no utiliza una frase de contraseña ssh.

Dicho esto, las contraseñas compartidas nunca son buenas y son una gran debilidad del sistema. Supondré que estás hablando de acceso de root.

El punto que estoy señalando es que ambos tienen inconvenientes y donde la seguridad debe ser un lugar.

Para todos los servidores que administro, utilizo una frase de contraseña SSH. Eso me da lo mejor de ambos mundos. Una contraseña que solo yo conozco, y que no usa una contraseña compartida para otros usuarios.

(y sí, he visto dónde se ha utilizado una clave ssh sin contraseña para comprometer toda la red.

Usted es tan seguro como su enlace más débil. Si sus servidores remotos permiten la autenticación con contraseña y basada en clave, usted es menos seguro en comparación con solo permitir una.

Sus vulnerabilidades adicionales para un sistema basado en clave sobre autenticación de contraseña (PA) son:

1. Un atacante obtiene una copia de su clave privada protegida por frase de contraseña al decir que tiene acceso físico a un disco no cifrado en cualquier sistema (por ejemplo, arranque en modo de usuario único) y luego ejecuta un ataque de fuerza bruta sin conexión basado en GPU en su clave y luego obtiene acceso a todos sus sistemas si su frase de contraseña es adecuadamente débil (por ejemplo, 4 palabras de diceware).

2. Usted usa algo como ssh-agent que mantiene su contraseña o clave privada en la memoria para un uso posterior y un atacante puede quitarlo de su sistema de alguna manera (por ejemplo, otro usuario root inició sesión mientras usted tenía el contraseña en la memoria).

3. Tu clave era mucho menos segura de lo que pensabas. Por ejemplo, la debilidad clave de OpenSSH; donde la única aleatoriedad provino del identificación del proceso, por lo que solo se generaron 65536 claves. Si bien este tipo de problemas se notan y parcheado rápidamente, como usuario final es imposible decir que no hay una falla importante en el generador de números aleatorios que se usa para crear sus claves.

Su seguridad adicional de usar autenticación basada en clave:

1. Los ataques de fuerza bruta no son factibles a lo largo de la vida del universo, sin robar su clave privada (y si se protegió la frase de contraseña; luego se rompe la frase de contraseña).
2. Los ataques MITM no funcionarán (un host remoto malintencionado no puede averiguar su clave privada / frase de contraseña); aunque ssh ya alerta a los ataques MITM para alertar a los administradores usando claves de host y archivos known_hosts .

En la práctica, ambos son igual de seguros. Cualquiera que pueda robar claves privadas ssh de la RAM, puede instalar un keylogger para obtener sus contraseñas / frases de contraseña / claves privadas.

Personalmente, me gusta su solución ya que una frase de contraseña es más conveniente (almacenada en la memoria RAM; en la máquina de un usuario que se bloquea después de 5 minutos); aunque solo puse mi clave privada protegida por contraseña en las máquinas locales en las que soy el único usuario.

Una razón por la que creo que la autenticación basada en clave tiene una ligera ventaja de seguridad es que hay veces que he visto a los dos usuarios finales, e incluso en algunas ocasiones ingresé mi contraseña en un campo de nombre de usuario en lugar de en la contraseña Cuadro de diálogo (dependiendo del cliente ssh). O presione la tecla Intro demasiado rápido y el cliente ssh se cerró, y mi contraseña entró en el historial de mi terminal.

Si no tiene cuidado cada vez que ingresa su contraseña, existe la posibilidad de que su contraseña se agregue de manera clara a varios archivos de registro, posiblemente al historial del shell, o incluso a algún tipo de caballo de Troya. En el caso de una clave sin contraseña o una clave que carga con un agente de SSH al comienzo de su sesión, nunca debe volver a escribir su contraseña, por lo que es poco probable que escriba sus credenciales en el lugar incorrecto y revele su contraseña para alguien o algo que no pretendías.

Bueno, en cierto modo es 6's. El primer riesgo inmediato de seguridad de un inicio de sesión basado en una contraseña sería que un usuario no autorizado obtenga (por cualquier medio) la contraseña del servidor. Del mismo modo, un inicio de sesión basado en clave tiene el riesgo de seguridad de que un usuario no autorizado obtenga acceso a su computadora. Si utiliza una contraseña compleja en el servidor, corre el riesgo de que los usuarios de la contraseña tengan que escribirla en algún lugar para recordarla. Con los usuarios clave, corre el riesgo de que se alejen de su escritorio con la computadora desbloqueada.

Gran parte de esto se reduce a la relación riesgo / usabilidad. Por supuesto, podría requerir contraseñas en las claves, solo permitir ciertas direcciones IP por cada clave y cualquier otra cantidad de medidas de seguridad estrictas, pero eso hace que su gente se sienta infeliz.

Pero para responder a su pregunta: si estamos hablando de una configuración Vanilla de OpenSSH, los inicios de sesión basados en contraseña y clave tienen sus propios puntos débiles de seguridad, diferentes.

Siempre desactivo el inicio de sesión de contraseña en ssh para root en mis sistemas. De esa manera, no hay forma de que un atacante pueda intentar forzar la fuerza bruta de la contraseña.

Aún debe tener cuidado con la seguridad en los sistemas cliente. Es posible que desee hacer que el agente ssh olvide sus credenciales clave cuando se active la pantalla de bloqueo. Esto ayudaría a evitar que los ataques en su máquina cliente comprometan su clave.

Algunas respuestas decentes aquí, pero todas parecen fallar en mi opinión.

El uso de un par de claves para la autenticación está reemplazando el "algo que sabes" de un sistema basado en contraseña con un "algo que tienes" de un sistema de clave o token. De vuelta a esto en un segundo.

Las claves son mucho más complejas. Creo que la mayoría de las implementaciones de SSH por defecto a 2048 clave RSA. Compare eso con una contraseña de 8 caracteres. Incluso si se hasheado en 256 bits, las contraseñas, ya que carecen de la aleatoriedad de las claves, pueden ser forzadas brutalmente. Schneier tiene algunas grandes observaciones sobre esto; incluso las contraseñas supuestamente "buenas" tienden a ser solo una combinación de datos crackeables (una palabra con un número y quizás algunas sustituciones simples); Nosotros, los humanos, somos demasiado predecibles.

En cuanto a que una clave sea tan segura como la contraseña para iniciar sesión, esto no es del todo correcto. Al ajustar una clave con otra contraseña, usted mejora la seguridad en gran medida porque básicamente está utilizando la autenticación de dos factores; para acceder a algo que tienes (la clave) debes usar algo que sabes (una contraseña). Sí, usar su contraseña de inicio de sesión para ajustar una clave socavaría esto.

Entonces, en el póster original, diría que tanto usted como sus compañeros de trabajo están equivocados. Es posible que lo sea menos, pero la respuesta correcta es que debe usar una clave y una contraseña.