¿Por qué la autenticación de contraseña SSH es un riesgo de seguridad?

68

La mayoría de las guías para la configuración de OpenSSH recomiendan deshabilitar la autenticación de contraseña a favor de la autenticación basada en claves. Pero en mi opinión, la autenticación con contraseña tiene una ventaja significativa: la capacidad de conectarse desde cualquier lugar sin una clave. Si se usa siempre con una contraseña segura, esto no debería ser un riesgo de seguridad. ¿O debería?

Septagrama
fuente
2
Las contraseñas son autenticación de un factor que puede ser rastreado, adivinado y reproducido. Las claves son (posiblemente) de dos factores. Poder iniciar sesión desde cualquier lugar con solo un factor es inaceptable en algunos sistemas.
Alex Holst

Respuestas:

25

Hay ventajas y desventajas para la autenticación basada en claves o pw.

En algunos casos, por ejemplo, la autenticación basada en claves es menos segura que la autenticación con contraseña. En otros casos, su pw-based es menos seguro. En algunos casos, uno es más conveniente, en otros, menos.

Todo se reduce a esto: cuando realiza una autenticación basada en claves, debe asegurar su clave con una frase de contraseña. A menos que tenga ssh-agent en ejecución (ssh-agent le libera de ingresar su frase de contraseña cada vez), no ha ganado nada en términos de conveniencia. La seguridad es discutible: el vector de ataque ahora pasó del servidor a USTED, o su cuenta, o su máquina personal, (...) - esos pueden o no ser más fáciles de romper.

Piensa fuera de la caja al decidir esto. Si gana o pierde en términos de seguridad depende del resto de su entorno y otras medidas.

editar: Oh, acabo de ver que estás hablando de un servidor doméstico. Estaba en la misma situación, "contraseña" o "memoria USB con llave" siempre conmigo? Fui por el primero, pero cambié el puerto de escucha SSH a algo diferente a 22. Eso detiene a todos esos guiones cobardes que imponen la fuerza bruta a rangos de red completos.

romano
fuente
Cambiar el puerto SSH de 22 podría no ser una buena idea en muchos casos. adayinthelifeof.nl/2012/03/12/…
Tymek
75

El uso de las teclas ssh tiene una característica única en comparación con el inicio de sesión con contraseña: puede especificar los comandos permitidos. Esto se puede hacer modificando el ~/.ssh/authorized_keysarchivo en el servidor.

Por ejemplo,

command="/usr/local/bin/your_backup_script.sh", ssh-rsa auiosfSAFfAFDFJL1234214DFAfDFa...

permitiría solo el comando `/usr/local/bin/your_backup_script.sh" con esa clave en particular.

También puede especificar los hosts permitidos para la clave:

from="yourclient,yourotherclient", ssh-rsa auiosfSAFfAFDFJL1234214DFAfDFa...

O combina los dos:

from="yourbackupserver", command="/usr/local/bin/your_backup_script.sh", ssh-rsa auiosfSAFfAFDFJL1234214DFAfDFa...

Con las claves también puede otorgar acceso temporal a algún usuario (por ejemplo, un consultor) a un servidor sin revelar la contraseña de esa cuenta en particular. Una vez que el consultor ha terminado su trabajo, se puede eliminar la clave temporal.

Janne Pikkarainen
fuente
Consejo muy muy útil.
Sachin Divekar
3
Además, usar Keys es como tener una contraseña larga de 2000 caracteres (bueno, técnicamente es aún más segura) en comparación con lo que puede
ingresar
3
Dos consejos muy útiles acerca de la autenticación SSH, pero en realidad no responde a la pregunta para mí ...
MikeMurko
Si desea forzar a un usuario autenticado con contraseña a pasar por un comando específico, cambie su shell de inicio de sesión. Además, "conceder acceso temporal sin revelar la contraseña" es una muy mala idea. Hay cientos de formas diferentes de mantener el acceso para más adelante.
b0fh
El último párrafo solo responde a la pregunta IMO: las teclas permiten la revocación granular, mientras que con las contraseñas debe informar a todos que lo está cambiando.
Riking
48

Puede obtener lo mejor de ambos mundos si solo permite la autenticación de contraseña desde su red. Agregue lo siguiente al final de su sshd_config:

PasswordAuthentication no
Match Address 10.0.0.0/8,172.16.0.0/12,192.168.0.0/16
    PasswordAuthentication yes
MikeyB
fuente
7

Ha respondido parcialmente a su pregunta: cuantos más lugares pueda atacar el atacante, más posibilidades tendrá de entrar en su servidor por fuerza bruta (considere DDoS).

También compare la longitud de su contraseña con el tamaño de la clave (generalmente miles de bits).

Martin Vejmelka
fuente
44
96 bits de entropía significa una contraseña de 80 caracteres, si está escrita en inglés; 15 caracteres si es un galimatías aleatorio del conjunto de caracteres imprimible. ¿estás seguro de que tus contraseñas ssh son tan largas / fuertes?
MadHatter
3
Si tiene varias contraseñas con 96 bits de entropía que no serán vulnerables a los ataques del Diccionario, es probable que necesite usar algún tipo de software de administración de contraseñas de todos modos, por lo que perderá efectivamente el elemento accesible en todas partes del uso de contraseñas .
Nick Downton el
55
@SachinDivekar son 96 bits de entropía solo si se usan contraseñas aleatorias del conjunto [a-zA-Z], no si se trata de palabras en inglés.
Jaap Eldering
16
@NickDownton: puede tener una contraseña larga y agradable sin recurrir al software keypass. Algo así mywifesnameisangelaandshehasanicebuttes invunlerable a los ataques de diccionario, es muy fuerte y muy fácil de recordar, pero imposible de adivinar. Y viene con el bono si el brownie apunta si alguna vez necesita darle su contraseña a su esposa.
Mark Henderson
77
Lo siento, Mark, pero eso está mal. La frase de contraseña que da tiene 37 caracteres y, por lo tanto, aproximadamente 44 bits de entropía, que es más débil que 7 caracteres imprimibles al azar y es eminentemente atacable. Lea el artículo de Wikipedia sobre el trabajo de Claude Shannon para obtener más detalles, pero el resultado es que el inglés escrito es altamente predecible, por ejemplo, después de "mywifesname", la palabra "es" está casi garantizada. Para contraseñas seguras que involucran palabras, cuatro palabras aleatorias encadenadas juntas de un diccionario le darán unas posibilidades de 10 ** 23, que son aproximadamente 77 bits de entropía; Todavía no es genial, pero no está mal.
MadHatter
7

Cuando inicia sesión con una contraseña, transmite su contraseña al servidor. Esto significa que el operador del servidor puede modificar el SSHD para obtener acceso a su contraseña. Con la autenticación de clave pública, no pueden obtener su clave privada, ya que solo su clave pública va al servidor.

Ramon
fuente
2
Esto es especialmente relevante cuando se conecta al servidor incorrecto debido a un error tipográfico. Por ejemplo, en algún momento, .cg era un comodín que apuntaba a una sola máquina con ssh habilitado. Cada vez que usted escribe mal .CG para .ch, que terminaría la conexión a la caja y fugas de la contraseña ...
b0fh
@ b0fh de hecho. Por lo que puedo decir, esta es la única vulnerabilidad real introducida mediante el uso de contraseñas con ssh. Si alguien ya posee el servidor al que se está conectando, o puede falsificar las direcciones IP a las que se está conectando (MITM), ya ha perdido.
placas el
6

Las claves ssh evitan ataques de hombre en el medio en su contraseña

Cuando intente iniciar sesión con una clave, el servidor construirá un desafío basado en su clave pública y lo enviará a su cliente. que lo descifrará y construirá una respuesta apropiada para enviar.

Su clave privada nunca se envía al servidor y cualquiera que esté escuchando no puede hacer nada excepto interceptar esa única sesión.

con una contraseña tendrían tus credenciales.

Mi solución es tener una clave ssh portátil en formatos adecuados en una partición cifrada en una clave usb. esto me permite:
retraer fácilmente esa clave en caso de que se pierda.
restringir a qué servidores me permite acceder
y aún llevarlo

aunque instalar el software de montaje es un problema (truecrypt)

Tacticus
fuente
1
Esto está mal. Tan pronto como sepa la clave pública del servidor (lo que hace si la agregó a su caché y no obtuvo MITM'd en la primera conexión), es inmune a los ataques MITM. La autenticación basada en clave / contraseña no tiene nada que ver con eso. La contraseña nunca se envía de forma clara por cable, siempre se establece una conexión segura en la autenticación a nivel de máquina (cuál es su / mi clave pública) antes de la autenticación a nivel de usuario (cuál es su contraseña / demuéstrame que esta clave pública es tuya) .
Thomas
3
Thomas, en realidad muchas personas ignoran la advertencia sobre un cambio de huella digital. Pubkey auth garantiza la protección MITM incluso si la clave privada del servidor se ve comprometida de alguna manera o un humano escribe "sí" distraídamente: el atacante tiene que elegir entre no poder ver el tráfico y enviar una clave pública que no iniciará sesión, que es un ganar.
Score_Under
55
Y para el que responde: no es necesario usar truecrypt, las claves privadas openssh vienen con su propio cifrado opcional basado en contraseña.
Score_Under
5

Es una compensación, como dice @MartinVejmelka.

La razón por la que utiliza la autenticación basada en claves es que la clave está muy por encima del forzamiento bruto actual o futuro, por lo que debe provenir de su propia PC o tener la clave en una memoria USB o similar.

Una contraseña tiene los siguientes problemas:

  • Si es corto, puede ser forzado
  • Si es largo, se olvida fácilmente
  • Podría ser surfeado

Una clave tiene órdenes de magnitud más largas y no se muestra en ningún punto, por lo que evita estos tres problemas.

Rory Alsop
fuente
pero el uso de un archivo de clave agrega el problema de perder el pen drive, o cualquier almacenamiento que esté utilizando.
João Portela
1
en ese momento, la clave perdida se puede eliminar y se agrega una nueva clave. Con las contraseñas (especialmente las contraseñas compartidas), esto puede ser un dolor MAYOR e implica muchos gemidos.
SplinterReality
Una de mis contraseñas (recientemente jubilados): 08Forging2?seminal*^Rajas-(Posed/|. Se genera aleatoriamente pero no tengo problemas para recordarlo. Y buena suerte haciendo surf con los hombros o forzándolo con fuerza bruta.
finnw
1
@finnw Grapa correcta de la batería del caballo :-) security.stackexchange.com/q/6095/485
Rory Alsop
2

Buenos puntos mencionados aquí ya.

Lo que considero el mayor riesgo, dado que se ha ocupado de los conceptos básicos con una contraseña segura, es que muchas computadoras tienen instaladas keyloggers sin que el usuario se dé cuenta. Incluso hay personas que crean sitios enteros de utilidades útiles que contienen troyanos, por lo que puede pasarnos lo mejor de nosotros. Un keylogger, por ejemplo, enviaría por correo electrónico los detalles de inicio de sesión a un hacker que luego podría acceder fácilmente al servidor.

Norton me advirtió recientemente sobre la descarga del instalador de Zombee Mod (no el jar, el instalador) para agregar vuelo al jar de Minecraft. Miré los detalles y Norton enumeró muchas utilidades en este sitio que estaban marcadas como que contenían un troyano. No sé si esto es correcto o no, pero fue bastante específico con los nombres de archivo. También es un hecho conocido que los troyanos se colocan en (algunos) warez antes de que se distribuyan.

Tedd Hansen
fuente
2

Un beneficio potencial de SSH sobre las contraseñas es que si no especifica una frase de contraseña SSH, nunca tendrá que volver a escribir una contraseña ... su computadora es intrínsecamente confiable en el servidor porque tiene la clave. Dicho esto, generalmente siempre uso una frase de contraseña SSH, así que descarto ese beneficio.

Encuentro la mejor respuesta de por qué las guías de usuario a menudo recomiendan SSH sobre la autenticación de contraseña proviene del manual de Ubuntu para SSHOpenSSHKeys. Yo cito,

Si no cree que sea importante, intente registrar todos los intentos de inicio de sesión maliciosos que reciba durante la próxima semana. Mi computadora, una PC de escritorio perfectamente normal, tuvo más de 4,000 intentos de adivinar mi contraseña y casi 2,500 intentos de intrusión solo en la última semana. ¿Cuántas miles de conjeturas al azar crees que se necesitarán antes de que un atacante tropiece con tu contraseña?

Esencialmente, si tiene una contraseña sólida de alta longitud con puntuación, mayúsculas y minúsculas y números ... probablemente estará bien con la autenticación de contraseña. Además, si planea monitorear sus registros, y de todos modos no está haciendo cosas "súper seguras" en la red ... es decir, usándolo para un servidor doméstico. Entonces, por supuesto, una contraseña funciona bien.

MikeMurko
fuente
1

El método de autenticación Passwd es realmente inseguro (en mi humilde opinión). Con este mecanismo, la contraseña se transmitirá al servidor sshd (como ya ha dicho @ramon). Esto significa que algunas personas podrían modificar el servidor sshd para recuperar la contraseña. Con un ataque Man-In-The-Middle esto es muy fácil de lograr dentro de una red local.

Puede simplemente parchear el servidor sshd instalando este parche ( https://github.com/jtesta/ssh-mitm ). Use arpspoofy iptablespara colocar su servidor parcheado entre el cliente y el servidor sshd auténtico.

Deshabilite la autenticación de contraseña: abra el archivo de configuración /etc/ssh/ssh_configy agregue la línea PasswordAuthentication no.

Pioz
fuente
¿El cliente SSH no comprueba el servidor en busca de huella digital RSA? Después de enviar a este servidor en particular al menos una vez, se recordará su huella digital, por lo que en el caso de posibles ataques MITM, SSH iluminaría una advertencia, ¿no?
Septagram
1
Sí. Aparece la advertencia, pero debido a que el 99% del tiempo es causado por la reinstalación del sistema operativo, la configuración cambió, etc., la mayoría de los usuarios ignorarán la advertencia y continuarán.
Pioz
@Septagram Muchos proveedores de cuentas shell no tienen la costumbre de publicar la huella digital de la clave del servidor actual para los nuevos suscriptores, para la migración de cuentas de usuario a nuevos servidores, etc.
Damian Yerrick
-2

Puede omitir el con la -o StrictHostKeyChecking=noopción. Esto es muy útil cuando se usa ssh en un script de shell.

ssh -o StrictHostKeyChecking=no -o ConnectTimeout=10 -o PasswordAuthentication=no -o ConnectionAttempts=5 xxUser@xxxHost
arganzheng
fuente