Pangolin 1.19: SSH, RDP y VNC en el navegador sin cliente ni VPN

Llegar a un servidor remoto suele implicar el mismo ritual de siempre: abrir una terminal con tu cliente SSH, levantar un cliente RDP para esa máquina Windows, o tunelizar VNC a mano. Y si querés que el equipo entero pueda hacerlo, terminás armando una VPN, repartiendo claves y rezando para que nadie deje un puerto 22 expuesto a internet. Pangolin 1.19 propone otra cosa: que todo eso pase dentro de una pestaña del navegador, detrás de tu propio login con identidad. En esta review vemos qué hace de verdad, cómo se despliega en un servidor propio y dónde aparecen las fricciones.

Pangolin es una plataforma open source de acceso remoto que combina VPN y reverse proxy tunelizado sobre WireGuard, desarrollada por Fossorial. La versión 1.19, publicada en junio de 2026, agrega acceso remoto por SSH, RDP y VNC directamente desde el navegador como protocolos de recurso de primer nivel, con autenticación por identidad (SSO, PIN, geo-bloqueo, listas de IP). Se posiciona como alternativa self-hosted a Apache Guacamole. Está licenciada bajo AGPL-3 y una licencia comercial.

¿Qué problema resuelve el acceso remoto desde el navegador?

El acceso remoto tradicional tiene dos costos que rara vez se nombran: la distribución de clientes (cada persona necesita su cliente SSH/RDP/VNC instalado y configurado) y la superficie de exposición (puertos abiertos, túneles, una VPN que mantener). Pangolin centraliza ambos. En lugar de abrir el 22 o el 3389 al mundo, exponés un recurso a través de un proxy con identidad, y el usuario llega por una URL HTTPS común.

Lo nuevo de 1.19 es que ese recurso ya no tiene por qué ser una web. Ahora puede ser:

• SSH en el navegador: una terminal web real, con autenticación por contraseña, por clave o por la propia identidad de Pangolin, según cómo configures el recurso.
• RDP en el navegador: un escritorio remoto de Windows completo, con soporte de portapapeles y transferencia de archivos.
• VNC en el navegador: el display remoto renderizado dentro de la pestaña.

Sobre los tres aplican las mismas reglas de acceso por identidad: SSO, integración con proveedor de identidad, códigos PIN, geo-bloqueo, bloqueo por ASN y listas de IP permitidas. Esa es la diferencia que marca la documentación frente a un Guacamole pelado: no solo es acceso por navegador, es acceso por navegador con control de quién, desde dónde y con qué credenciales.

¿Cómo funciona la arquitectura de Pangolin?

Para entender la review hay que tener el modelo mental claro, porque define qué tan trabajoso es el despliegue.

• El servidor central (la cara pública): Pangolin corre típicamente en un servidor con IP pública —tu Cloud Server— y usa Traefik como reverse proxy, con el plugin Badger para enganchar la autenticación. Acá viven el dashboard y el control de acceso.
• El conector de sitio (Newt): en la red donde están tus máquinas instalás Newt, que abre un túnel WireGuard de salida hacia el servidor central. Como el túnel es saliente, hay NAT traversal y no necesitás abrir puertos de entrada en la red interna.
• El detalle clave de 1.19: para SSH, RDP y VNC no hace falta correr el conector en la máquina destino. Alcanza con instalar Newt en un host que tenga acceso de red al objetivo, elegir qué sitios lo enrutan y apuntar a cualquier servidor SSH, máquina Windows o display VNC. Es el mismo patrón que ya usabas para recursos HTTP.

El proyecto está mayormente escrito en TypeScript y, al momento de esta review, ronda las 21.4k estrellas en GitHub con un ritmo de releases alto (alrededor de 79 versiones publicadas). La última de la serie es la 1.19.2, de junio de 2026.

¿Qué es el nuevo modo Pangolin SSH y por qué importa?

Históricamente, hacer SSH "a la Pangolin" implicaba configurar un daemon de autenticación, tocar sshd_config y armar patrones de bastión. 1.19 introduce un modo Pangolin SSH que se saltea casi todo eso: las sesiones corren directamente sobre el host a través del conector, sin instalar servidor SSH ni configurar daemons.

En palabras de la documentación, el flujo es: seleccionás "Pangolin SSH" en el dashboard, te asegurás de que Newt corra como root en la máquina a la que querés acceder, y listo. A partir de ahí tenés doble vía:

• Recursos públicos: terminal por navegador en el FQDN del recurso.
• Recursos privados: acceso por CLI con pangolin ssh prod-app.internal, y transferencia de archivos sobre el túnel privado con pangolin scp ./config.yml prod-app.internal:/etc/app/.

Es cómodo, pero acá está la primera contra honesta: correr Newt como root en el host destino para habilitar este modo es una concesión de seguridad nada menor. Te ahorrás configurar OpenSSH, sí, pero a cambio le das privilegios totales al conector. En una máquina sensible, esa decisión hay que pensarla, no aceptarla por comodidad.

¿Cómo se instala Pangolin en un servidor propio?

El despliegue self-hosted se hace con Docker Compose o con el script de instalación oficial. El camino habitual es:

1. Un servidor con IP pública y un dominio: ahí va el stack central (Pangolin + Traefik + Badger). Conviene un Cloud Server con Ubuntu y el dominio apuntando por DNS.
2. Levantar el stack: con Docker Compose, siguiendo el instalador, que resuelve los certificados SSL automáticamente (Let's Encrypt vía Traefik).
3. Instalar Newt en cada sitio: en la red donde viven tus máquinas, para que abra el túnel WireGuard de salida.
4. Crear los recursos: desde el dashboard, eligiendo protocolo (HTTP, SSH, RDP, VNC), apuntando al destino y asignando una política de acceso.

Dos requisitos de versión que conviene anotar antes de tocar nada, porque si no coinciden el acceso por navegador no levanta:

• Newt 1.13.0 o superior: es el mínimo para RDP, SSH y VNC por navegador, y para el modo Pangolin SSH.
• Plugin Badger de Traefik en v1.4.1: la documentación marca esta versión como necesaria para el SSH por navegador en 1.19.

Si venís de hacer hardening manual de SSH, esto no reemplaza esas buenas prácticas: las complementa. Si te interesa el tema, en el blog tenemos como lectura complementaria "Hardening inicial de un Cloud Server Ubuntu: SSH, UFW y Fail2Ban" y "Cómo proteger SSH y Nginx con CrowdSec en Ubuntu".

¿Qué otras mejoras trae 1.19 además del acceso remoto?

• Auto-actualización de Newt: el conector chequea nuevas versiones, las descarga y se reinicia solo. Pangolin espera 24 horas tras publicar un release antes de que los sitios lo bajen. Importante: funciona solo con instalaciones por binario; en Docker o Kubernetes la actualización la maneja tu orquestador.
• Labels (etiquetas): tags de texto que se enganchan a sitios, clientes y recursos, pensados para filtrar y buscar en despliegues grandes.
• Resource policies: políticas que agrupan autenticación, SSO, PIN, asignación de usuarios/roles, geo-bloqueo y restricciones de IP. Varios recursos comparten una política base y cada uno puede sumar reglas extra de forma aditiva, sin pisar la base.
• Documentación de Helm y blueprints: guías de despliegue en Kubernetes con Helm y plantillas de Docker Compose precableadas a Pangolin para apps comunes self-hosted (Grafana, Jellyfin, Immich, entre otras).

¿Cuáles son los pros y contras reales de Pangolin 1.19?

A favor:

• Centraliza el acceso con identidad: SSO, PIN, geo y ASN sobre SSH/RDP/VNC es algo que un Guacamole básico no te da de fábrica.
• Cero clientes para el usuario final: todo pasa por el navegador, lo que baja el costo de onboarding de un equipo.
• Sin puertos de entrada: el túnel saliente de Newt con NAT traversal evita exponer 22/3389 a internet.

En contra:

• El stack no es liviano: necesitás VPS con IP pública, Traefik, el plugin Badger en la versión exacta y al menos un conector. No es un binario que tirás y anda.
• El modo Pangolin SSH pide Newt como root: comodidad a cambio de privilegios totales del conector en el host destino.
• Proyecto joven y de ritmo rápido: con decenas de releases, fijá versiones (de Pangolin, Newt y Badger) y leé el changelog antes de actualizar. La cobertura externa incluso detectó un link de changelog apuntando a una versión vieja —ruido menor, pero señal de que la documentación va detrás del código.
• Licenciamiento dual: el núcleo es AGPL-3 (copyleft fuerte, a tener en cuenta si integrás), y la edición Enterprise es comercial, gratuita para uso personal y para empresas por debajo de cierto umbral de facturación. Verificá en qué edición vive cada feature que te interesa.

¿Para quién es Pangolin y cuándo no conviene?

Conviene si administrás varias máquinas (Linux y Windows) y querés dar acceso a un equipo sin repartir clientes ni claves, con control de identidad real y auditoría de quién entra a qué. El caso ideal es el reemplazo de una mezcla de VPN + bastion + Guacamole por una sola pieza self-hosted.

No conviene si solo necesitás entrar a un servidor propio de vez en cuando: para eso, un SSH bien endurecido con clave y Fail2Ban es más simple y con menos superficie. Tampoco es la opción si no querés mantener un stack con reverse proxy, certificados y conectores, o si tu política de seguridad no tolera correr el conector con privilegios elevados.

Veredicto

Pangolin 1.19 da un salto concreto: convierte SSH, RDP y VNC en recursos de navegador con identidad, algo que antes implicaba pegar varias herramientas con cinta. La promesa de "sin cliente ni VPN" se cumple de verdad para el usuario final. El costo está del lado del que administra: hay que montar y mantener un stack no trivial, y el modo SSH simplificado pide un compromiso de seguridad (Newt como root) que no es gratis. Si ya tenés un Cloud Server con dominio y estás dispuesto a operar la pieza, es una de las propuestas open source más completas de acceso remoto unificado del momento. Como con todo proyecto de ciclo rápido: fijá versiones, leé el changelog y validá en un entorno de prueba antes de poner producción detrás.

Preguntas frecuentes

¿Pangolin es gratis?

La edición Community es gratuita y open source bajo licencia AGPL-3. Existe además una edición Enterprise con licencia comercial, gratuita para uso personal/hobbyista y para empresas por debajo de cierto umbral de facturación. Verificá en qué edición está cada función que necesitás.

¿Necesito instalar Newt en la máquina a la que quiero entrar?

No necesariamente. Para SSH, RDP y VNC por navegador alcanza con instalar Newt en un host con acceso de red al objetivo y apuntar al destino. El modo Pangolin SSH simplificado sí pide que Newt corra (como root) en la máquina destino.

¿Qué versión de Newt requiere el acceso remoto por navegador?

Newt 1.13.0 o superior. Además, el SSH por navegador en 1.19 requiere el plugin Badger de Traefik en la versión v1.4.1.

¿Pangolin reemplaza a Apache Guacamole?

Apunta a ese caso de uso. La documentación oficial lo posiciona como alternativa a Guacamole para acceso remoto por navegador, con la diferencia de sumar autenticación por SSO y reglas de acceso granulares por identidad.

¿Cómo se actualizan los conectores automáticamente?

Con la auto-actualización de Newt: el conector chequea nuevas versiones, las descarga y se reinicia solo. Pangolin espera 24 horas tras un release antes de que los sitios lo bajen. Solo aplica a instalaciones por binario; en Docker o Kubernetes lo maneja el orquestador.

¿Necesito abrir el puerto 22 o 3389 en mi red?

No. Newt abre un túnel WireGuard de salida con NAT traversal hacia el servidor central, así que no hace falta exponer puertos de entrada de SSH ni RDP a internet.

Fuentes: Notas de la versión Pangolin 1.19 (sitio oficial), repositorio fosrl/pangolin en GitHub, release 1.19.0 en GitHub y cobertura de Linuxiac.

Cloud Serversby Donweb

Todo el poder de la nube a tus proyectos y aplicaciones.
Alojamiento ultra rápido, escalable y con alta disponibilidad.

• Performance que te sorprenderá
• Rápida escalabilidad y sin limitaciones
• Arquitectura de alta disponibilidad
• Soporte experto y ejecutivos de cuenta
• Pagos en tu moneda y facturación local

Descubre la mejor solución de Cloud Hosting