Revista Tecnología

Haciendo SSH a través de SSH. Rápido y fácil con ProxyCommand.

Publicado el 08 mayo 2017 por Gaspar Fernández Moreno @gaspar_fm

Haciendo través SSH. Rápido fácil ProxyCommand.Haciendo SSH a través de SSH. Rápido y fácil con ProxyCommand.
Como vemos en las películas de hackers. ¡Alguien ha conectado con el servidor y no podemos averiguar su IP porque ha estado rebotando a través de varios servidores! Bueno, yo me quejaría un poco de la velocidad de la conexión entre mi ordenador y el ordenador destino cuando paso por dos servidores intermedios. Pero puede ser un buen ejercicio. A la vez que útil cuando queremos ocultar el acceso a nuestro servidor o tenemos que acceder a un ordenador que está en una red privada.

En el primer ejemplo me refiero a un servidor cuyo acceso SSH está cerrado a todas las IPs exceptuando las de una red o una máquina concreta. Por ejemplo, podemos abrir el puerto SSH de nuestro ordenador de casa o nuestro mediacenter sólo a la IP de un servidor de nuestra propiedad. Así, cuando nos hagan un scan de puertos, el puerto estará cerrado. Pero cuando quiera conectarme desde fuera, primero tendré que conectarme a mi servidor y desde ahí conectarme al mediacenter de casa.

En el segundo ejemplo, imaginad que tenemos un servidor web conectado directamente a Internet, y un servidor de base de datos conectado al servidor web. Si deseamos acceder al servidor de base de datos desde Internet tendremos que entrar primero al servidor web y desde ahí acceder al servidor de base de datos. Bueno, este esquema de red lo podemos complicar mucho más. Además, esquemas parecidos nos los podemos encontrar, por ejemplo, en Amazon, cuando hemos creado una VPC con subred pública y privada y queremos acceder a las máquinas de la subred privada.

Pinceladas de seguridad

Antes de nada, os recomiendo este post sobre Consejos para endurecer un servidor SSH y hacerlo más seguro. Con muchas cosas a tener en cuenta a la hora de montar nuestro servidor SSH y aislarlo de posibles ataques desde fuera.
Otro detalle más, y muy interesante es que lo que pongo en este post debemos hacerlo siempre en servidores de confianza. Es decir, puede que tengamos acceso a un servidor SSH que hemos encontrado por Internet, que sea muy rápido y todo muy bonito. Pero al final, la clave privada de acceso al segundo servidor va a pasar por el primero para poder conectar. Como algún administrador de sistemas esté atento se puede quedar con tu clave privada y las claves privadas no se pueden dar a nadie.

Por otra parte, al conectar con un servidor intermedio y estar enviando una clave privada, si alguien intercepta el tráfico con el primer servidor y consigue descifrarlo podrá entrar en los dos servidores en nuestro nombre. Aunque son cosas difíciles de descifrar... todo es posible. Siempre es importante tener actualizado tanto el cliente como el servidor SSH en todos los puntos para que la negociación de protocolos elija siempre los algoritmos más seguros disponibles.

El método clásico. SSH, entro, SSH, entro

Lo primero que se nos puede pasar por la cabeza es hacer SSH en al primer servidor y una vez dentro hacer SSH al segundo. Esto es sencillo cuando tenemos contraseñas. Es decir, para entrar en el primero nos pide introducir contraseña y luego para entrar en el segundo también. Luego para cerrar la sesión, hacemos exit en el segundo y seguidamente exit en el primero.
Pero siempre se recomienda utilizar pares de claves pública y privada ( ver los consejos para endurecer un servidor SSH). Aunque ahora empieza a ser un poco incómodo porque conectar al primer servidor es inmediato. Ya que el servidor conoce nuestra clave pública podemos entrar directamente. Pero para entrar en el segundo servidor, es decir, nuestro destino, este segundo servidor tiene que tener la clave pública del primer servidor y el primero la clave privada correspondiente. Por lo que configurar un sistema así es arriesgado:

  • Por un lado, la clave privada de acceso al segundo servidor debe estar siempre en el primero. Cualquiera podría verla, sobre todo si el usuario dentro del servidor es compartido. Aunque no es una técnica recomendable, se utiliza.
  • Configurarlo todo es un rollo, y es muy fácil confundirse con las claves. Además, para copiar en el servidor no vamos a utilizar nuestra clave privada, utilizamos otra por si las moscas.
  • Acceder al servidor es lento, necesitamos ejecutar un comando intermedio. Y luego si no queremos sólo acceder sino que queremos copiar archivos, es mucho más lío copiar los archivos al primero y una vez copiados, copiarlos al segundo.

Otro método que podríamos utilizar. VPN

Otro método interesante sería crear una red VPN entre nuestro ordenador y el ordenador de destino. Pasaríamos por el servidor VPN y tendríamos la conexión cifrada. Sobre esa conexión estableceríamos la conexión por SSH y listo. Aunque tendríamos que tener de antes la VPN. De todas formas, el método que explicaré a continuación con ProxyCommand podríamos utilizarlo para entra en la máquina antes de tener la VPN montada.

Conectar con ProxyCommand

Este método ha sido inventado precisamente para conectar con un servidor intermedio. En este caso, hacemos que para conectar tengamos que ejecutar algo en el servidor intermedio. ¿Qué ejecutamos? ssh para conectar y nc (netcat) para que el primer servidor haga de puente. Veamos la línea de conexión más a fondo:

Con esto, hacemos que se utilize la opción ProxyCommand que justo antes de conectar hará ssh al intermedio.com (nuestro servidor intermedio) con el usuario usuario y seguidamente ejecutará nc al host y puerto con el que vamos a conectar. En nuestro caso el host sería final.com y el puerto 22 para SSH (aunque como veremos en futuros ejemplos, podremos variar estos puertos).

Perfectamente podríamos cambiar los puertos, por ejemplo SSH al puerto 221 para el servidor intermedio y el puerto 222 para el servidor final:

Conectando de esta forma, la clave privada no tiene por qué estar almacenada en el servidor intermedio todo el tiempo, ni tampoco tendríamos que añadir una clave pública extra al servidor final. Directamente las cogerá de nuestro directorio ~/.ssh/ local. Y ssh se encargará de hacer la negociación de claves y protocolos.

Esto también podríamos añadirlo en nuestro archivo ~/.ssh/config con la siguiente información:

Host final.com
ProxyCommand ssh -p221 [email protected] nc %h %p
Port 222

Ahora, haciendo sólo:

Conectaría automáticamente con el proxy. Es decir, sería transparente para nosotros y no tendríamos que especificar el ProxyCommand todo el rato para conectar. Aún así hemos de ser conscientes que se ejecuta un netcat en el servidor, es decir, en ese punto, la información está sin cifrar. Si alguien mete mano en el nc estamos perdidos. Por lo tanto, hacedlo siempre en servidores de confianza. Además, si se compromete el servidor intermedio, tal vez no se haya comprometido sólo la clave privada para el servidor final. Así que cuidado.

Transfiriendo archivos

Podemos hacerlo con scp. Si en nuestro ~/.ssh/config hemos hecho las modificaciones anteriormente mencionadas no habrá problema, podremos hacer scp sin mover un dedo. Pero, ¿cómo sería el comando para hacer scp?

Aunque lo interesante es hacerlo con que nos da muchas facilidades y ventajas frente a la transmisión con scp:

Aunque los argumentos -avhP no son estrictamente necesarios. Con rsync tengo siempre esta coletilla que me vale para la mayoría de los casos. Pero añadiremos -e con el comando para ejecutar ssh y tendremos que añadir toda la línea de conexión. Aunque, como antes, si lo tenemos configurado en ~/.ssh/config no hace falta.

Notas finales

Para realizar este tipo de conexión, debemos tener acceso al servidor intermedio y el servidor intermedio deberá tener acceso al segundo. Pero no es necesario que tengamos acceso al servidor final, es más, puede que no tengamos ping, puede que el servidor final, como dije al principio esté dentro de una red privada y el intermedio sea sólo el punto de entrada. Aunque lo pongamos en nuestro archivo de configuración (~/.ssh/config) podemos poner una IP privada a la que no tenemos acceso (siempre es mejor que los hosts tengan su nombre, pero no nos vamos a morir si no es así).
Pero insisto, el servidor intermedio sí que debe tener acceso.

Foto principal: Metropolitan transportation

También podría interesarte...


Volver a la Portada de Logo Paperblog