Autenticación mutua del servidor SFTP

Autenticación en SSH

La autenticación toma dos formas principales, nombre de usuario y contraseña, y autenticación basada en claves.

También se realiza una verificación de autenticidad cuando el cliente se conecta al demonio SSH al confirmar que la clave pública de confianza no ha cambiado al comparar la huella digital que se encuentra en la base de datos de confianza known_hosts y lo que presenta el servidor. Si coinciden, la conexión continúa, los desafíos del servidor para la autenticación y, una vez validados, se establece la sesión completa.

¿Qué es la autenticación mutua?

Antes de hablar sobre SSH, hablemos sobre la autenticación mutua en una implementación típica. Una autenticación mutua TLS presenta certificados tanto para el servidor como para el cliente, lo que confirma la identidad. Esto se usa comúnmente en aplicaciones B2B, como los puntos finales de API. Esto proporciona los beneficios de PKI (cifrado en tránsito, comprobación de integridad y revocación a través de los respondedores de CRL y OCSP) al tiempo que proporciona autenticación de la identidad.

¿Qué hay de implementar eso en SSH?

Por defecto, esto no funcionará. El cliente SSH se conecta a un demonio SSH. Esto requeriría que el servidor tenga credenciales de cliente en el cliente. ¿Confuso? Demos un paso atrás.

Usuario (usted) - > Clave SSH - > Servidor

Este es un comportamiento normal. Queremos voltear eso y establecer confianza en el reverso:

Servidor - > Clave SSH diferente - > Usuario (Usted)

Esto es peligroso . Hay algunas razones por las que:

• El compromiso del servidor permitiría pasar a la red de escritorio corporativa, oa la red doméstica de un usuario. Cualquiera de las dos situaciones sería devastadora.

• Las ACL en la empresa no deben permitir que esto suceda. Esto hace que el giro y la extracción de datos sean mucho más simples para un atacante.

Conclusión

Esto es posible, pero rara vez se hace, y es peligroso.

Si ejecuta el siguiente comando en el servidor SFTP (asumiendo la ruta correcta)
ssh-keygen -l -f /etc/ssh/ssh_host_rsa_key.pub

Tendrá una salida similar a la siguiente:

2048 7c:d9:68:a7:de:ad:26:12:34:56:78:00:4a:9b:a2:b9 root@localhost (RSA)

Si guarda esta cadena de hash con su cliente, puede compararla en la primera conexión o si alguna vez encuentra el siguiente mensaje:

The authenticity of host 'localhost (::1)' can't be established.
RSA key fingerprint is 3e:34:de:ad:55:55:55:66:89:ab:41:de:ad:46:20:16.
Are you sure you want to continue connecting (yes/no)?

Luego puede comparar manualmente los dos hashes y si son diferentes, sabrá si no se está conectando al servidor correcto.

Nota: una vez que se haya conectado con éxito por primera vez, el cliente se encarga de esta comparación cada vez que se conecta y guarda esos datos en el archivo .ssh/known_hosts para la comparación.

Dicho esto, saber de antemano el hash de la clave del servidor permitiría al usuario del cliente verificar que se está conectando al servidor correcto.

Se define el método de autenticación hostbased en el protocolo ssh , que hace básicamente lo que es en la pregunta.

Este método debe permitirse explícitamente:

HostbasedAuthentication yes
EnableSSHKeysign yes

en ssh_config , pero también en el servidor (pero ciertamente no para todos, el nombre DNS validado es un buen comienzo):

Host *.trusted.example.org
    HostbasedAuthentication yes
    EnableSSHKeysign yes

y luego configure los hosts conocidos globales en los archivos known_hosts en el cliente y el servidor con claves públicas válidas de los pares (que básicamente sustituirán a authorized_keys ).

Lo último es /etc/shosts.equiv , que limita quién puede iniciar sesión y desde dónde.

No estoy diciendo que sea una buena práctica, segura ni nada, pero existe . Pero el uso de certificados ssh es un enfoque mucho mejor.