Cómo habilitar SSH, RDP y VNC en el navegador con Pangolin

Problema

En entornos auto‑gestionados es frecuente que los equipos necesiten acceso remoto a servidores o estaciones de trabajo sin instalar clientes pesados en cada máquina del equipo. La solución típica implica desplegar un cliente SSH, una aplicación RDP o un visor VNC, y gestionar credenciales separadas para cada protocolo. Cuando el acceso se hace a través de una VPN o de un túnel, la complejidad aumenta: hay que mantener servidores SSH en cada host, sincronizar claves, actualizar firewalls y, en muchos casos, los usuarios terminan pidiendo acceso a través del navegador porque no pueden instalar software adicional.

El patrón que se repite es la necesidad de exponer recursos de terminal y escritorio a través del navegador mientras se conserva una capa de autenticación basada en identidad y se evita la sobrecarga operativa de mantener servidores SSH/RDP/VNC tradicionales.

Causa

1. Dependencia de servidores de acceso
   Cada host necesita un daemon SSH, un servicio RDP o un proceso VNC activo. En infraestructuras dinámicas (contenedores, nodos efímeros) mantener esos servicios alineados con la política de seguridad es costoso.

2. Gestión de credenciales dispersas
   Los usuarios manejan claves SSH, contraseñas RDP y tokens VNC por separado. La falta de un punto único de control genera errores de sincronización y vulnerabilidades.

3. Falta de túnel unificado
   Cuando se usa una VPN tradicional, el tráfico de cada protocolo pasa por rutas diferentes. Si la VPN falla, el acceso a cualquiera de los recursos se corta simultáneamente.

4. Actualizaciones manuales de conectores
   Los agentes que hacen de puente (site connectors) suelen requerir actualizaciones manuales, lo que lleva a versiones desfasadas y a brechas de seguridad.

Solución

Adoptar un gateway de túnel basado en identidad que:

• Actúe como proxy inteligente para SSH, RDP y VNC.
• Permita definir recursos mediante una URL y los exponga directamente en el navegador.
• Utilice la autenticación del proveedor de identidad (OIDC, SAML, LDAP) para autorizar sesiones.
• Proporcione un modo “host‑exec” que ejecute comandos SSH sin necesidad de un daemon SSH en el host.
• Incluya un mecanismo de actualización automática del agente.

Pangolin implementa este modelo, pero la arquitectura es aplicable a cualquier herramienta que ofrezca un site connector con capacidades de proxy. Los pasos genéricos son:

1. Desplegar el conector en una máquina con acceso a la red interna. El conector debe ejecutarse con privilegios suficientes para abrir puertos de túnel (normalmente como root o con capacidades de red).
2. Registrar recursos en la interfaz de gestión del gateway. Cada recurso indica:
   • Tipo (ssh, rdp, vnc).
   • Host interno y puerto destino.
   • Política de acceso (grupos de usuarios, geo‑blocking, etiquetas).
3. Configurar la capa de identidad para que el gateway valide tokens JWT o SAML assertions antes de abrir el túnel.
4. Activar actualizaciones automáticas del conector, ya sea mediante un script de auto‑upgrade o mediante el propio mecanismo del gateway.
5. Distribuir URLs a los usuarios. Al abrir la URL en cualquier navegador moderno, el gateway establece un WebSocket seguro que transporta el protocolo elegido (SSH sobre xterm.js, RDP sobre Guacamole, VNC sobre noVNC).

Alternativas prácticas

Cuándo aplicar esta solución

• Entornos mixtos donde algunos nodos solo pueden ejecutar comandos y otros requieren escritorio completo.
• Equipos con políticas BYOD que impiden la instalación de clientes nativos.
• Infraestructura con alta rotación de hosts (K8s, autoscaling) donde mantener daemons SSH/RDP/VNC es inviable.
• Requisitos de auditoría que exigen registro centralizado de accesos y control de identidad.

No es la mejor opción cuando:

• Solo se necesita acceso a un único servidor y la sobrecarga de un gateway resulta innecesaria.
• La red está aislada y no hay posibilidad de exponer un punto de entrada HTTP/HTTPS.

Código

# 1. Instalar el conector (ejemplo con Pangolin)
curl -L https://github.com/fosrl/pangolin/releases/download/v1.19/pangolin-site-connector.tar.gz | tar xz -C /opt/pangolin
chmod +x /opt/pangolin/pangolin-site

# 2. Ejecutar como servicio (systemd unit simplificado)
cat <<EOF > /etc/systemd/system/pangolin-site.service
[Unit]
Description=Pangolin Site Connector
After=network.target

[Service]
ExecStart=/opt/pangolin/pangolin-site --config /etc/pangolin/site.yaml
Restart=on-failure
User=root

[Install]
WantedBy=multi-user.target
EOF

systemctl daemon-reload
systemctl enable --now pangolin-site

# 3. Crear recurso SSH (CLI del gateway)
pangolin resource create \
  --name prod-app-ssh \
  --type ssh \
  --host 10.0.2.15 \
  --port 22 \
  --policy team-devops

# 4. Crear recurso RDP
pangolin resource create \
  --name win10-rdp \
  --type rdp \
  --host 10.0.2.20 \
  --port 3389 \
  --policy team-it

# 5. Activar actualizaciones automáticas
pangolin site update --auto true

Verificación

1. Conexión SSH

   • Abre https://gateway.example.com/resource/prod-app-ssh en el navegador.
   • Debería aparecer una terminal basada en xterm.js. Ejecuta whoami y verifica que el usuario corresponde al token de identidad.

2. Conexión RDP

   • Navega a https://gateway.example.com/resource/win10-rdp.
   • Aparecerá la interfaz de Guacamole; inicia sesión con las credenciales del dominio. Verifica que el escritorio responde.

3. Actualizaciones

   • Ejecuta pangolin site status y revisa la versión del conector.
   • Fuerza una actualización manual con pangolin site update --check. La versión mostrada debe coincidir con la última release.

4. Política de acceso

   • Intenta acceder con un usuario fuera del grupo team-devops. El gateway debe devolver un error 403 antes de abrir el WebSocket.

Notas adicionales

• TLS obligatorio: el gateway expone los recursos vía HTTPS; cualquier intento de usar HTTP será redirigido o bloqueado.
• Persistencia de sesiones: los navegadores cierran la sesión al cerrar la pestaña; si necesitas reconexiones automáticas, habilita la opción “reconnect” en la configuración del cliente web.
• Límites de ancho de banda: RDP y VNC consumen más tráfico que SSH. Monitorea el uso de la interfaz del conector y ajusta QoS si la red es compartida.
• Backup de políticas: exporta la configuración de recursos y políticas con pangolin export --output backup.yaml. Esto simplifica la recuperación ante fallos del conector.
• Compatibilidad de navegadores: xterm.js, Guacamole y noVNC requieren WebSocket y WebGL; versiones antiguas de Safari pueden presentar problemas de renderizado.

Con esta arquitectura el acceso remoto se vuelve tan simple como compartir una URL, mientras que la seguridad sigue centralizada en el proveedor de identidad y en las políticas del gateway. La clave está en tratar al conector como el único punto de entrada a la red interna y dejar que él maneje la traducción de protocolos hacia el navegador.