Plink SSH: Auto aceptar hostkey fingerprint al crear un túnel local port forwarding en SSH versión 2

Hostkey o fingerprint SSH

Cuando nos conectamos a través de un cliente SSH como PuTTY, por primera vez en una conexión se nos mostrará una alerta de seguridad indicando que el host key no está cacheado en el registro, no es más que la huella digital o fingerprint de la máquina remota a la que nos conectamos usado como método de confianza para garantizar la autenticidad de la máquina remota.

Esta host key al no estar registrada o cacheada por la máquina cliente que establece la conexión por primera vez, nos alerta de que no hay garantía de que el servidor remoto sea quien creemos que es.

ssh:ed25519 se trata de un esquema de firma digital EdDSA. Manteniendo la seguridad de otros esquemas con la principal ventaja de aportar más velocidad, más info aquí.

Figura 1: Alerta de seguridad - Host key de la primera conexión SSH.

Usando PuTTY las SSH host keys se cachean almacenándose en el registro de Windows.

HKEY_CURRENT_USER\Software\SimonTatham\PuTTY\SshHostKeys

En un tipo de valor de cadena (REG_SZ).

Figura 2: Registro Windows - SSH Host Keys de Putty.

Conexión SSH con Plink

Comentado lo anterior, vamos a ver entonces con Plink (utlidad de comandos de Putty) como podemos conectarnos por SSH estableciendo un túnel port forwarding auto aceptando el hostkey.

Pero que pasa si no tenemos una interfaz gráfica ni un Putty y solo disponemos de una terminal de comandos en la que podemos incorporar un Plink.

Cuando nos conectamos directamente al servidor SSH con Plink lo hacemos del siguiente modo.

plink <host_servidor_SSH>

De esta forma nos solicitará almacenar o no la hostkey en caché, sería la equivalencia a la ventana de alerta de seguridad de la hostkey que se muestran en las conexiones con Putty. Continuamos (y yes) almacenando la clave, nos pedirá usuario y contraseña. Y vemos que nos conecta al servidor remoto correctamente (independientemente de la mala interpretación en la codificación de caracteres).

Figura 3: Conexión estándar SSH con Plink (Putty).

Creando un túnel SSH port forwarding con Plink

Con Plink al igual que con Putty podemos crear un túnel SSH.

plink.exe -L <puerto_local>:<host_remoto>:<puerto_remoto> -P 22 -pw <password> <usuario>@<host_server_SSH>

De esta forma simplemente aceptaremos el cacheo de hostkey y tendremos el reenvío de puertos establecido en la conexión SSH.

Figura 4: Conexión túnel SSH port forwarding con Plink (Putty).

Hay un tip un poco "sucio" que es auto aceptar la host key con: "echo y | plink...". Quedando algo como esto.

echo y | plink.exe -L <puerto_local>:<host_remoto>:<puerto_remoto> -P 22 -pw <password> <usuario>@<host_server_SSH>

Figura 5: Auto aceptando hostkey ssh con "echo y | plink..."

Auto aceptar hostkey con Plink creando un túnel SSH port forwarding

Hasta aquí todo correcto. El problema de esto es si queremos conectarnos con un reenvío de puertos forzando una versión particular del protocolo SSH con plink, hay que especificar los parámetros: -ssh -2 (la versión SSH).

De este modo al intentar conectarnos por SSH estableciendo el reenvío de puertos para crear el túnel SSH. Y no tenemos la hostkey inicialmente cacheada en la máquina cliente, nos encontraremos con el siguiente problema.

Connection abandoned.
Disconected: Aborted at host key verification.

Conectándose de este modo, forzando la versión 2 del protocolo SSH, no aparece la solicitud y/n (si o no) para cachear la host key y directamente aborta la conexión.

Figura 6: Intento de conexión abortada con Plink especificando la versión 2 del protocolo SSH.

Aquí el truco sucio de "echo y | plink..." no funciona.

La única forma de auto aceptar el host key de una conexión con plink forzando a la versión 2 del protocolo SSH y que tenga establecido un port forwarding para el uso de un túnel SSH. Sería especificar el parámetro -hostkey seguido del fingerprint correspondiente.

La hostkey la podemos ver en una primera conexión, aunque esta no se establezca abortándose, igualmente se nos mostrará el fingerprint del host remoto correspondiente al servidor SSH.

plink.exe -ssh -2 -batch -v -L <puerto_local>:<host_remoto>:<puerto_remoto> -P <puerto_ssh> -pw <password> <usuario>@<servidor_remoto_ssh> -hostkey <hostkey_fingerprint>

Se especifica la host key correspondiente al servidor remoto SSH y vemos como la conexión se establece automáticamente.

Figura 7: Especificar la hostkey del servidor SSH cuando esta aún no está cacheada en el equipo cliente.

Probamos a conectarnos a través del túnel SSH creado. En este ejemplo era un reenvío de puertos del tipo local para una conexión RDP de Escritorio remoto.

Figura 8: Conexión RDP tunelizado por SSH.

Conexión establecida por RDP a través del tunelizado SSH. En una primera instancia auto aceptando la hostkey del servidor SSH cuando esta aún no está cacheada en la máquina cliente.

Figura 9: Conexión tunelizada por SSH - Conexión RDP establecida.

Saludos!

Solución al problema de licencias de conexiones RDP entre Windows Server 2016 y Windows Mobile (RDM), Windows CE o versiones antiguas RDP 5.x / 6.x

Actualmente RDP (Remote Desktop Protocol) está en versión 10.x y versiones más actualizadas que incluyen importantes mejoras de seguridad. Mejoras como una mayor longitud de clave generada por el servidor de licencias RDS 4096 bits con un algoritmo de seguridad SHA256 soportando SSL/TLS y NLA (Network Level Authentication).

Versiones iguales o inferiores a RDP 6.x no soportan las características anteriores. El límite de longitud para las claves es de 2048 bits con algoritmo de seguridad SHA1 (Secure Hash Algorithm 1).

Esta clave se genera en base al método de activación de licencias del administrador de licencias de Escritorio remoto. Si el método empleado es "Web Browser" (Explorador Web) las claves de licencias, se pueden generar un requisitos más bajos que si lo activásemos con otro método, con una longitud de 2048 bits SHA1.

Si aún no tenemos activado el servidor de administración de licencias de Escritorio remoto y queremos tener la compatibilidad entre versiones más antiguas y actuales para establecer conexiones RDP. Seleccionamos la opción de activar por el método de conexión Web Browser.

En caso de que ya tengamos activado el servidor de licencias procederemos del siguiente modo.

En el servidor Windows Server 2016 que recibirá la conexión RDP desde el dispositivo Windows Mobile o Windows CE comprobamos que NLA esté desactivado.

Figura 1: Desactivar NLA (Autenticación a nivel de red) en Windows Server 2016.

⚠️ Hay que tener en cuenta que desactivar NLA implica riesgos de seguridad
Seth: Ataques MITM a conexiones RDP y mitigación

Añadir un rol de instalación de Servicios de Escritorio remoto para VDI (Virtual Desktop Infraestructure).

Figura 2: Añadir rol de instalación de RDS.

En este paso podría ser "Implementación estándar" o "Inicio rápidio".

Figura 3: Implementación estándar para el rol RDS.

Para este escenario será implementación de escritorio basada en sesión.

Figura 4: Implementación de escritorio basada en sesión.

Una vez agregados los servicios RDS. Creamos una colección y no dirigimos a ella.

Figura 5: Colección de host de sesión de Escritorio remoto.

Dentro de las tareas de colección de RDS configuramos las opciones de seguridad para conexiones RDP.

• Nivel de seguridad de protocolo de Escritorio remoto (RDP).
• Nivel de cifrado: Bajo.
• Deshabilitamos NLA.

Figura 6: Configuración de opciones de seguridad para conexiones RDP.

Como comentaba al principio, si elegimos un método de conexión basada en Explorador Web. No es necesario realizar ninguna otra acción y las conexión RDP entre Windows Mobile o Windows CE y Windows Server 2012/2016 estarán funcionales.

De igual modo, seleccionamos el método de conexión por Explorador Web o Web Browser y aceptamos.

Figura 7: Selección del método de conexión "Web Browser". 

Eliminamos los tipos de claves REG_BINARY correspondientes a las claves de certificado X509 del método anterior de licencias RDS. En el registro del servidor de administrador de licencias de Escritorio remoto.

HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Terminal Server\RCM

• Certificate
• X509 Certificate
• X509 Certificate ID 
• X509 Certificate2

Figura 8: Eliminación de claves de licencias generadas por el administrador de licencias de Escritorio remoto.

¿Por qué eliminar estas claves de certificados del registro? 

Entre versiones de RDP actuales la longitud de clave de certificados es de 4096 bits con un algoritmo de seguridad SHA256, estas claves se generan en la primera instancia de conexión entre un acuerdo entre el nivel de seguridad compatible entre las dos máquinas que establecen la conexión RDP.

El equipo del usuario que mantiene la conexión con el servidor al que se conecta establece la longitud y algoritmo de esta clave, si el equipo que se conecta usa una versión de protocolo reciente no habrá problemas, pero si el equipo cliente se trata de un sistema Windows Mobile o similar este no podrá conectarse debido a que el servidor administrador de licencias no puede generar claves de una longitud y algoritmo inferior a los requisitos mínimos que establece el método de conexión (figura 7), por ese motivo el método de conexión Web Browser tiene unos requisitos menos restrictivos y puede generar claves de longitud más corta y cifrados de menor nivel.

Conexión establecida

Como equipo cliente para este ejemplo usaré un Windows XP SP1 que dispone de versión RDP v5.x (funcionaría igual para Windows Mobile, Windows CE o similares con versiones RDP v5.x o v6.x).

Vemos como la conexión RDP se estableció correctamente. En ese momento Windows XP SP1 estableció el acuerdo de certificados X509 de conexión. Si añadimos la desactivación de NLA y el nivel de cifrado más bajo sin SSL/TLS, la conexión es posible.

Figura 9: Conexión RDP establecida entre versioens RDP antiguas y Windows Server 2016.

Saludos!