viernes, 12 de julio de 2019

Serie: Cambiarse de Windows a Linux

Traicionando a Bill Gates. Cuando abandonas Windows por Linux 

|SSH y el Error: No Matching key exchange method found.



Cuando damos nuestros primeros pasos en el mundo de Linux tendemos a pensar que todo en el SO del pingüinito es complicado, y de hecho lo es si no tienes experiencia alguna con la Interfaz de Línea de Comandos (Command Line Interface, CLI) será como dar pasos a ciegas en una habitación llena de objetos de cristal, podrás ver todo pero tendrás miedo de tocarlo.

Dependiendo de la distro que elijas puedes pasar de tu interfaz de siempre llena de ventanas y accesos directos en la que resuelves todo con la ayuda de los clics de tu mouse, a teclear como un demente en tu nueva terminal, dañando varios archivos en el proceso de adaptación.

Pero cuando ya tienes cierta experiencia básica y consigues agarrarle cariño al uso del teclado para editar ficheros, descargar programas, actualizar repositorios y te sientes bien en la interfaz de tu distro Linux (bien sea Debian, Ubuntu, Mint, Fedora, CentOS, entre otras, muchas otras), y además eres un informático curioso, entonces querrás probarte a ti mismo y pasar tus métodos de trabajo tradicionales de Windows y darles una oportunidad en el ambiente del software libre. Esto fue lo que me pasó.

Soy un profesional de las tecnologías de la información (IT) y mi trabajo consiste en monitorear una gran red WAN, mayormente interconectada con dispositivos CISCO de última generación (y muchos otros de vieja escuela como los switch Catalyst 2900 y 3200). 

En mi trabajo siempre se ha usado Windows como SO base en la mayoría de los equipos, cosa que no es de extrañar dado que en latinoamérica el software privativo no es tan privado, y que además sigue siendo el SO más usado en todo el mundo y la gran mayoría de los usuarios del planeta tienen una relación muy dependiente con su Interfaz Gráfica (Graphical User Interface, GUI) "¿Qué haríamos sin nuestra barra de herramientas y nuestros accesos directos?".

Sin embargo y afortunadamente para mi, me encuentro dentro de ese selecto grupo de aficionados que les encanta aprender y no me quedo quieto con la plataforma que me ofrecen donde quiera que llego a trabajar, por lo que luego de dominar las herramientas del SO base, tiendo a buscar otras diferentes que me reten a configurarlas para conseguir experiencia y (aceptémoslo) para matar las largas horas de ocio que podemos acumular frente al PC.

Continuando con la historia, luego de pasar más de un año monitoreando mi WAN en ambiente Windows (porque eso era lo que había) y usando cantidad de clientes de Terminales (Putty, KiTTY, cmder, ConEmu) de los cuales preferí por practicidad ZOC Terminal (el porqué puede ser tema para otra publicación), llegué a un punto en que debía cortar relaciones con Windows y decidí darle paso a una distro Linux, básicamente por dos razones: la primera es que hacía tiempo que había dejado de usar Ubuntu y quería refrescar mis conocimientos y la otra porque profesionalmente si eres usuario Linux tu CV gana más peso, quieras o no los reclutadores lo ven así.

Como si de un par de zapatos nuevos se tratase, antes de adquirir mi nuevo SO tuve que visitar muchas tiendas (páginas). Pasé al modo investigador leyendo las características, propiedades y beneficios de muchísimas distribuciones de Linux, debo admitir que me costó al principio decidirme por una, igual que me pasa con los zapatos, tanto así, que sólo decidir cuál SO instalar me llevó un día entero de lectura en muchísimos blogs populares.



Cuando por fin, luego de pensarlo y analizarlo mucho, supe qué distro quería instalar, realizar el cambio fue cosa de minutos. ¿Mi primera elección? CentOS.

CentOS tiene toda esa reputación que en mi área de trabajo (dispositivos y servidores) garantiza que tendrás todo lo que necesitas para operar profesionalmente al máximo nivel, además de esa estabilidad que ofrecen las distribuciones basadas en Red Hat Enterprise Linux (RHEL). Ciertamente fue así, bastó empezar a manipular su interfaz para darme cuenta que no era tan compleja y que por defecto me ofrecía todas las herramientas preconfiguradas para mis tareas cotidianas monitoreando mi WAN. Cabe destacar que CentOS te da la opción durante la instalación de descargar los paquetes y repositorios que vas a necesitar según el área o entorno que desees, una opción súper útil si eres un usuario que sabe lo que busca en una interfaz.

Pero, y aquí viene lo complicado al elegir una distro que se adapte a ti (millenial) hoy en 2019: somos usuarios muy visuales. Windows y MAC tienen la culpa de eso al crear sistemas ridículamente intuitivos, pero cómo culparlos del todo si a todos nos agrada las facilidades de hacer pocos clics para conseguir realizar las tareas del día a día frente al monitor y nos encanta poder hacer todos nuestros deberes en una GUI de los más amigables visualmente, todo en pro de nuestras propias comodidades, es que si pudiéramos trabajaríamos desde nuestras casas sólo con nuestros smartphones y tablets, muchos incluso tienen esa facilidad ("los influencers" la tienen muy fácil).

Pero en el mundo IT no es tan simple, en este campo de batalla que es controlar dispositivos, aún dependemos demasiado de centrales, servidores, equipos de escritorio y terminales, falta mucho para que podamos tener una interfaz estilo Jarvis que nos convierta en usuarios tipo Tony Stark en los que controlemos todos los objetos a nuestro al rededor con la voz y gestos al aire. 

Cuando hacía mi investigación ya presentía que tendría que renunciar a algunas comodidades con CentOS. Este SO no suelta muchas actualizaciones entre upgrades, sino que suele sacar su SO completo cada tanto y cada otro pequeñas actualizaciones para los RPM y sin grandes cambios a la vista, de hecho su última versión, la 7.1611, fue en diciembre de 2016. Pero no reparé en lo más mínimo en restarle importancia a eso, su gran reputación en uso para administrar servidores me hacía pensar que podría ser completamente funcional para mi, como usuario local y más. ¡Ups! no fue así.

¿En qué me falló? pues que soy otro millenial que no puede vivir sin youtube ni redes sociales y que no voy a vivir con una impresora monocromática en pleno 2019.

Sí amigos, tuve demasiado problemas para visualizar videos con plugins HTML5 en CentOS porque, como les expliqué este no libera actualizaciones a diestra y siniestra como lo haría, por ejemplo Canonical con Ubuntu, que caen en lo fastidioso a veces. Leí que puedes instalar algunas librerías para solucionar los problemas al reproducir videos pero siendo honesto estaba perdiendo mucho tiempo tratando de solucionar algo que por defecto se encuentra en otros sistemas.

Mucha agua ha corrido por debajo del puente de la tecnología desde la última actualización de CentOS y el crecimiento desmedido de información digital ha forzado la creación de nuevos estándares que permitan la fluidez de información en mejoría de la calidad y la velocidad. En esto, muchas distros orientadas a servers se quedan  atrás, y no hacen mal del todo, porque si tienes un equipo para administrar redes y servidores, osea para trabajo ¿por qué lo vas a querer configurar como una PC perosnal? no tiene ningún sentido. Pero como dije, soy un curioso y yo quiero un SO Linux que me permita hacer de todo con mi máquina, no quiero tener que extrañar nada de mi viejo Windows.

Fue así como me permití seguir mi búsqueda de una distro buena y bonita (barata no porque, ajá, Linux...). En fin el siguiente en mi lista de pruebas es desde el cual hoy escribo esta publicación LINUX MINT. 

Debo decir que la comodidad fue inmediata, Linux Mint posee una interfaz muy agradable y lo mejor fácil de customizar según tus gustos, yo estoy en la onda de los Modo Oscuros (Dark Mode) me parecen lo mejor que le puede pasar a tus ojos si tu trabajo es pasar hasta 12 horas seguidas frente a un monitor, es más me hace cuestionar ¿por qué pasamos tantos años con fondos blancos y grises? y Mint te ofrece un gran poder de customización que te permite sentirte realmente a gusto con el look que le das a tu interfaz.



La Terminal se puede adaptar a tus preferencias de visualización, fácil de customizar, te permite hacer cambios en el color de fondo y de texto, contiene atajos de teclado muy útiles. Utilizarla es sencillo con sólo tener la experiencia básica en Linux.



Ahora, para mí existen varios factores indispensables para realizar el trabajo y que mi SO debe tener. La parte profesional que quiero que funcione a la perfección porque no me gusta perder el tiempo ni sentir que estoy limitado y son los temas que iré desarrollando en mis primeras publicaciones. Los siguientes programas y equipos son aspectos con los que usualmente no tendrías ningún problema en Windows o MacOS, pero que en Linux pueden tener un poco de resistencia.

  • SSH y otros programas de conexión remota y almacenamiento compartido (Telnet, ftp, etc)
  • Impresión, suena simple pero con algunas distros puede ser un dolor de cabeza dependiendo del modelo y marca de la impresora.
  • Programas de edición de imágenes. Es un verdadero reto encontrar uno decente en Linux.
En lo que resta de esta publicación me centraré en explicar la instalación y configuración de SSH y en los problemas que tuve para lograr conectarme de forma remota a mi WAN. Los otros los abordaré en otra oportunidad.

SSH: Breve definición


SSH (Secure Shell) es ese protocolo que nos permite conectarnos y/o administrar nuestra red a través de una conexión remota y cifrada. Pensado como un reemplazo para el protocolo Telnet el cual, es considerado poco seguro al no poseer métodos de cifrado.

La mayoría de los SO, o por lo menos los que yo conozco, traen por defecto instalado el repositorio para cliente SSH el cual es utilizado desde la terminal de una forma muy simple para conectarte a tu host remoto.


Donde:

  • SSH: es el comando que invoca la función de conexión remota.
  • Usuario: es el nombre del usuario creado para realizar la conexión.
  • 123.123.123.123: representa la IP del equipo Host al que deseas conectarte.

Si tu red se encuentra bien y actualizada no tendrás ningún inconveniente y recibirás las respuesta de petición de contraseña de parte tu host.



Pero qué pasa si tu red tiene vulnerabilidades de cifrado? O se encuentra administrada por algunos viejos algoritmos de conexión? Pues Linux reconocerá dicha debilidad y no te permitirá realizar la conexión remota arrojando un error como el siguiente:

Unable to negotiate with 10.10.150.51 port 22: no matching key exchange method found. their offer: diffie-hellman-group-sha1



Este fue mi caso y no fue tan sencillo encontrar información en internet que explicara exactamente qué debo hacer para corregirlo, ¿qué extraño verdad?. Qué en pleno 2019 sea complicado encontrar un tema de lo que sea en internet y más si tiene que ver con tecnología o informática, pero así fue en este caso.

Por supuesto que hay muchos foros que tratan de explicar a qué se debe el error y qué se debe hacer para salir de este pequeño problema. Incluso la página de OpenSSH tiene una sección dedicada a tratar de aclarar por qué ocurre este problema y qué hacer para solucionarlo. En pocas palabras el cliente SSH en Linux impide la conexión remota con métodos de cifrados considerados débiles u obsoletos y por lo tanto no se encuentran habilitados por defecto en sus archivos de configuración.

La buena noticia (a medias) es que te explican qué hacer para reimplementar esos viejos algoritmos para que puedas acceder a tus dispositivos remotos. Pero cuando intentaba recrear las soluciones editando los archivos SSH y siguiendo paso a paso los tutoriales que leía, me encontraba con nuevos errores, era un verdadero fastidio. 

Aquí algunos de los sitios que visité:
Todos con buenas intenciones pero ninguno ofrecía una solución efectiva al problema, algunos eran usuarios que intentaban conectarse a un solo dispositivo remoto y vinculaban la IP del host al archivo de configuración y les funcionaba. Pero yo administraba una gran red que abarca más de 200 localidades a nivel nacional, me resultaba ilógico que tuviera que archivar la IP de cada dispositivo remoto, sería una locura de archivo.

Fue aquí donde empecé a frustrarme y acabé utilizando una opción de Google que muy pocas veces usamos, es más, una opción que siempre está a la vista pero que simplemente vemos como inútil, se trara de el botón de página siguiente en en el buscador.



Sí amigos, fui tras esos foros, blogs, vlogs y comentarios que nunca figuran entre el top de la primera página del famoso buscador de la G (y entre los cuales seguro estaré yo con mi blog próximamente), creo que lo más lejos que llegué fue la tercera o la cuarta "o" cuando comencé a atar cabos sueltos entre blogs y comentarios de distintas fuentes más un video random de un tipo que hablaba "suizo o alemán" según yo, y me dispuse a tratar de hallar sentido en lo que estaba haciendo, al punto de pensar que quizás el repositorio se había descargado de forma incorrecta (sí lo sé, nunca piensen eso de Linux).

Hasta que finalmente di con un video de 2018 que tiene muy pocas vistas y que fue determinante en mí para comprender qué estaba haciendo mal y qué debía hacer con el algoritmo que me daba error de conexión diffie-hellman-group-sha1. Muy buena explicación por parte de ese youtuber, todo el crédito es para él.

Solución a: Unable to negotiate with 10.10.150.51 port 22: no matching key exchange method found. their offer: diffie-hellman-group-sha1


En la mayoría de los foros que leí al principio te piden que edites solo el archivo del cliente SSH (ssh_config) que se encuentra en la ruta /etc/ssh/ssh_config pero nada hacemos modificando el cliente si no modificamos también el servidor, dualidad amigos míos, la clave de todo es esa dualidad cliente-servidor.



Donde:
  • Sudo: es el comando que invoca el modo administrador o root para hacer posible la configuración del sistema.
  • Vim: es el programa editor de archivos. Tú puedes usar el de tu preferencia (nano, vi, gpedit, etc)
  • /etc/ssh/ssh_config: es la ruta por defecto donde se encuentra el archivo de configuración del Cliente SSH y cuyos valores vamos a modificar.
Dentro del archivo de configuración vamos a agregar al final de las sentencias (OJO siempre al final para evitar cambiar parámetros ajenos al error que tenemos) los algoritmos legacy desactualizados, yo coloqué además del que tenía aviso de error, otros que también son versiones viejas sólo por si las dudas.

Lo que vamos a escribir es lo siguiente:


KexAlgorithms +diffie-hellman-group1-sha1,diffie-hellman-group-exchange-sha256,diffie-hellman-group14-sha1

Seguido de los distintos opciones de configuración llamadas Ciphers:


Ciphers +aes128-cbc,3des-cbc,aes192-cbc,aes256-cbc




Guardamos los cambios y abrimos el archivo sshd_confg que corresponde al demonio SSH (así también es llamado el server SSH y no entiendo porqué razón) y el cual es muy similar al del cliente excepto por esa letra "d" antes del underscore y cuya ruta es la siguiente /etc/sshd/sshd_config.



Donde, igual que en el paso anterior:
  • Sudo: es el comando que invoca el modo administrador o root para hacer posible la configuración del sistema.
  • Vim: es el programa editor de archivos. Tú puedes usar el de tu preferencia (nano, vi, gpedit, etc)
  • /etc/ssh/sshd_config: es la ruta por defecto donde se encuentra el archivo de configuración del Cliente SSH y cuyos valores vamos a modificar.
Dentro de este archivo de configuración vamos a agregar al final del las sentencias (igual que en el caso anterior siempre al final para evitar cambiar parámetros ajenos al error que tenemos) los algoritmos legacy desactualizados.

Lo que vamos a escribir es lo siguiente:


KexAlgorithms +diffie-hellman-group1-sha1,diffie-hellman-group-exchange-sha256,diffie-hellman-group14-sha1



Guardamos los cambios, salimos del editor y listo (recuerda estar consciente de qué editor estás usando para modificar estos archivos porque cada uno tiene sus maneras de ejecutar los comandos de guardado). Ahora y finalmente gracias a que hemos desactualizado nuestro cliente-servidor SSH podemos tener gestión remota de nuestra red nuevamente.


Para su consideración


Hay que tener en cuenta que con esta modificación no estamos mejorando nuestra red sino que más bien la estamos haciendo vulnerable a ataques de tipo Logjam y que la solución real sería actualizar nuestros servidores. OpenSSH (quienes se encargan de los repositorios para SSH en Linux) sólo deshabilitan los algoritmos que ellos recomiendan no usar por no tener cifrados suficientemente fuertes. Sé que en algunos casos la decisión de actualizar servidores puede escapar de nuestras manos, pero cuando sepamos bien a qué se debe este fallo en la conexión remota podemos alertar a nuestros compañeros sobre qué clase de cambios necesitamos para fortalecer nuestra red.

Lo importante es comprender lo que estamos haciendo y por qué sucede y no quedarnos con las simpleza de resolver y ya. Seamos mejores profesionales, aunque eso implique más trabajo y lo que considerábamos una pequeñez se vuelva una tarea más grande. 

Ahora, ¿porqué cuando usábamos Windows nunca tuvimos este inconveniente con not matching key exchange found? Esa es una explicación que los programadores de Redmond nos deben y que debemos agradecer a Linux por demostrarnos que nuestros protocolos de seguridad en nuestra red no eran los más confiables. Una razón de mucho peso para probar aunque sea una vez una distro Linux.

Espero les sea de utilidad la información y que hayan disfrutado la historia, seguiré con la serie de temas dedicados a Cuando cambiamos a Windows por Linux en otro oportunidad.

Nos leemos en la próxima!

Serie: Cambiarse de Windows a Linux

Traicionando a Bill Gates. Cuando abandonas Windows por Linux   |SSH y el Error: No Matching key exchange method found. C uando da...