Linux Sin Humo (Publicaciones sobre ssh)

Cómo Hacer Túneles SSH

sebelk — Mon, 18 Nov 2024 00:00:03 GMT

Una de las funcionalidades extraordinarias que posee openssh es la de encapsular el tráfico inseguro a puertos TCP. A continuación vemos algunos ejemplos útiles de cuándo y cómo utilizarlos.

Aaron Burden

Algunas suposiciones:

openssh-server.example.com: Es el host que posee el servicio ssh y el servicio sin cifrar
otrohost.example.com: Es un host que posee un servidor web sin TLS pero que carece de ssh.
192.0.2.1/24: Es la dirección IP del cliente ssh.
filtrado.example.com: Es un host que tiene el puerto del servicio al que queremos acceder pero se encuentra filtrado para el exterior.
casa.example.com: Es un host remoto respecto a un servidor ssh accesible desde la red de filtrado.example.com. Este host está en un lugar en el cual podemos trabajar cómodamente 😊 por fuera de la infraestructura de filtrado.example.com.

Caso 1: Redireccionado desde un puerto local a un puerto remoto para segurizar un servicio sin cifrar

Queremos segurizar el acceso a un servidor web sin TLS.

ssh -N -f -L 10001:localhost:80 openssh-server.example.com

80: Es el puerto que tiene el servicio sin cifrar
localhost: Es la dirección en el host servicio-remoto.example.com que escucha en el puerto 80.
10001: Es el puerto local al cual tendremos que conectarnos para obtener el servicio web.
-N No ejecuta comandos en el lado remoto.
-f El proceso va al segundo plazo antes de la ejecución de comandos.

El url que habrá que poner en el navegador es http://localhost:10001

Caso 2: Redireccionado desde un puerto local a un puerto remoto permitiendo el acceso al túnel usuarios de la misma red local para Segurizar un servicio sin cifrar

Queremos permitir que otros hosts de la red puedan acceder nuestro servicio encapsulado.

ssh -g -N -f -L 10001:localhost:80 openssh-server.example.com

-g Permite acceder a otros hosts de la red 192.0.2.0/24 acceder a el url http://192.0.2.1:10001/

Caso 3: Redireccionado desde un puerto local a un puerto remoto usando otro servidor ssh para acceder a un servicio sin TLS ni ssh

ssh -N -f -L 10001:otrohost.example.com:80 openssh-server.example.com

Aquí la url será http://localhost:10001

Caso 4: Crear un túnel en dirección inversa para acceder a un puerto SSH filtrado (utilización de un túnel remoto)

En este caso, queremos acceder al puerto SSH de filtrado.example.com, que no es accesible desde internet. Utilizamos casa.example.com con acceso SSH temporal para redirigir el puerto SSH de filtrado.example.com.

El comando debe ejecutarse en filtrado.example.com:

ssh  -N -f -R 9000:localhost:22 casa.example.com

22: Es el puerto SSH de filtrado.example.com.
9000: Es el puerto redirigido en casa.example.com.

Para conectarse al puerto SSH de filtrado.example.com desde casa.example.com:

ssh -p 9000 localhost

Caso 5: Redireccionamiento remoto para permitir acceso compartido a un puerto filtrado

En este caso, queremos redirigir el puerto SSH de un servidor filtrado (filtrado.example.com) hacia un servidor intermedio (casa.example.com) y permitir que otros hosts que están en la misma red local puedan acceder al túnel.

Comando para configurar el túnel:

ssh  -N -f -R 0.0.0.0:9000:localhost:22 casa.example.com

0.0.0.0:9000: Permite que el puerto redirigido esté accesible en todas las interfaces de red de casa.example.com.
localhost:22: Redirige el tráfico al puerto SSH de filtrado.example.com.

Para conectarse al túnel desde cualquier host con acceso a casa.example.com:

ssh -p 9000 casa.example.com

Requisito en casa.example.com

Habilitar GatewayPorts en /etc/ssh/sshd_config:

GatewayPorts clientspecified

Con esta configuración si el cliente no especifica explícitamente 0.0.0.0 al crear el túnel, los puertos siguen siendo locales por defecto.

Reinicia el servicio SSH:

sudo systemctl restart sshd

Notas de Seguridad

Si el servidor casa.example.com tiene una IP pública, usar firewalls para limitar el acceso al puerto 9000 y restringirlo solo a las máquinas necesarias. Para mayor seguridad, se puede especificar una interfaz específica en lugar de 0.0.0.0.

Troubleshooting

En todas las casos usar la opción -v para obtener realizar debugging. Recordar que dicha opcioń se puede usar múltiples veces para aumentar el detalle.

OpenSSH, X11Forwarding y Wayland

sebelk — Sun, 26 Apr 2020 11:33:41 GMT

Digamos que hay tres maneras de levantar acceder a la interfaz gráfica de un Linux remoto:

Photo by JJ Ying on Unsplash

Accediendo a todo el escritorio
Accediendo a una aplicación en particular
Conectándose a un administrador de login remoto

Una de las maneras habituales hasta hace relativamente pocos años era abrir aplicaciones gráficas de manera individual usando ssh usando la funcionlidad llamada X11Forwarding.

¿Qué es X11 Forwarding?

La mayoría estará de acuerdo con lo poco aconsejable que es usar Xorg en un servidor. Una alternativa menos riesgosa es instalar un programa cliente de X. En ese caso podemos usar el redireccionamiento X11 de ssh. De esta manera los datos viajan cifrados por la red y además, establecerá la variable DISPLAY en la máquina en la cual estamos usando el cliente ssh. Una de las cosas más ventajosas que tiene el redireccionamiento X es que host remoto no necesita un servidor Xorg real. El programa xauth en el host remoto simula que hay un servidor local ante sus programas clientes pero redireccionando la imagen en la pantalla del cliente ssh. Esto tiene un costado problemático: estamos abriendo un canal desde el servidor ssh al cliente ssh. Por eso es muy importante segurizar el servidor para minimizar los riesgos. El protocolo X es muy antiguo y como tal era muy laxo en cuando a la seguridad, de este modo imponía pocas restricciones en el acceso por red. Durante el paso de los años el Xorg se ha esforzado por reducir esos inconvenientes. De hecho cuando una aplicación remota se abre por ssh X la considera un cliente no confiable, impidiendo el acceso a recursos de clientes confiables.

El Problema

El X Window System o X11 nació en el año 1987, y en los comienzos de Linux se usaba XFree86, una implementación libre (aunque con una licencia considerada problemática). Pero en 2004 nació Xorg como un fork de XFree86 y desde ese momento reemplazó en general a su antecesor en el reinado de las interfaces gráficas de Linux. Sin embargo, algunas distribuciones en la actualidad ofrecen de manera predeterminada Wayland en lugar de Xorg. Kristian Høgsberg un desarrollador de Xorg y de gráficos del kernel Linux creó Wayland en 2008. El propósito de Wayland es proveer una alternativa que sea más fácil para desarrollar y mantener que Xorg. Aquí tenemos que recordar que es un compositor: se trata de un software que utiliza buffers de memoria para que la imagen tenga mejor calidad y de paso poder proporcionar ciertos efecto. Wayland es un protocolo para que un compositor pueda comunicarse con programas clientes y además una implementación de dicho protocolo. De esta manera, se dejan las funcionalidades esenciales para que las ejerzan los clientes.

Es así como llegamos a que Wayland tampoco tiene como propósito ofrecer el renderizado de aplicaciones remotas, es decir, no existe de manera predeterminada algo como WaylandForwarding. Los desarrolladores de Wayland dicen que podrías en cambio:

Usar un servidor de renderizado sobre Wayland con soluciones ya existentes ( vnc, rdp, Xorg) o desarrollar uno nuevo.
Usar y/o desarrollar un protocolo de renderizado remoto en un compositor de wayland.
Usar y/o desarrollar un compositor remoto aislado o una parte de un compositor de escritorio

GNOME está trabajando con el renderizado de aplicaciones remotas en Wayland y KDE aparentemente también con en su proyecto Plasma.

Una tubería como camino

Waypipe programa desarrollado por M. Stoeckl para eñ Google Summer of Code de 2019: es un proxy para clientes de Wayland. Lo interesante es que puede usar ssh para hacer un redireccionamiento de una manera muy sencilla:

waypipe ssh usuario@servidorssh

Ese comando ejecuta dos instancias, una en el cliente y otra en el servidor (es decir debe estar instalado en ambos hosts). La instancia de waypipe que se ejecuta en el servidor ssh simula ser un compositor wayland, y usa un socket Unix para que los programas puedan conectarse. El resultado final es que la aplicación remota se muestra en la pantalla local de wayland. Las pruebas que realicé sobre CentOS8 como servidor wayland y cliente ssh frente a un servidor Fedora 31 han sido satisfactorias.

Más que mil palabras

¿Querés ver un video con waypipe en acción? Lo podés ver a continuación:

Fuentes de Consulta y Más Recursos

Como autenticar en ssh con certificado

sebelk — Sat, 16 Nov 2019 08:39:00 GMT

En un servidor crear un par de claves para firmar claves de usuario.
cd /etc/ssh && ssh-keygen -f user_ca
Agregar en el archivo /etc/ssh/sshd_config:
TrustedUserCaKeys /etc/ssh/user_ca.pub
Reiniciar el servicio
systemctl restart sshd
Para lograr que los certificados que vamos a generar se puedan usar en otros servidores, habría que copiar en ellos la clave pública (user_ca.pub), agregar la misma línea y reiniciar el servicio ssh.
Copiar la clave pública del cliente ssh al servidor.
scp ~/.ssh/id_rsa_sergio.pub root@certserver:/etc/ssh/
Generar un certificado a partir de la clave pública.
ssh-keygen -s user_ca -I user_sergio -n sergio,root -V +52w id_rsa_sergio.pub
Copiar el certificado al host del usuario.
scp root@certserver:/etc/ssh/id_rsa_sergio-cert.pub ~/.ssh/
Autenticarse con el certificado del usuario.
ssh -i ~/id_rsa_sergio-cert.pub root@certserver

Enlaces útiles

Tutorial: Autenticación en SSH con clave pública | Mixturas Resilientes
OpenSSH certificates (Mención de honor para este host que es en el cual me basé para la presente guía)
8.3. Using OpenSSH Certificate Authentication

Tutorial: Autenticación en SSH con clave pública

sebelk — Fri, 08 Nov 2019 12:12:36 GMT

Este es un tutorial para que empecemos a usar claves públicas para autenticarnos. El único requisito es que hayamos ingresado a un servidor o host remoto con ssh. En nuestro ejemplo ese host tiene la ip 10.0.3.11.

i
¹

El uso de autenticación por clave pública, tal como vimos en el post anterior tiene la ventaja de no tener que ingresar usuario y contraseña. Esto puede ser útil en casos en que necesitemos realizar alguna tarea en un host remoto de manera no interactiva. Por ejemplo podríamos crear una tarea programada que ejecute todos los días un script de backup. Veremos paso a paso como conseguirlo. Lo primero que tendremos que hacer es generar un par de claves. Para ellos ejecutaremos el siguiente comando: ssh-keygen

Como se ve en la imagen de abajo se nos preguntará la ruta de la clave privada, aceptamos la predeterminada presionando la tecla Enter.

y además se nos pedirá una passphrase. La passphrase es una frase que sea fácil de recordar para uno mismo, pero a la vez difícil de adivinar para otros. El propósito es cifrar la clave privada. Si te estás preguntando ¿para qué hacer todo esto si de todas maneras tendré que ingresa una passphrase para autenticarme. La respuesta es que tenemos técnicas como veremos un poco más abajo, para evitar la necesidad del ingreso de la frase una y otra vez. Ingresamos la frase una vez después de la otra:

Esto generará dos archivos en el directorio ~/.ssh: id_rsa y id_rsa.pub que son la clave privada y la clave pública respectivamente. Como sus nombres lo indican la clave privada no debe compartirse, en cambio la clave pública es la que nosirve para identificarnos como usuarios frente a otros hosts y se puede compartir.

En este momento tenemos que copiar la clave pública al host que funciona como servidor ssh. La manera más fácil y ráṕida de hacerlo es con el comando siguiente:

Ingresamos la contraseña de root y luego presionamos la tecla Enter. Lo que hace este comando es agregar la clave pública del archivo id_rsa.pub al archivo /root/.ssh/authorized_keys del servidor ssh.

Ahora lo que hacemos es reemplazar la shell actual con el agente de ssh y re-ejecutando la shell bash. El agente de ssh será el encargado de guardar las claves privadas en memoria para que no tengamos que ingresar más de una vez la passphrase:

Luego ejecutamos el comando ssh-add:

Se nos pedirá la frase, la ingresamos y le damos Enter.

A través de este tutorial mencionamos varios conceptos que podés ampliar recurriendo a los siguientes enlaces:

Photo by Jametlene Reskp on Unsplash ↩

Guía Breve sobre ssh con clave pública

sebelk — Sun, 03 Nov 2019 21:33:32 GMT

La autenticación por clave pública nos permite loguearnos a un host sin necesidad de ingresar usuario y contraseña.

CMDR Shane

Descripción del método

Nociones fundamentales

El esquema se basa en criptografía de clave pública.
Usamos claves separadas para cifrar y descifrar.
Es imposible obtener la clave para descifrar a partir de la clave para cifrar
Solamente el cliente sabe la clave privada.

Funcionamiento

Desde el lado del cliente ssh creamos un par de claves (una pública y otra privada).
- Cada clave se guarda en archivo separado.
- Tenemos la opción en este momento de cifrar su clave privada mediante una frase de paso. La clave privada queda inutilizable si olvidamos esa contraseña.
- Desde el lado cliente copiamos la clave pública agregándola al archivo ~/.ssh/authorized_keys en su directorio de la máquina remota.
- Luego de esto, el usuario puede loguearse sin proporcionar la contraseña.
- Cuando nos logueamos, el programa ssh le dice al servidor que par de claves le gustaría usar para autenticar. El cliente verifica que tiene acceso a la clave privada y el servidor verifica que la clave correspondiente está autorizada para aceptar la cuenta.
- El servidor puede informarle al cliente los errores que impidan que la autenticación por clave pública se pueda usar exitósamente luego de que la autenticación se complete usando un método diferente.
- De manera predeterminada si falla el método por clave pública se usará otro método, como por ejemplo el de usuario y password.

Nota:La manera más conveniente de usar una clave pública es con un agente de autenticación que se encargue de guardar en memora las claves privadas descifradas y de esta manera evitar tener que ingresar una y otra vez la frase de paso correspondiente.

Archivos involucrados del cliente

Archivo	Descripción
/usr/bin/ssh	cliente ssh
/usr/bin/ssh-keygen	Generador de par de claves (una pública y otra privada). Con la opción -t se puede especificar el algoritmo
~/.ssh/known_hosts	claves públicas de los hosts a los que ya accedimos alguna vez
~/.ssh/id_rsa	(nombre predeterminado con algoritmo RSA)
~/.ssh/id_ecdsa	nombre predeterminado con algoritmo ECDSA
~/.ssh/id_ed2551	nombre predeterminado con algoritmo ED25519

Archivos involucrados del servidor

Archivo	Descripción
/usr/sbin/sshd	servidor ssh
~/.ssh/authorized_keys	Clave públicas de clientes autorizados

Formato de ~/.ssh/authorized_keys

El siguiente es un ejemplo de un archivo que contiene solamente dos claves pública:

ssh-rsa AAAAB3NzaC1yc2EAAAADAQABAAABgQCb96oGSIMquG5UGR6aFXtX6aHboMDS3Pkr8NOuLskabSnSzgUC8IGYvxn86W0xvcWGdVD+Qljl6h16ARFXGpCNWSxktl7TWMnbDn i5AZaJXETV1ZkB5ro5f33gEvaMcZel18X1FcE1RBEJG92ufOoIIastxYo+THU8TW0bwVG08/hHcPn+d9YYEwZ92b/sTQH3rtcvLrAtsSmI8flVc0M054Tmkhf15fXuVlPeYwqYhCWBT1JGg60Jn3ZrsQvD6di0KRBuw0icfeF1mdHnHSlrb7AhcNFs+kds1acWaE3cOINuKJmDHPmsyT6+wujnOx+3TCGVhGC8hm/8dizkALwks/1Zt5T1R8o/erOu8NFfzG3NvOB9dx9szbAHOxKiJ61FH6qOIUGj74xMNNGmCszz57g3JG8gfFe+zc7tlrvXgBIj1ZyY16JC6LkbYjUb5aXJQRLIPSe8XoAJU+UkxTjuXU7lCGnMPH0DjvvgLgpZYlWtL8zGqdu+ruMOE0S2N8= root@dublin.ireland.home

command="yum check-update" ssh-rsa AAAAB3NzaC1yc2EAAAADAQABAAABgQCb96oGSIMquG5UGR6aFXtX6aHboMDS3Pkr8NOuLskabSnSzgUC8IGYvxn86W0xvcWGdVD+Qljl6h16ARFXGpCNWSxktl7TWMnbDnCi5AZaJXETV1ZkB5ro5f33gEvaMcZel18X1FcE1RBEJG92ufOoIIastxYo+THU8TW0bwVG08/hHcPn+d9YYEwZ92b/sTQH3rtcvLrAtsSmI8flVc0M054Tmkhf15fXuVlPeYwqYhCWBT1JGg60Jn3ZrsQvD6di0KRBuw0icfeF1mdHnHSlrb7AhcNFs+kds1acWaE3cOINuKJmDHPmsyT6+wujnOx+3TCGVhGC8hm/8dizkALwks/1Zt5T1R8o/erOu8NFfzG3NvOB9dx9szbAHOxKiJ61FH6qOIUGj74xMNNGmCszz57g3JG8gfFe+zc7tlrvXgBIj1ZyY16JC6LkbYjUb5aXJQRLIPSe8XoAJU+UkxTjuXU7lCGnMPH0DjvvgLgpZYlWtL8zGqdu+ruMOE0S2N8= root@belfast.ireland.home

ssh-rsa es el tipo de clave
AAAAB3NzaC1yc2EAAAADAQABAAAegQCb96oGSIMquG5UGR6aFXtX6aHboMDS3Pkr8NOuLskabSnSzgUC8IGYvxn86W0xvcWGdVD+Qljl6h16ARFXGpCNWSxktl7TWMnbDnCi5AZaJXETV1ZkB5ro5f33gEvaMcZel18X1FcE1RBEJG92ufOoIIastxYo+THU8TW0bwVG08/hHcPn+d9YYEwZ92b/sTQH3rtcvLrAtsSmI8flVc0M054Tmkhf15fXuVlPeYwqYhCWBT1JGg60Jn3ZrsQvD6di0KRBuw0icfeF1mdHnHSlrb7AhcNFs+kds1acWaE3cOINuKJmDHPmsyT6+wujnOx+3TCGVhGC8hm/8dizkALwks/1Zt5T1R8o/erOu8NFfzG3NvOB9dx9szbAHOxKiJ61FH6qOIUGj74xMNNGmCszz57g3JG8gfFe+zc7tlrvXgBIj1ZyY16JC6LkbYjUb5aXJQRLIPSe8XoAJU+UkxTjuXU7lCGnMPH0DjvvgLgpZYlWtL8zGqdu+ruMOE0S2N8= es la clave pública codificada en base64
root@dublin.ireland.home es un comentario opcional
command=yum check-update en la segunda línea restringe el acceso permitiendo la ejecución de un único comando.
El contenido de este archivo debería tener permisos 0600 y el directorio ~/.ssh 0700.