Túneles SSH: ejemplos de configuración y uso

Concepto de operación de túnel SSH

La tunelización SSH le permite establecer una conexión cifrada entre dos computadoras a través de una red no segura. El túnel SSH se basa en la transmisión de paquetes TCP/IP desde el puerto de una computadora a otra, por lo que a veces esta tecnología también se denomina «Reenvío de puertos SSH».

Una ventaja importante de los túneles SSH es la facilidad de configuración: dado que la conexión se establece con el servicio SSH en el servidor, que en la mayoría de los casos ya se está ejecutando, no se requieren acciones adicionales.

Sintaxis

Al crear un túnel, puede utilizar dos modos principales: Local y remoto.

Para crear un túnel local, se usa el parámetro-L, y el comando puede verse así:

ssh -L local_port:local_host:remote_port remote_host

En lugar del nombre de host remoto, puede usar el par de direcciones user_ssh@ip_server, y si el comando ssh se ejecuta en nombre de un usuario que coincide con el usuario ssh, es suficiente especificar solo la dirección IP.

La sintaxis del comando de creación de túnel remoto es similar, pero usa el parámetro-R.:

ssh -R remote_port:local_host:local_port remote_host

Tenga en cuenta que la computadora que ejecuta el túnel remoto (cliente SSH) puede estar ubicada detrás de un firewall o puede que no acepte conexiones entrantes en absoluto. De esta manera, un túnel remoto puede proporcionar una conexión a una computadora inaccesible desde la red global. Por esta razón, los túneles remotos también se denominan a menudo túneles inversos.

«man ssh» puede obtener una descripción completa de la sintaxis del comando ssh utilizando el comando «man ssh».

Ejemplos de trabajo con túneles SSH

1. Conéctese al servicio en el servidor (túnel SSH local).

Digamos que un servicio de base de datos PostgreSQL se está ejecutando en un servidor con la dirección IP 1.2.3.4, escuchando en el puerto local 5432. No es posible conectarse a este puerto desde el exterior, pero el puerto 22 está abierto en el servidor, que está escuchando el servicio SSH (sshd). La conexión SSH está abierta para el usuario. En este caso, puede ejecutar el comando en el equipo local para acceder a la base de datos.

ssh -L 5555:localhost:5432 user@1.2.3.4

Ahora el puerto 5555 se reenvía desde la computadora local al puerto 5432 en el servidor y puede conectarse a la base de datos remota ejecutando el comando

psql -h localhost -p 5555

2. Remote port forwarding

Ahora compliquemos un poco la tarea. Supongamos «»que nuestra base de datos está instalada en un servidor sin acceso a Internet, por ejemplo, con una dirección IP «gris», pero queremos acceder a ella desde un equipo local con la dirección» blanca » 6.7.8.9 y un servicio SSH en ejecución. En este caso, puede ejecutar el siguiente comando en el servidor::

ssh -R 5555:localhost:5432 user@6.7.8.9

Después de eso, el puerto 5555 en el servidor se reenviará al puerto 5432 en la computadora local, lo que nos permitirá ejecutar el mismo comando psql.

«»Puede verificar la conexión en el servidor remoto con el comando» lsof-i-P-n | grep LISTEN » o «ss-nlpt»:

Las dos últimas líneas en la salida de este comando significan que el servidor está escuchando conexiones locales en el puerto 5555, como se esperaba.

Por supuesto, hemos dado el servicio PostgreSQL solo como ejemplo. De esta manera, puede organizar el acceso remoto a cualquier servicio, como un servidor web. Para organizar dicho reenvío de puertos, cambiemos un poco nuestro equipo.:

ssh -R 4433:localhost:4430 user@6.7.8.9

Aquí suponemos que un servidor web en una computadora con un cliente SSH escucha en el puerto 4430, al cual se reenvía el puerto 4433 desde el servidor remoto. Tenga en cuenta que, de forma predeterminada, solo se puede acceder al puerto 4433 desde la dirección IP local 127.0.0.1 (localhost). Para que los clientes de Internet se conecten a nuestro servidor web, podemos habilitar el reenvío de puertos a interfaces de red externas (GatewayPorts sí) en la configuración del servicio SSH (ssh_config). En este caso, los clientes deberán especificar el número de puerto en la barra de direcciones del navegador para iniciar sesión en el servidor web.:

https://6.7.8.9:4433

Para usar el puerto estándar 443 y no cambiar la configuración de SSH, también puede reenviar conexiones externas desde el puerto 443 al puerto interno 4433 utilizando un servicio de proxy, por ejemplo, nginx.

Para que el túnel SSH sea accesible después de reiniciar la computadora, es conveniente usar el servicio systemd en el lado que invoca el comando ssh-L o ssh-R. Para crear nuestro propio servicio, agregue un archivo en el directorio /etc/system/system, por ejemplo, ssh-tunnel.servicio con algo como este contenido:

[Unit]
Description=SSH tunnel
After=network-online.target
[Service]
ExecStart=/usr/bin/ssh -i /home/user/.ssh/ssh-tunnel-key -NT \
    -o ServerAliveInterval=60 -o ExitOnForwardFailure=yes \
    -R 4433:localhost:4430 user@6.7.8.9
RestartSec=15
Restart=always
[Install]
WantedBy=network-online.target

Aquí hemos especificado varios parámetros adicionales para iniciar el túnel:

  • i/raíz/.ssh / ssh-tunnel-key — especifica la ubicación de la clave SSH privada ssh-tunnel-key.
  • N – no ejecute el comando remoto.
  • T-deshabilitar el pseudo-terminal.
    -o ServerAliveInterval = 60 y-o ExitOnForwardFailure = yes son opciones que permiten reiniciar el servicio tras perder la conexión.
    Por lo tanto,el servicio ssh-tunnel se activará automáticamente cuando se inicie el servidor después de que la interfaz de red establezca una conexión (red-en línea.objetivo) y reiniciado después de una posible interrupción de la conexión.

Después de crear el archivo ssh-tunnel, debe ejecutar los comandos secuencialmente:

sudo systemctl daemon-reload
sudo systemctl start ssh-tunnel.service
sudo systemctl enable ssh-tunnel.service

Puede verificar el estado del servicio utilizando el método estándar.:

sudo systemctl status ssh-tunnel.service

SOCKS-servidor proxy y reenvío dinámico de puertos

SSH admite otra característica extremadamente útil que le permite obtener acceso seguro a los nodos de la red a través de una red insegura. Este modo a menudo se conoce como proxy SOCKS.

Supongamos que tenemos un servidor que ejecuta el servicio SSH y la dirección IP 1.2.3.4. El servidor tiene la capacidad de conectarse directamente a los recursos de Internet que nos interesan. En este caso, es suficiente ejecutar el siguiente comando en la computadora local:

ssh -D 8888 user@1.2.3.4

El parámetro-D aquí significa reenvío dinámico de puertos. Cuando una aplicación establece una conexión con el puerto 8888, se redirige a través de un canal seguro al servidor 1.2.3.4, y luego la aplicación usa el protocolo SOCKS para crear una conexión con el nodo deseado desde el servidor remoto.

Usar su propio servidor proxy SOCKS tiene una gran ventaja: cuando trabaja a través de SSH, puede ingresar contraseñas, códigos de acceso, números de tarjetas de crédito y otros datos confidenciales de manera segura, lo que se desaconseja encarecidamente cuando se usan servidores proxy públicos.

Múltiples túneles y conmutación de múltiples hosts

Para no crear conexiones separadas con el mismo servidor, puede crear varios túneles a través de una sola conexión especificando varios parámetros-L, por ejemplo:

ssh -L 5555:server1:5432 -L 4433:server2:4430 user@server3

En este caso, al acceder a localhost: 5555, llegaremos al servidor1:5432, y al acceder a localhost: 4433, la conexión se redirigirá al servidor2: 4430. En ambos casos, los servidores de destino se encuentran detrás del nodo servidor3.

Saltando entre anfitriones

Si su red está dividida en segmentos (subredes), puede usar la opción-J (Salto de proxy) para conectarse a una computadora fuera de su subred. Esta opción también es útil, por ejemplo, para acceder a servidores en la nube que se encuentran detrás de una NAT y no tienen acceso desde Internet.

La sintaxis del comando es muy simple:

ssh -J <servidor de salto> <objetivo remoto>

Dado que el servidor jump se usa para acceder a una subred privada, a menudo se lo denomina»bastión». En grandes infraestructuras, por razones de seguridad, se utiliza un servidor separado como bastión, que realiza una sola tarea: proxy de llamadas a servicios internos. Dichos servicios pueden ser servidores web, servidores DNS, servidores de correo, FTP y VPN,etc.

Si es necesario, puede haber varios servidores de salto, por ejemplo:

ssh -J host1,host2,host3 user@host4

En este caso, SSH creará un túnel hacia el servidor host4 a través de la cadena de servidores host1 host host3.

Vale la pena señalar que cuando se conecta a través de un servidor intermedio, se utilizan las claves de autorización de este servidor, y no la computadora desde la que se conectó. Para reenviar claves desde su computadora al servidor, puede usar la tecnología de reenvío de agentes SSH, por ejemplo, usando el parámetro-A (reenvío de agentes de autenticación ssh-agent):

ssh -A user@host

Nota de seguridad: al reenviar claves, los datos de autorización local no se almacenan en el sistema de archivos del servidor intermedio, pero aún están disponibles en las variables de entorno. Por lo tanto, no recomendamos utilizar ForwardAgent en servidores que no controle. Tampoco recomendamos utilizar el parámetro «ForwardAgent yes» en el archivo de configuración local ~/.ssh / config de forma permanente.

Seguridad de Túnel SSH

SSH se basa en la criptografía, un algoritmo para cifrar el tráfico que requiere claves especiales para descifrarlo. A pesar de la alta confiabilidad de este método, podemos recomendar algunas medidas de seguridad adicionales.:

  1. Deshabilitar el inicio de sesión con contraseña. Recomendamos encarecidamente utilizar una clave en lugar de iniciar sesión con una contraseña abierta.
  2. Deshabilitando el acceso root. El acceso remoto del superusuario, en caso de compromiso, le da al atacante acceso ilimitado al servidor. Es por eso que los robots que realizan ataques de Fuerza bruta primero intentan encontrar la contraseña de la cuenta raíz. Es fácil verificar esto al ver las entradas del registro del servicio SSH sobre intentos fallidos de inicio de sesión en casi cualquier servidor con acceso a Internet. Por lo tanto, en lugar del acceso raíz, recomendamos utilizar una conexión en nombre de un usuario sin privilegios, si es necesario, un miembro del grupo de ruedas especificado en el archivo sudoers.
  3. Limite los intentos de inicio de sesión SSH. Para reducir el riesgo de un ataque de fuerza bruta exitoso en el servidor, se recomienda utilizar nombres de usuario no estándar, así como limitar el número de intentos de autorización. Esto se puede hacer usando las herramientas SHH integradas, por ejemplo, reduciendo el valor MaxAuthTries en el archivo de configuración/etc/ssh / sshd_config, o usando herramientas externas como fail2ban.