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

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

La mayoría de las guías para la configuración de OpenSSH recomiendan desactivar la autenticación de contraseña en 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 utiliza siempre con una contraseña segura, esto no debería suponer un riesgo para la seguridad. ¿O debería hacerlo?

Respuesta1

Existen ventajas y desventajas para la autenticación basada en contraseña o clave.

En algunos casos, por ejemplo, la autenticación basada en claves esmenosmás segura que la autenticación con contraseña. En otros casos, el sistema basado en pw 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,debeasegure su clave con una frase de contraseña. A menos que tenga ssh-agent ejecutándose (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, (...) - estos pueden ser más fáciles de romper o no.

Piense fuera de lo común al decidir esto. Si usted gana o pierde en términos de seguridad depende del resto de su entorno y de 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 primeroperoCambió el puerto de escucha SSH a algo diferente a 22. Eso detiene a todos esos tontos niños con scripts que fuerzan bruscamente rangos de red completos.

Respuesta2

El uso de claves 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 ~/.ssh/authorized_keysel archivo 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 combinar los dos:

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

Con las claves también puedes 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 haya terminado su trabajo, se podrá retirar la clave temporal.

Respuesta3

Puede obtener lo mejor de ambos mundos permitiendo únicamente la autenticación de contraseña desde dentro de 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

Respuesta4

Las claves ssh evitan ataques de intermediarios a su contraseña.

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

Su clave privada nunca se envía al servidor y cualquiera que escuche no puede hacer nada más que 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 llave USB. esto me permite:
retraer fácilmente esa llave en caso de que se pierda.
restringir a qué servidores me permite acceder
y aún así llevarlo consigo

aunque instalar el software de montaje es una molestia (truecrypt)

información relacionada