36 – SSH por web

Te doy la bienvenida al episodio 36 de deployandome, el podcast de tecnología para sysadmins y devops. Soy Rodolfo Pilas y estoy grabando el 5 de febrero de 2019.
Todos tenemos alguna aplicación o algún software que usamos preferente en nuestro entorno de trabajo, una aplicación que usamos más que todas las otras, una aplicación que define nuestro entorno de trabajo.
Programador – IDE de programación
Diseñador gráfico – Editor de fotos o vectorial
Dpto. contable – Planilla electrónica
Dpto. administración – Correo electrónico
Muchos – Navegador de Internet
Para mi es, sin dudarlo, el secure shell, el SSH.
Posiblemente por ese motivo le he dedicado muchos episodios de este podcast. La serie OpenSSH que se registra en el blog https://deployando.me tiene actualmente cinco episodios.
La cuestión que para mí sin SSH representa casi como estar “sin internet”. Estoy de manos atadas y no tengo casi condiciones de desarrollar mi trabajo.
De forma equivalente a cómo el mecánico de mi automóvil mantiene un tablero de herramientas con los perfiles dibujados en color llamativo de cada una de sus herramientas, para encontrarlas y ordenarlas más rápidamente, debo pensar y cuidar mi SSH: debo considerar distintos escenarios, debo hacer la curaduría de mis certificados de acceso y debo estar preparado para tener un SSH disponible cuando lo necesito.
Pero, algunas veces no tengo SSH, ni tengo mi notebook, ni tengo los certificados que requiero para acceder.
Por eso, en esta edición de depolyandome te voy a contar cómo hago para tener SSH cuando el ambiente donde me encuentro no permite disponer de SSH, es decir, una otra opción al SSH normal de mi notebook.

Como te decía, muchas veces debo conectarme a redes donde el SSH está completamente capado. A veces empeora, pues estoy frente a equipos que no son míos, no tienen un cliente SSH y, mucho menos, tienen los certificados que necesito para acceder al equipamiento que mantengo.
Pero si hay algo común a esos equipos y redes: en el 99% de los casos ese puesto de trabajo cuenta con un navegador y ese navegador tiene salida internet.
Entonces en lugar de intentar conectarme al servicio OpenSSH (puerto 22) puedo conectarme libremente (generalmente a través de proxy auditado) a los servicios web (puertos 80 y 443).
Así que por ahí comencé a pensar una solución a la falta de conectividad SSH.
Originalmente hice algunas pruebas colocando el servicio SSH escuchando en puerto 443, pero habían dificultades cuando tenía un proxy.
También pensé en tunelizar sobre HTTP el servicio SSH. Pero en ambos casos dependía de clientes instalados en los equipos que estaba utilizando.
Hasta que encontré un software libre llamado SHELL-IN-A-BOX que permite exportar el shell sobre un navegador web.
Es decir que ahora la terminal de mi Linux-box esta dentro de un navegador: es una página web, pues Shellinabox ofrece la emulación de terminal VT100 corriendo dentro de cualquier navegador actual ejecutando.
Shellinabox es un paquete que se instala como cualquier otro y levanta un servidor web sobre SSL en el puerto 4200/TCP y al que se accede con un navegador.
Obviamente, si busco una alternativa siempre accesible no podía dejar el puerto 4200 ya que estaría bloqueado en muchas redes o proxies, así que edité la configuración de Shellinabox y modifiqué el puerto por defecto al 443, reinicié el servicio y ahi quedó mi conectividad habilitada.
Shellinabox es un software libre licenciado mediante GPL escrito por Markus Gutschke desde el 2008 al 2012, y el paquete Debian instala la versión 2.20. Existe un fork (que dejo en las notas del podcast) que ha recibido varios aportes, fixes y mejoras del proyecto original.

De esta forma solucioné mi problema: tener un shell casi en cualquier lado, utilizando un navegador, hasta en un equipo de un hotel o un cybercafé. Dentro de ese shell puedo tener mis certificados SSH y las configuraciones (.ssh/config) para acceder a los servidores que mantengo.
Ahora abro el navegador, coloco una URL y veo el conocido prompt de login: y luego password: del shell de GNU/Linux.
Pero ahi me surgió un segundo problema: toda la seguridad de acceso a mis servidores (por más que accedo con certificados con passphrase) estaba expuesta a cualquiera que supiera mi login y password y conociera la URL accesible desde todo internet.
Así que implementé un segundo nivel de validación: agregando validación e clave única o como se suele llamar validación de dos pasos utilizando Google Authenticator, que también es paquete de la distribución Debian.
En el servidor de Shellinabox configuré el módulo PAM de google-authenticator únicamente para cuando se ingresa por Shellinabox, dejando el acceso de login de consola y el acceso por ssh directo sin la validación de dos pasos.
Respecto a google-authenticator instalé la aplicación en mi celular para el cálculo de la clave única cada ves que me la solicita. Así que ahora mi acceso por Shellinabox es login: -> password: -> verification code:
Pero como soy dependiente ahora de tener mi celular para ingresar, también me guardé varias claves atemporales de un solo uso, en un correo electrónico dirigido a mi mismo al que puedo acceder por webmail, en caso que no tenga mi celular.

Por último, y solo por un tema de delicadeza de la solución, el certificado de validación SSL que utiliza Shellinabox por defecto es autofirmado, por lo que requiere aceptar la validación la primera vez en el navegador que se está utilizando.
Para esto instalé y configuré un certificado Let’s Encrypt para que sea utilizado por Shellinabox. Si recuerdas, Let’s Encrypt fue el tema del primer podcast de Deployando.me.
Y con eso me quedó una solución a prueba de bloqueos, redes seguras y demás restricciones que a veces suelo encontrar en distintos ambientes o momentos. Por supuesto, que si no tengo ni acceso SSH ni acceso a WEB, ni por red del lugar, ni por red de móvil de mi tablet o mi móvil, es cómo si no tuviera Internet, como si estuviera en la isla de Lost y, en esos casos, creo poder prescindir de acceder a mis servidores.

En las notas del blog deployando.me, quedan enlaces a todos estos software que te he mencionado y a algunas guías de cómo se configuran.
Si tienes algún sistema de “contingencia” para acceder a tus servidores o tus infraestructuras me gustaría que lo compartas en los comentaros del blog, o con respuestas a los mensajes de Twitter de este episodio o en la noticia en Instagram.
Soy Rodolfo Pilas, en twitter me puedes seguir por @pilasguru y te dejo un saludo. Confío que este podcast te haya aportado para mejorar y, como siempre, espero tus inquietudes y sugerencias comentando en deployando.me
Hasta la próxima edición.
Referencias: Sitio oficial
Paquete Debian
Ubuntu Wiki
Fork shellinabox
Tecmint tutorial
Google-Authenticator
Pilas.guru Google-Autenticator