Categoría: ssh

SSH-Vault: Cifrar y descifrar un fichero usando la clave ssh

Suelo pedir a mis alumnos que generen un par de claves SSH para darles de alta en alguno de los servidores que usamos en la asignatura (añadiendo la parte pública en el fichero de claves autorizadas, authorized_keys). Lo siguiente suele ser crearles una base de datos y un usuario con acceso a la misma. Aquí, el usuario necesita una contraseña. Para pasarles esta contraseña y otros datos privados, solía pedirles a su vez que me enviaran su clave pública GPG. Realmente, este último paso no es necesario… si disponemos ya de una clave pública SSH podemos usarla para cifrar y descifrar ficheros, muy fácilmente. Una de las formas más sencillas es mediante una aplicación de la línea de comandos, ssh-vault.com.

Para cifrar, usaremos el siguiente comando:

echo -n "mensaje a cifrar" | ./ssh-vault -k /ruta/a/clave/publica/id_rsa.pub create vault

Para descifrar, el receptor usará este otro comando:

./ssh-vault -k /ruta/a/tu/fichero/.ssh/id_rsa view vault

También podríamos haber evitado el uso de una aplicación extra, usando los comando ssh-keygen y openssl que seguramente ya tengamos (la «pega» es que un usuario Windows no las tendrá…):

Convertimos la clave pública ssh a formato PEM:

ssh-keygen -f ~/.ssh/id_rsa.pub -e -m PKCS8 > id_rsa.pem.pub

A continuación, ciframos el mensaje:

openssl rsautl -encrypt -pubin -inkey id_rsa.pem.pub -ssl -in myMessage.txt -out myEncryptedMessage.txt

El receptor usará también openssl para descifrar:

openssl rsautl -decrypt -inkey ~/.ssh/id_rsa -in myEncryptedMessage.txt -out myDecryptedMessage.txt

Fuente, cómo no, un hilo de discusión en SuperUser, una de las webs de la red StackExchange, la misma que alberga a StackOverflow.com

ngrok, o cómo resolver problemas a distancia

Llevaba unos cuantos días intentando resolver un problema de configuración de Apache a otra persona, por email. Me enviaba detalles del problema, pantallazos en algún caso y yo le respondía con posibles soluciones, comandos que debería ejecutar y ficheros de configuración que debería editar. Se trataba de una máquina local, detrás de un NAT. Tras muchas idas y venidas, no conseguíamos resolver y pensando en cómo solucionarlo, me encontré con una herramienta que me ha permitido hacerlo en 2 minutos, ngrok 🙂 Permite exponer puertos tras el NAT de forma muy sencilla, de tal forma que si expone por ejemplo el puerto 22, yo pueda conectarme de forma remota a administrar su máquina. Lógicamente debe haber confianza entre ambas partes, para evitar sustos de seguridad.

Para ello, la persona con el problema de configuración ha tenido que realizar los siguientes pasos:
Instalar openssh (si no lo tiene ya instalado):
$ sudo apt-get update
$ sudo apt-get upgrade
$ sudo apt-get install openssh-server

Poner en marcha openssh:

$ sudo service ssh start

Instalar ngrok (la aplicación que expone puertos tras el NAT)

Tras instalar, debe darse de alta: https://ngrok.com/signup
Una vez realizado ese paso,  ngrok le devolverá el comando a ejecutar para identificarse en ngrok. Algo como:
./ngrok authtoken XXXXXXX

Abrir el puerto 22 (ssh) al exterior: (magia!)

$ ./ngrok tcp 22
(Este comando te dará como resultado una dirección ngrok, que es la que tiene que enviar a la persona que le ayuda. Algo como:  tcp://0.tcp.ngrok.io:13011 )
La persona que le ayuda, en este caso yo 🙂  podrá conectarse así:
$ ssh -l usuario 0.tcp.ngrok.io -p13011

Lógicamente, la persona con el problema antes debe haberle enviado al ayudante un nombre de usuario y contraseña para conectar por ssh.

Una vez conectado, el ayudante puede abrir otras sesiones para tunelizar más puertos. Por ejemplo:

$ ssh -l usuario 0.tcp.ngrok.io -p13011 -L 8080:localhost:80

Ese comando permite tunelizar el puerto 80 de la máquina remota para dejarlo accesible a través del puerto 8080 de la máquina local. Es decir, si el ayudante en su navegador teclea ahora: http://localhost:8080 en realidad se estará conectando a través del túnel ssh al puerto 80 de la máquina remota (tras el NAT). Muy, muy interesante para permitir la administración remota de equipos. Lo dicho, en dos minutos he podido resolver así un problema que se estaba estirando ya unos cuantos días por la incomodidad de analizar el problema vía email…

perl: warning: Setting locale failed

Conectamos por ssh contra nuestro servidor, lanzamos un comando erróneo y aparte del mensaje de error el intérprete de comandos nos suelta el siguiente sermón:

# comando erróneo
perl: warning: Setting locale failed.
perl: warning: Please check that your locale settings:
	LANGUAGE = (unset),
	LC_ALL = (unset),
	LC_PAPER = "es_ES.UTF-8",
	LC_ADDRESS = "es_ES.UTF-8",
	LC_MONETARY = "es_ES.UTF-8",
	LC_NUMERIC = "es_ES.UTF-8",
	LC_TELEPHONE = "es_ES.UTF-8",
	LC_IDENTIFICATION = "es_ES.UTF-8",
	LC_MEASUREMENT = "es_ES.UTF-8",
	LC_TIME = "es_ES.UTF-8",
	LC_NAME = "es_ES.UTF-8",
	LANG = "en_US.UTF-8"
    are supported and installed on your system.
perl: warning: Falling back to the standard locale ("C").
ERROR: (algo relacionado con el comando erróneo)

Mmmh… ¿por qué? Pues porque en el fichero /etc/ssh/sshd_config tenemos una linea como la siguiente:

AcceptEnv LANG LC_*

Que viene a decir: las variables de entorno relacionadas con el idioma del usuario deben ser exportadas al intérprete de comandos destino de una conexión ssh. En mi caso, el soporte es_ES. El problema es que los paquetes de ese idioma en el servidor destino no están instalados… de ahí que Linux se queje amargamente.
Bueno, para evitarlo hay varias formas. La más sencilla: basta con comentar la línea en cuestión de /etc/ssh/sshd_config (añadiéndole un # por delante) y ¡listo!

Acceso a MySQL remoto vía Android y SSH tunneling

Otra receta, esta vez para poder acceder desde nuestro dispositivo Android a una DB MySQL remota protegida por un firewall que impide la conexión directa. Necesitaremos realizar 3 pasos:

1) Instalar Connect Bot (para la parte SSH que explicaré a continuación) y MySQL Connect (de Javier Romero).

2) Generar un túnel SSH que permita conectar el puerto 3306 del dispositivo Android al puerto 3306 de la máquina remota (vía túnel SSH, porque el puerto 3306 remoto, recuerda, está filtrado por el firewall)

Para ello, en Connect Bot mantenemos pulsada la conexión SSH que queremos tunelizar y en el menú contextual elegimos «Editar redirección de puertos». Ahí configuramos una nueva redirección así: (la traducción del primer campo está mal, debería poner ‘nombre del túnel’ o algo similar, no nombre del usuario)

Conectamos ahora normalmente con Connect Bot (como si de una conexión SSH normal se tratara). Internamente estará abriendo el túnel.

3) Abrir una conexión con protocolo MySQL desde el cliente Android (la aplicación que haga esto en principio no sabe que el puerto 3306 local es realmente un extremo del túnel SSH. Para la aplicación Android ese puerto corresponde a una BD MySQL local!) En la imagen adjunta, «tester» es el nombre de usuario MySQL que tengas configurado en la DB remota.

¡Listo! Ya puedes ver y editar tuplas y esquemas de tus tablas cómodamente desde tu tablet Android (desde tu móvil también, pero no tan cómodamente 😉

Receta rápida: evitar desconexión por timeout en ssh

Problema: El servidor ssh al que te conectas cierra la conexión cuando detecta inactividad del usuario. Como tienes varias ventanas y tareas abiertas a la vez, ese timeout hace que la sesión ssh se quede bloqueada cada dos por tres.

Solución: crear un fichero ~/.ssh/config con el contenido que indico a continuación. Ese fichero se leerá cada vez que iniciemos una conexión ssh con cualquier host. Lo que indicamos es que queremos lanzar un paquete a modo de señal cada 120 segundos (2 minutos), haciendo saber que seguimos conectados y que no queremos que nos corte la conexión. Si por cualquier razón el servidor no respondiera tras 3 intentos de envío de señal (2*3 = 6 minutos), se cancelará la conexión.

cat ~/.ssh/config 
Host *
    ServerAliveInterval 120
    ServerAliveCountMax 3