16 febrero, 2019

Plink SSH: Auto aceptar hostkey fingerprint al crear un túnel local port forwarding en SSH versión 2

Hostkey o fingerprint SSH

Cuando nos conectamos a través de un cliente SSH como PuTTY, por primera vez en una conexión se nos mostrará una alerta de seguridad indicando que el host key no está cacheado en el registro, no es más que la huella digital o fingerprint de la máquina remota a la que nos conectamos usado como método de confianza para garantizar la autenticidad de la máquina remota.

Esta host key al no estar registrada o cacheada por la máquina cliente que establece la conexión por primera vez, nos alerta de que no hay garantía de que el servidor remoto sea quien creemos que es.

ssh:ed25519 se trata de un esquema de firma digital EdDSA. Mantiendo la seguridad de otros esquemas con la principal ventaja de aportar más velocidad, más info aquí.

Figura 1: Alerta de seguridad - Host key de la primera conexión SSH.

Usando PuTTY las SSH host keys se cachean almacenándose en el registro de Windows.
HKEY_CURRENT_USER\Software\SimonTatham\PuTTY\SshHostKeys
En un tipo de valor de cadena (REG_SZ).

Figura 2: Registro Windows - SSH Host Keys de Putty.

Conexión SSH con Plink

Comentado lo anterior, vamos a ver entonces con Plink (utlidad de comandos de Putty) como podemos conectarnos por SSH estableciendo un túnel port forwarding auto aceptando el hostkey.

Pero que pasa si no tenemos una interfaz gráfica ni un Putty y solo disponemos de una terminal de comandos en la que podemos incorporar un Plink.

Cuando nos conectamos directamente al servidor SSH con Plink lo hacemos del siguiente modo.
plink <host_servidor_SSH>
De esta forma nos solicitará almacenar o no la hostkey en caché, sería la equivalencia a la ventana de alerta de seguridad de la hostkey que se muestran en las conexiones con Putty. Continuamos (y yes) almacenando la clave, nos pedirá usuario y contraseña. Y vemos que nos conecta al servidor remoto correctamente (independientemente de la mala interpretación en la codificación de caracteres).

Figura 3: Conexión estándar SSH con Plink (Putty).

Creando un túnel SSH port forwarding con Plink

Con Plink al igual que con Putty podemos crear un túnel SSH.
plink.exe -L <puerto_local>:<host_remoto>:<puerto_remoto> -P 22 -pw <password> <usuario>@<host_server_SSH>
De esta forma simplemente aceptaremos el cacheo de hostkey y tendremos el reenvío de puertos establecido en la conexión SSH.

Figura 4: Conexión túnel SSH port forwarding con Plink (Putty).

Hay un tip un poco "sucio" que es auto aceptar la host key con: "echo y | plink...". Quedando algo como esto.
echo y | plink.exe -L <puerto_local>:<host_remoto>:<puerto_remoto> -P 22 -pw <password> <usuario>@<host_server_SSH>
Figura 5: Auto aceptando hostkey ssh con "echo y | plink..."

Auto aceptar hostkey con Plink creando un túnel SSH port forwarding

Hasta aquí todo correcto. El problema de esto es si queremos conectarnos con un reenvío de puertos forzando una versión particular del procotolo SSH con plink, hay que especificar los parámetros: -ssh -2 (la versión SSH).

De este modo al intentar conectarnos por SSH estableciendo el reenvío de puertos para crear el túnel SSH. Y no tenemos la hostkey inicialmente cacheada en la máquina cliente, nos encontraremos con el siguiente problema.
Connection abandoned.
Disconected: Aborted at host key verification.
Conectándose de este modo, forzando la versión 2 del protocolo SSH, no aparece la solicitud y/n (si o no) para cachear la host key y directamente aborta la conexión.

Figura 6: Intento de conexión abortada con Plink especificando la versión 2 del protocolo SSH.

Aquí el truco sucio de "echo y | plink..." no funciona.

La única forma de auto aceptar el host key de una conexión con plink forzando a la versión 2 del protocolo SSH y que tenga establecido un port forwarding para el uso de un túnel SSH. Sería especificar el parámetro -hostkey seguido del fingerprint correspondiente.

La hostkey la podemos ver en una primera conexión, aunque esta no se establezca abortándose, igualmente se nos mostrará el fingerprint del host remoto correspondiente al servidor SSH.
plink.exe -ssh -2 -batch -v -L <puerto_local>:<host_remoto>:<puerto_remoto> -P <puerto_ssh> -pw <password> <usuario>@<servidor_remoto_ssh> -hostkey <hostkey_fingerprint>
Se especifica la host key correspondiente al servidor remoto SSH y vemos como la conexión se establece automáticamente.

Figura 7: Especificar la hostkey del servidor SSH cuando esta aún no está cacheada en el equipo cliente.

Probamos a conectarnos a través del túnel SSH creado. En este ejemplo era un reenvío de puertos del tipo local para una conexión RDP de Escritorio remoto.

Figura 8: Conexión RDP tunelizado por SSH.

Conexión establecida por RDP a través del tunelizado SSH. En una primera instancia auto aceptando la hostkey del servidor SSH cuando esta aún no está cacheada en la máquina cliente.

Figura 9: Conexión tunelizada por SSH - Conexión RDP establecida.

Saludos!

11 febrero, 2019

Resetear la password SSO Administrator@vsphere.local de VMware vCenter (VCSA)

Para resetear la password SSO del usuario "Administrator@vsphere.local" de vCenter. Accemos a la gestión del VCSA (vCenter Server Appliance) por el puerto 5480 con el usuario root y password.
https://IP-vCenter_o_hostname:5480
Una vez en el appliance de vCenter, en la sección de Acceso marcamos:
  • Habilitar inición de sesión en SSH.
  • Habilitar el shell Bash.
Figura 1: Habilitar el acceso SSH y Shell Bash para VCSA.

Nos conectamos por SSH al vCenter y habilitamos el uso de acceso a Shell Bash y entramos en la Shell.
shell.set --enabled true
shell
Una vez estamos en el Shell prompt ":~ #" ejecutamos vdcadmintool desde su ruta absoluta.
/usr/lib/vmware-vmdir/bin/vdcadmintool
Este ejecutará un menú de opciones, para este caso elegirémos la opción 3 "Reset account password". Establecemos la cuenta SSO "Administrator@vsphere.local" y nos generará una password aletoria. Con la opción 0 salimos del menú.

Figura 2: Resetear passworrd SSO Administrator desde vdcadmintool.

Accedemos ahora a vSphere Web Client.
https://IP-vCenter
Nos identificamos con el usuario SSO Administrator@vsphere.local y la password generada anteriormente.

Figura 3: SSO Administrator@vsphere.local vSphere Web Client.

Una vez logueados cambiamos la password por la que queramos establecer.

Figura 4: Cambiar password SSO Administrator@vsphere.local.

Por último podemos configurar que la password nunca expire. Configuración > Directivas > Directiva de constraseñas, editamos la directiva y establecemos a 0 días la duración máxima en la que la contraseña se debe cambiar.

Figura 5: Configurar que la password de SSO Administrator@vsphere.local nunca expire.

Saludos!

06 febrero, 2019

Habilitar virtualización anidada VT-x/AMD-V en Virtualbox cuando no se puede activar (nested virtualization)

[1] - Habilitar la virtualización a nivel de BIOS/UEFI en el host anfitrión. Opción VT-x (procesadores Intel) o AMD-v (procesadores AMD).

[2] - Comprobar que no haiga otro hypervisor (VMware o Hyper-V por ejemplo) usándose o con una mayor prioridad que no sea Virtualbox instalado en el host anfitrión.

[3] - La característica de viritualización anidad o nested virtualization en Virtualbox solo está disponible en versiones igual o superior a 6.0.

Esta característica es visible y se puede habilitar en: Sistemas > Procesador > Habilitar PAE/NX y Habilitar VT-x/AMD-V anidado.

En la siguiente screenshot se muestra como la característica es visible pero no nos permite habilitarla, pero esta opción se puede forzar para habilitarla en la máquina virtual seleccionada.

Figura 1: Caracteristica extendida - No es posible habilitar la virtualización aninada para la VM seleccionada.

[4] - Listar el nombre e ID de las VMs creadas con Virtualbox en nuestro host afitrión, esto lo haremos con la utilizada de comandos de VBoxManage.exe de Virtualbox. En el caso de Windows, desde una CMD accedemos a la ruta donde se encuentra este binario.
C:\Program Files\Oracle\VirtualBox
[5] - Listamos las VMs disponibles.
VBoxManage list vms
[6] - Modificamos la característica de la VM seleccionada, forzando así que se habilite la virtualización anidada con el parámetro --nested-hw-virt on.
VBoxManage modifyvm "Nombre-VM o {ID-VM}" --nested-hw-virt on
Referencia: https://docs.oracle.com/cd/E97728_01/F12469/html/nested-virt.html

Figura 2: Virtualización anidada habilitada para la VM seleccionada.

[7] - Si se habilitó correctamente la virtualización anidada podemos comprobarlo desde la VM seleccionada.

En el caso de usar un procesador Intel.
cat /proc/cpuinfo | grep vmx
En el caso de usar un procesador AMD.
cat /proc/cpuinfo | grep smv
Si todo a salido correctamente se debería mostrar contenido resultante que contiene "vmx" (en este caso de ejemplo se trataba de un procesador Intel). De no estar habilitada la virtualización anidada para la máquina virtual seleccionada no nos mostraría nada como resultado del cat.
 
Figura 3: Comprobación de que la virtualización anidada está habilitada en la VM seleccionada.

Saludos!

30 enero, 2019

Túnel SSH port forwarding: Local, remote y dynamic [Explicado]

¿Qué es SSH?

ssh-tunnelingSSH (Secure Shell) es un protocolo de comunicaciones seguras entre dos sistemas usando una arquitectura cliente/servidor que permite a los usuarios conectarse a un host remotamente para su posterior administración. A diferencia de otros protocolos de comunicación remota como FTP o Telnet (Telecommunication Network), SSH cifra la sesión de conexión y la comunicación ofreciendo también una infraestructura de autenticación PKI (Public Key Infrastructure) para la conexión con el host remoto.

Para poder establecer una conexión a un host que tenga implementado el rol de servidor SSH es necesario disponer de un cliente SSH. El puerto por defecto de escucha del servicio SSH es el 22.

Una vez se disponga de una comunicación establecida al servidor SSH se pueden usar los protocolos SFTP (SSH File Transfer Protocol) o SCP (Secure Copy) para la transferencia segura de ficheros entre cliente/servidor.

¿Qué es un tunel SSH?

Es una técnica que consiste en encapsular un protocolo de red sobre otro o un determinado tráfico de red. En el caso de usar conexión SSH se trata de realizar esta técnica de forma segura añadiendo una capa de seguridad en la que los datos viajan de forma cifrada a través del túnel SSH, realizando un reenvío o redirección de puertos (port forwarding) desde una máquina local a otra remota (o viceversa) para establecer una comunicación a un recurso o servicio accesible solamente desde uno de los extremos de la red.

Suele usarse para conectarse a un servicio remoto que solo se tiene acceso desde la red local remota. A través de un cliente SSH nos podemos conectar a un servidor SSH remoto que tenga acceso a la red remota a la que queremos acceder, especificar un reenvío de puertos para establecer las conexiones a ese servicio y así poder ejecutarlo de forma local desde la máquina que inició la conexión SSH. El método más habitual suele ser el reenvío de puertos local.

¿Tipos de reenvíos de puertos? (port forwarding)

  • Reenvío de puerto local (Local por fortwarding)
  • Reenvío de puerto remoto (Remote port forwarding)
  • Reenvío de puerto dinámico (Dynamic port forwarding)

SSH Local port forwarding

Local (Redirección de puertos local): Reenvía un puerto local a un host remoto.

Si un servicio se ejecuta en la máquina remota en la que establecemos la conexión y queremos ejecutar este servicio en la máquina local que inicia la conexión, se puede acceder a este servicio de desde nuestra máquina local usando la dirección local de lookback (127.0.0.1 o localhost) haciendo referencia al puerto mapeado a través de la conexión de inicio de la sesión SSH.

Pongamos un escenario de ejemplo de una conexión local port forwarding de escritorio remoto RDP realizando pivoting a otro equipo dinstinto al servidor SSH.

Supongamos que estamos en una red A y queremos acceder por escritorio remoto a un equipo situado en una red B (192.168.0.10), pero que por restricción del Firewall de la red A solo podemos realizar solicitudes de conexión al puerto 22 de SSH y no al puerto 3389 del servicio RDP. Lo que podemos hacer es crear una conexión desde un cliente SSH desde la red A (172.16.0.20) a un servidor SSH situado en la red B (192.168.0.15), en esa conexión tendremos que especificar un port forwarding local en un puerto aleatorio (mayor del puerto 1024 para que esté fuera del rango de "puertos bien conocidos") por ejemplo el 9090 como puerto origen (puerto local) de la red A y la IP:3389 del equipo de la red B al que nos queremos conectar (192.168.0.10), después de establecer esta parametrización nos conectamos al servidor SSH de la red B para crear el túnel local.

En el host de la red A que estableció la conexión desde el cliente SSH (172.16.0.20) abrimos un cliente de RDP (mstsc Windows, rdesktop o Remmina en Linux) y nos conectamos a "localhost:9090". Esto redirigirá la petición del host localhost (172.16.0.20) del puerto 9090 al servidor SSH de la red B que a su vez este redirigirá la petición al host destino 192.168.0.10 hacia el puerto 3389 y así establecer la conexión RDP.

En el caso de querer conectarse a otro servicio o desde otro host que no sea el propio host que realiza conexión desde el cliente SSH se especificaría: "<host-remoto>:<puerto-remoto>".

Desde una terminal se usa el parámtro -L para port forwarding local.
ssh -L <puerto-local-escucha>:<host-remoto>:<puerto-remoto> <servidor-ssh>
ssh -L 9090:192.168.0.10:3389 mi.servidorssh.com
PuTTY - Local port forwarding SSH Tunneling.
Figura 1: PuTTY - Local port forwarding SSH Tunneling.
  • Cliente SSH (Red A): 172.16.0.20
  • Servidor SSH (Red B): 192.168.0.15
  • Host RDP (Red B): 192.168.0.10
Figura 2: SSH port forwarding - Túnel SSH local.

SSH Remote port forwarding

Remote (Reedirección de puertos inverso): Reenvía un puerto rmeoto a un host local.

Al contrario que una conexión de túnel local, si un servicio solo es accesible desde una máquina de la red local y se necesita tener conexión a el de forma remota. Se puede usar un puerto específico de escucha para conectarse a esa máquina remota y que esta nos proporcione el servicio a través de ella, pivotando posteriormente esa conexión a la máquina desde la que se inicia la sesión SSH.

Pongamos un ejemplo con los mismos hosts del escenario anterior de una conexión remote port forwarding de escritorio remoto RDP.

Supongamos que estamos en una red A y queremos ofrecer el servicio de escritorio remoto RDP situado en la red A (172.16.0.20), pero este servicio hacía este host solo solamente es accesible desde la red A y no desde otras redes externas. Lo que podemos hacer es crear una conexión con un cliente SSH desde el mismo host de la red A a un servidor SSH situado en la red B (192.168.0.15), en esa conexión tendremos que especificar un port forwarding remote en un puerto aleatorio (mayor del puerto 1024 para que esté fuera del rango de "puertos bien conocidos") por ejemplo el 9090 como puerto origen (puerto remoto) de la red B y la 172.16.0.20:3389 del equipo de la red A del que queremos ofrecer la conexión RDP (sería válido también localhost:3389 ya que se trata del mismo equipo local quien es el cliente SSH que establece la conexión), después de establecer esta parametrización nos conectamos al servidor SSH de la red B para crear el túnel remoto.

La idea es prácticamente la misma que el tunel local, la diferencia está en que la conexión se establece de forma inversa (reverse port forwarding)

En el host 192.168.0.10 de la red B abrimos un cliente de RDP (mstsc Windows, rdesktop o Remmina en Linux) y nos conectamos a "192.168.0.5:9090" (servidor SSH de la red A). Esto redirigirá la petición al puerto 9090 al host destino de la red B 172.16.0.20 hacia el puerto 3389 para establecer la conexión RDP.

En el caso de ofrecer otro servicio o desde otro host que no sea el propio host que realiza conexión desde el cliente SSH se especificaría: "<host-local>:<puerto-local>".

Directivas en el servidor SSH (/etc/ssh/sshd_config)

Para que el servidor SSH permita el conexiones de puertos de reenvío remoto es necesario habilitar principalmente la directiva GatewayPorts. Referencia: https://linux.die.net/man/5/sshd_config

AllowTcpForwarding

Especifica si se permite el reenvío de TCP, de forma predeterminada el valor está establecido a "yes".

GatewayPorts

Especifica si los hosts remotos pueden conectarse a los puertos reenviados para el cliente. De forma predeterminada, enlaza los reenvíos de puertos remotos a la dirección de loopback. Esto evita que otros hosts remotos se conecten a puertos reenviados. Por lo que para poder usarse para el reenvío de puertos remotos debe establecerse a "yes".

Desde una terminal se usa el parámtro -R para port forwarding remote.
ssh -R <puerto-remoto-escucha>:<host-local>:<puerto-local> <servidor-ssh>
ssh -R 9090:172.168.0.20:3389 mi.servidorssh.com
o también
ssh -R 9090:localhost:3389 mi.servidorssh.com
PuTTY - Remote port forwarding SSH Tunneling.
Figura 3: PuTTY - Remote port forwarding SSH Tunneling.
  • Cliente SSH y Host RDP (Red A): 172.16.0.20
  • Servidor SSH (Red B): 192.168.0.15
  • Client RDP (Red B): 192.168.0.10
Figura 4: SSH port forwarding - Túnel SSH remoto.

SSH Dynamic port forwarding

Dynamic (Redirección de puertos dínamico): Utiliza SOCKS.

Se comporta como un proxy SOCKS, suele usarse si nos necesitamos conectar a un software que espera un reenvío de SOCKS.

La idea es igual que cuando se establece un túnel local SSH. La diferencia es que los datos se enviarían a todos los destinos remotos. Para utilizar este tipo de conexión es necesario que la aplicación del cliente que se conecta al puerto local debe enviar tráfico mediante el protoclo SOCKS. En el lado del túnel del cliente se crearía un porxy SOCKS y la aplicación (por ejemplo un navegador web) utiliza el protocolo SOCKS para especificar donde debe enviarse el tráfico cuando sale del otro extremo del túnel SSH.

SSH creará un proxy SOCKS que escuchará las conexiones en el puerto 9090, al recibir una solicitud enrutará el tráfico a través del canal SSH establecido entre la red A (172.16.0.20) y la red B (192.168.0.15). Para ello, es necesario configurar la aplicación (navegador web) del host de la red A para que apunte al proxy SOCKS en el puerto 9090 en localhost. De ese modo estaremos saliendo con la conexión pública (si el mecanismo NAT está habilitado) a través de este navegador web como si estuviésemos en la red B.

Ejecutándolo desde un cliente SSH desde la red A. Desde una terminal se usa el parámtro -D para port forwarding dynamic
ssh -D <puerto-origen-dinámico-escucha> <servidor-ssh>
ssh -D 9090 mi.servidorssh.com
PuTTY - Dynamic port forwarding SSH Tunneling.
Figura 5: PuTTY - Dynamic port forwarding SSH Tunneling.

Proxy SOCKS navegador web.
Figura 6: Proxy SOCKS navegador web.
  • Cliente SSH (Red A): 172.16.0.20
  • Servidor SSH (Red B): 192.168.0.15
SSH port forwarding - Túnel SSH dinámico.
Figura 7: SSH port forwarding - Túnel SSH dinámico.

Repositorio Github: https://github.com/adrianlois/SSH-Tunnel-Port-forwarding

Saludos!
Entradas Relacionadas