¿Es mejor usar una clave pública para iniciar sesión en SSH que guardar una contraseña?

Mi respuesta es que usar pares de claves públicas es una cosa mucho más inteligente que hacer que usar contraseñas o listas de contraseñas. Me centraré en las cosas que no se conocen ampliamente sobre diferentes formas de autenticación SSH, y no veo otras respuestas que las mencionen.

En primer lugar, debe comprender que la autenticación del usuario es un proceso diferente y separado del establecimiento del canal seguro . En términos simples, lo que esto significa es que primero, se usa la clave pública del servidor (¡si se acepta!) Para construir el canal SSH seguro, al permitir la negociación de una clave simétrica que se usará para proteger la sesión restante, habilitar el canal confidencialidad, protección de integridad y autenticación del servidor.

Después de el canal es funcional y seguro, se lleva a cabo la autenticación del usuario. Las dos formas habituales de hacerlo es mediante una contraseña o un par de claves públicas. La autenticación basada en contraseña funciona como se puede imaginar: el cliente envía su contraseña a través del canal seguro, el servidor verifica que esta es la contraseña del usuario específico y permite el acceso. En el caso de clave pública, tenemos una situación muy diferente. En este caso, el servidor tiene almacenada la clave pública del usuario. Lo que sucede a continuación es que el servidor crea un valor aleatorio (nonce), lo cifra con la clave pública y lo envía al usuario. Si el usuario es quien se supone que debe ser, puede descifrar el desafío y enviarlo de vuelta al servidor, quien confirma la identidad del usuario. Es el clásico modelo de desafío-respuesta . (En SSHv2 se usa algo un poco diferente pero conceptualmente cercano)

Como puede imaginar, en el primer caso, la contraseña realmente se envía al servidor (a menos que SSH use la respuesta de desafío de contraseña), en el segundo, su clave privada nunca abandona el cliente. En el escenario imaginario, alguien intercepta el tráfico SSL y puede descifrarlo (utilizando una clave privada del servidor comprometida, o si acepta una clave pública incorrecta al conectarse al servidor) o tiene acceso al servidor o cliente, su contraseña será conocido: con la autenticación de clave pública-privada y el modelo de respuesta de desafío, sus detalles privados nunca caerán en las manos del atacante. Entonces, incluso si un servidor al que te conectas está comprometido, otros servidores para los que utilices la misma clave no lo serían.

Hay otras ventajas de usar un par de claves públicas: la clave privada no debe almacenarse en texto sin cifrar en la PC de su cliente como sugiere. Por supuesto, esto deja el archivo de clave privada abierto para comprometerse, como lo haría un archivo de contraseña no cifrado, pero es más fácil de descifrar (al iniciar sesión) y usar la clave privada. Debe almacenarse encriptado y necesita que proporcione una frase de contraseña generalmente larga para descifrarla cada vez que se use.

Por supuesto, esto significa que tendrá que proporcionar la contraseña larga cada vez que se conecte a un servidor, para desbloquear su clave privada. Puede aumentar la capacidad de uso del sistema utilizando un agente de autenticación: este es un software que desbloquea las claves de la sesión actual, cuando inicia sesión en gnome, por ejemplo, o cuando inicia sesión por primera vez en su cliente, por lo que puede escriba 'ssh remote-system-ip' e inicie sesión, sin proporcionar una frase de contraseña, y hágalo varias veces hasta que cierre sesión en su sesión.

Por lo tanto, para resumir, el uso de pares de claves públicas ofrece considerablemente más protección que el uso de contraseñas o listas de contraseñas que se pueden capturar si el cliente , el servidor o la sesión segura está comprometida . En el caso de no usar una frase de paso (que no debería ocurrir), los pares de claves públicas aún ofrecen protección contra las sesiones y servidores comprometidos.

En comparación con una lista almacenada de contraseñas (largas y aleatorias), una clave privada SSH almacenada ofrece la misma seguridad : las cosas están seguras siempre que su archivo privado permanezca privado.

La clave privada, sin embargo, es mucho más conveniente , prácticamente en la práctica (en este momento, los clientes SSH lo admiten de forma inmediata, al contrario de un archivo personalizado de contraseñas que debe use con algunas copias manuales y pegue) y teóricamente (puede reutilizar la misma clave para cada host al que desee conectarse, mientras que una lista de contraseñas aumentará linealmente con el número de hosts contactados, a menos que reutilice la misma contraseña para múltiples hosts) , que es malo ).

Depende de qué amenazas consideres.

El punto principal de la autenticación de clave pública / privada es no permitir que su secreto salga, incluso a la parte a la que se autentica. Por esta razón, es mejor utilizar las teclas, ya que nunca envía su máquina externa a su secreto.

Sin embargo, si la amenaza que considera es local, y si no protege sus claves privadas con una contraseña, almacenar una lista de contraseñas en claro es casi lo mismo que almacenar las claves privadas sin protección.

Por esta razón, es útil proteger sus claves privadas con una contraseña y usar herramientas como ssh-agent (para su comodidad). En OSX, esto también se puede integrar con el KeyChain, de modo que es posible que ni siquiera necesite desbloquear la clave privada (en el nivel de la aplicación, solo en el nivel del demonio de seguridad) para poder usarla a través de SSH (esencialmente, el KeyChain y el demonio de seguridad se encarga de ssh-agent).

La principal diferencia entre usar una clave privada sin contraseña y usar contraseña de texto sin formato para la autorización de SSH es autorizar por algo que tenga (su clave privada) o por algo que sepa (su contraseña memorizada). Son de diferentes razas, pero es difícil decir que uno es mejor o más seguro.

Autorizar por algo que tienes suele ser más difícil para el atacante replicar de la nada: es más fácil forzar / adivinar su contraseña más sencilla que replicar su clave. Pero tiene un gran inconveniente: ahora mantener su clave privada realmente en secreto se convierte en primordial . Si usa algo que solo usted conoce (contraseña memorizada), debería ser más fácil mantenerlo así (al menos en teoría). Pero si tiene que memorizarlo, entonces probablemente use algo que no sea tan complejo.

Por lo tanto, es usted quien debe decidir qué es más probable: se roba su clave privada segura o no se adivina la contraseña tan segura (o se la adquiere de alguna otra manera).

Aquí hay una excepción: si en su pregunta quiere decir que almacenará contraseñas realmente largas, complejas y aleatorias en su archivo secreto en lugar de usar una clave privada, entonces probablemente haya una pequeña diferencia entre los dos todavía hay alguna diferencia (me he perdido la parte, vea la respuesta de @john para una buena reseña sobre esto ). En ese caso, ambos son algo que usted tiene , manténgalo en secreto , pero y luego pregúntese: ¿por qué hacerlo en primer lugar si eso es lo que diseñaron las claves privadas? ¿Para? debe permanecer con claves privadas en ese caso.

El documento al que se hace referencia está discutiendo las contraseñas escritas dentro de una sesión ssh; Creo que vale la pena, y los comentarios de Richard, pero ya no creen en la respuesta en sí. (Todavía prefiero las claves públicas).

Song, Wagner y Tian han demostrado que es es posible acelerar las búsquedas de contraseñas de fuerza bruta aproximadamente 50 veces usando información de tiempo de ssh session . Noack volvió a visitar su estudio y descubrió que SSH2 también es vulnerable al análisis de tiempo.

El ataque hace dos suposiciones:

• El hash de contraseña está disponible para craqueo por fuerza bruta.
• Un atacante puede obtener marcas de tiempo precisas en los paquetes enviados entre hosts, o de otro modo adquirir información de tiempo.

Las claves públicas no solo son más convenientes, sino también más seguras contra ciertas amenazas.

Si está utilizando claves de "software" (es decir, las claves almacenadas en su directorio .ssh o equivalente) está básicamente en el mismo nivel que el almacenamiento de contraseñas.

OpenSSH ahora tiene un soporte PKCS # 11 casi decente, el mismo está disponible en KiTTY (una bifurcación PuTTY), por lo tanto, para hacer un uso real de la autenticación de clave de acceso, elija una tarjeta inteligente. Entonces hay una diferencia real de las contraseñas. Un archivo de claves de software, protegido por una contraseña, puede replicarse de la misma manera que una contraseña simple, mientras que una tarjeta inteligente no puede.