¿Cómo puedo conectarme por SSH con cifradores SHA1 antiguos en Ubuntu 20.04LTS?

Durante la forzosa estadía de exilio en la Quinta 17 de Octubre de Puerta de Hierro, Juan Perón expuso la necesidad de unificar criterios por parte del Comando Táctico en la Argentina y el Comando Estratégico. También ahondó en cómo reactivar los algoritmo SHA1 para establecer enlace SSH desde y hacia servidores antiguos, en Ubuntu 20.04LTS.

(...)

Vean señores,

Todo Conductor ha de poder definir políticas flexibles, pero lo escencial es que estos lineamientos puedan cumplirse con los medios de los que dispone. El rendimiento de los medios es el cual dicta la política, y no a la inversa. La explicación es lógica: una declamación política no puede cambiar el rendimiento fijo de los medios.

Este principio no se puede romper, es una de las bases nodales nodales de la conducción, y quien no siga este precepto caerá invariablemente en un voluntarismo: una mera declamación de hacer las cosas.

Deseos tienen todos: pero mejor que decir es hacer, y mejor que prometer es realizar

Tal es así que poco nos servirá dar una directiva de conducción y pretender establecer un corpus legal que la avale, si materialmente es imposible su cumplimiento.

Un ejemplo suele explicarlo todo, como decía Napoleón.

Es sabido que Ubuntu cuenta con una implemntación de Shell seguro que nos permite establecer enlaces remotos cifrados entre sistemas informáticos: el Secure Shell (SSH). Este esquema se basa en un modelo cliente-servidor ataviado de algoritmos matemáticos y fórmulados de cifrado preconvenidas, de forma tal de ofrecernos una protección el flujo de datos comunicacional. Lo hacen secreto.

Ahora bien, la versión SHA1 de este corpus directivo de cifrado daba en emplear una apilado de algoritmos que fue efectivo durante el primer peronismo. Pero el tiempo ha pasado y hoy, el comado de la conducción táctica lo ha evaluado como relativamente fáciles de vencer. Entre estos algoritmos se encuentra el ya inseguro diffie-hellman-group1-SHA1, el relativamente seguro diffie-hellman-group14-SHA1 cruzados con el conocido cifrador aes128-cbc. Las directiva política de seguridad del Comando Superior Táctico dispuso cambiar los esquemas de cifrado a versiones SHA2, anular el uso de group1-sha1 y promover el cambio de group14-sha1 toda vez que sea posible.

Este cambio político de adecuación a la nueva realidad percibida hizo que las versiones 19.04 y superiores de Ubuntu procedieran a desactivar por defecto el soporte del antiguo cifrado SHA1 del protocolo Secure Shell (SSH).

Naturalmente, esta política tiene el sentido deseado toda vez que contamos con medios de comunicación capaces de hacerla valer. Indudablemente tendrá un inconveniente insalvable si quisiéramos conectarnos a un servidor SSH antiguo de que disponen únicamente de los algoritmos y cifradores de la generación SHA1.

Por ejemplo, si me deseo utilizar el cliente OpenSSH de Ubuntu 20.04LTS para loguearme a un dispositivo que utiliza un servidor SSH superado con algorutmos SHA1, utilizando el comando de terminal:

ssh root@192.168.0.1

...recibiría de parte del cliente SSH un error similar al siguiente:

Unable to negotiate with 192.168.0.1 port 22: no matching key exchange method found. Their offer: diffie-hellman-group14-sha1,diffie-hellman-group1-sha1,kexguess2@matt.ucc.asn.au

Este mensaje explica que que nuestro cliente SSH se ha visto imposibilitado de utilizar los algorimos SHA2 más modernos con el servidor antiguo, y nos informa para poder lograr el enlace el servidor remoto nos oferta forzar la utilización de los algorimos antiguos SHA1. La oferta de los algoritmos específicos se dicta en orden de seguridad (primero el más seguro).

Siendo consecuencia que en Ubuntu 20.04LTS Focal estos algoritmos antiguos han sido por defecto desactivados, habremos de especificarlos en el comando de conexión SSH a fin de utilizarlos con el servidor antiguo. En este caso podríamos utilizaríamos la siguiente sintaxis el fin de dar uso a la versión "group14" del algoritmo SHA1:

ssh -o KexAlgorithms=+diffie-hellman-group14-sha1 usuario@host -p nro.puerto

...o bien podríamos probar conectarnos con la versión más antigua del cifrador SHA1 (con la gran penalidad en seguridad criptográfica que significa usar este viejo algoritmo):

ssh -o KexAlgorithms=+diffie-hellman-group1-sha1 usuario@host -p nro.puerto

Con este proceder ya deberíamos poder establecer el enlac al servidor SSH de generación SHA1. Debemos tener presente que el cifrado es antiguo (potencialmente inseguro).

En mi caso se trata de un enlace a un antiguo router. Lo ideal sería actualziar su firmware para instalar una versión más nueva de SSH en dicho aparato, pero en este caso no es posible hacerlo ya. Como no es cuestión de tirar todos los días un vuejo router por la ventana, al menos podremos establecer una conexión para confirgurarlo toda vez que sea necesario.

Ahora bien - por más que hayamos tenido éxito al conectarnos con el servidor SSH del router - el comando necesario para hacerlo es difícil de recordar, bastante molesto para tipear, máxime si lo necesitamos usar asiduamente. Por tal motivo si necesitamos usarlo en muchas ocasiones, nos resultará muy conveniente incluir los datos con las propiedades deseadas de la conexión SSH al archivo de configuración del cliente de conexión SSH: ~/.ssh/config.

Este es un simple archivo de texto donde podremos poner el o los servidores a los cuales deseamos conectarnos.Para editarlo desde la terminal del cliente ingresamos:

nano ~/.ssh/config

Al ingresar dicho comando se abrirá el editor GNU Nano con un archivo normalmente vacío. Cada entrada Host puede contener varias opciones, y podremos agregar más hosts también (siempre que estén separados entre sí por una línea en blanco). Un ejemplo podría ser:

Host router

Port 22

User root

HostName 192.168.0.1

KexAlgorithms +diffie-hellman-group14-sha1

En la línea HostName podríamos poner el nombre de red del host, o como en este caso, una dirección IP fija. Lo guardamos con Ctrl+o y salimos del Nano con Ctrl+x.

De ahora en más, toda vez que desde la terminal de nuestro usuario ingresemos:

ssh router

...nuestro cliente SSH intentará conectarse al servidor remoto como si usáramos el largo comando "ssh -o +diffie-hellman-group14-sha1 root@192.168.0.1 -p 22", y debería poder conectarse.

Esta funcionalidad suele ser lo único necesario de hacer para el caso de tener que conectarnos a un servidor remoto SSH mediante el protocolo de cifrado antiguo SHA1. Recordemos que si quisiéramos agregar otras entradas simplificadoras al archivo ~/.ssh/config, podremos hacerlo siempre y cuando dejemos una línea en blanco entre un Host y el otro. Naturalmente si omitimos una de las configuraciones, nuestro cliente OpenSSH interpretará que debe utilizar los valores por defecto y tomará dicho predicamento.

Por ejemplo, si queremos utilizar los cifradores modernos simplemente omitiríamos especificar la línea "kexAlgorithms", de la siguiente manera, y OpenSSH usará los algoritmos modernos por defecto.

Host mongoaurelio

Port 12345

User administrador 

IdentityFile ~/.ssh/mongoaurelio.key

HostName ssh.mongoaurelio.com

KexAlgorithms +diffie-hellman-group14-sha1

En base a esta entrada de Host, toda vez que ingresemos "ssh mongoaurelio", nuestro cliente intentará conectarse como si hubiésemos usado 

 

ssh administrador@ssh.mongoaurelio.com -p 12345

Con esto habremos podido solucionar de manera peronista el acceso desde un cliente SSH moderno como el que tiene Ubuntu 20.04LTS a un viejo servidor remoto SSH SHA1.

Pero la política, como he dicho, ha de ser sumamente flexible y omnicomprensiva. ¿Qué sucedería en el caso contrario, donde un viejo cliente SSH dotado únicamente con cifradores de la generación SHA1 anhele establecer contacto con nuestro moderno Ubuntu 20.04LTS, que acepta SHA2?

En tal caso. nuestro servidor SSH - por defecto SHA2 - lo rechazará. En dicho caso al ordenar lo siguiente al cliente remoto con...

ssh peron@ubuntu_focal

...el cliente antiguo con SHA1 podría informarnos:

ssh: Connection to peron@ubunru_focal:22 exited: No matching algo kex

...o bien:

Unable to negotiate with ubuntu_focal (ip xxx.xxx.xxx.xxx, port 22:

no matching key exchange method found.

En este escenario, el cliente SSH antiguo al verse rechazado no podrá conectar a Ubuntu 20.04LTS (o a cualquier servidor SSH más moderno que 2018, por poner una fecha referencial). Si deseamos que nuestro servidor SSH acepte dichas conexiones SSH provenientes de clientes con algoritmos antiguos, debemos autorizar dicha política reversora en el fichero de configuración del servidor SSH. Para ello, en el servidor SSH (Ubuntu 20.04LTS por ejemplo), ingresamos:

sudo nano /etc/ssh/sshd_config

Se abrirá el GNU Nano con el archivo de configuración, que ya tendrá contenido. Podremos utilizar la función "Buscar" (Ctrl+w) para buscamos la sección "#Ciphers and keying"

Recordemos que en todos los archivos de configuración, las líneas que comienzan con "#" serán siempre ignoradas por el sistema, y se pueden utilizar como "comentarios". A tal fin borraremos los # para que no sea ignorada la opción que queremos activar. Por ejemplo, si deseamos habilitar para que nuestro sistema autorice el algoritmo diffie-hellman-group14-sha1, quitamos los # en las líneas que le corresponden. 

En nuestro caso, como deseamos activar el más recomendado de los algoritmos antiguos diffie-hellman-group14-sha1 con el cifrador aer128-cbc, agregamos a continuación de las líneas:

#Ciphers and keying

#RekeyLimit default none

el contenido, como está a continuación:

## Descomentado para habilitar los ciphers para clientes SSH

## SHA1 antiguos. Provee seguridad reducida.

KexAlgorithms +diffie-hellman-group14-sha1

Ciphers +aes128-cbc

## Descomentar para que habilitar clientes SSH SHA muy antiguos.

## Provee seguridad muy reducida.

#KexAlgorithms +diffie-hellman-group1-sha1

#Ciphers +aes128-cbc

## Descomentar para habilitar los ciphers para clientes SSH 

## SHA1 extremadamente antiguos. Provee seguridad extremadamente

## reducida. Usar sólo para evaluar conexiones desde clientes

## SSH muy antiguos.

#KexAlgorithms diffie-hellman-group1-sha1,curve25519-sha256@libssh.org,ecdh-sha2-nistp256,ecdh-sha2-nistp384,ecdh-sha2-nistp521,diffie-hellman-group-exchange-sha256,diffie-hellman-group14-sha1

#Ciphers 3des-cbc,blowfish-cbc,aes128-cbc,aes128-ctr,aes256-ctr

Nota: naturalmente que si en lugar de diffie-hellman-group14-sha1 necesitamos usar otros menos seguros aún, podremos utilizar las otras líneas. Sin embargo, esto debe evitarse toda vez que sea posible.

Guardamos los cambios con Ctrl+o y salimos del editor Nano con Ctrl+x. Luego reiniciamos el servicio con:

service ssh restart

Es útil saber que en ciertos equipos GNU con Linux puede ser necesario directamente reiniciar el equipo ingresando

sudo reboot

Una vez reiniciado el sistema, ya los clientes remotos antiguos deberían poder conectarse con el algoritmo diffie-hellman-group14-sha1 y el cifrador aes128-cbc.