Escritorio remoto en GNOME: guía completa en Linux

Si trabajas con Linux a diario, tener un escritorio remoto bien configurado en GNOME marca la diferencia: puedes administrar servidores, ayudar a otros usuarios o seguir trabajando en tu equipo aunque no estés delante de él. En entornos modernos como GNOME 44 o GNOME 50, las opciones han cambiado bastante respecto a versiones antiguas, y según la distribución (Debian, Oracle Linux, Ubuntu, etc.) las herramientas preinstaladas son distintas.

Para liar más la cosa, coexisten varias tecnologías: RDP, VNC, soluciones propias como AnyDesk o RealVNC Connect y protocolos optimizados como X2Go. Cada una tiene implicaciones en seguridad, rendimiento y facilidad de uso. En esta guía vamos a ordenar ese caos y ver, con calma, cómo funciona el escritorio remoto en GNOME y qué alternativas tienes si lo quieres usar en Debian u otras distribuciones.

Escritorio remoto en GNOME: qué integra el entorno y por qué a veces no aparece

El entorno de escritorio GNOME ofrece de serie varias formas de acceder a sesiones gráficas de manera remota, pero no todas se exponen igual en todas las distribuciones. A nivel conceptual, tienes dos grandes escenarios soportados por GNOME:

Por un lado está el uso compartido de escritorio de un usuario ya conectado. Esto es lo típico de conectarte a la sesión que alguien tiene abierta en su PC para darle soporte o manejar la misma sesión desde otra máquina. En GNOME se gestiona normalmente desde el panel Configuración > Compartir > Escritorio remoto, usando el componente gnome-remote-desktop.

Por otro lado está el inicio de sesión remoto con pantalla de login de GNOME. En este caso, el cliente remoto no engancha a una sesión ya iniciada, sino que ve el gestor de inicio de sesión (GDM) y puede abrir una nueva sesión gráfica de GNOME como si estuviera delante de la máquina, lo que se conoce a menudo como «login remoto».

Cuando hay acceso físico al servidor y un monitor enchufado, muchos escritorios GNOME exponen la opción de compartir escritorio directamente en la interfaz de Configuración. Sin embargo, en distribuciones como Debian trixie/sid con GNOME 44.8, esa opción puede no aparecer aunque instales paquetes como gnome-remote-desktop, gnome-connections o xrdp, bien porque el proveedor de la distribución ha cambiado los presets, bien porque la integración gráfica está deshabilitada o todavía no se ha adaptado a esa versión.

En entornos sin cabeza (servidores sin monitor, máquinas en la nube, instancias en Oracle Cloud Infrastructure, Azure, etc.) la cosa cambia: GNOME no siempre muestra el panel gráfico de «Escritorio remoto» y se suele recurrir a soluciones como FreeRDP o X2Go que lanzan sesiones gráficas sin necesidad de monitor físico.

GNOME, RDP y gnome-remote-desktop como servidor del escritorio

En los GNOME modernos, el componente clave para ofrecer escritorio remoto mediante RDP es gnome-remote-desktop. Este daemon puede funcionar tanto como servicio de usuario (para compartir la sesión actual) como como servicio de sistema (para acceso multiusuario sin cabeza), y se gestiona con la utilidad de línea de comandos grdctl.

A grandes rasgos, el flujo para montar un servidor RDP con GNOME como backend pasa por estos pasos: instalar GNOME y FreeRDP, configurar TLS, registrar las credenciales RDP y activar el servicio. En entornos como Oracle Linux, esto se hace sobre un sistema sin entorno gráfico y se instala el escritorio GNOME desde cero junto con el software RDP.

Primero se instala un entorno de escritorio GNOME completo con todas sus dependencias, asegurándose de que el sistema está actualizado y reiniciando si hace falta. A continuación se añade el paquete de FreeRDP, que es la implementación libre del protocolo RDP usada para servir y/o probar conexiones remotas.

Para habilitar un servidor RDP multiusuario sin cabeza, es necesario generar una clave y un certificado TLS autofirmados. Se crea un directorio específico para alojarlos, se usa una herramienta como winpr-makecert para generar el par .key/.crt, y después se le indica a gnome-remote-desktop dónde están esos archivos mediante los comandos de grdctl.

El siguiente paso consiste en definir las credenciales RDP. Estas credenciales (usuario y contraseña) son las que utilizará el cliente RDP para establecer la sesión que muestra la pantalla de login de GNOME. Es importante tener claro que esto no sustituye a las cuentas locales del sistema: para entrar en una sesión de escritorio real, el usuario deberá iniciar sesión con un usuario Linux válido, con su contraseña de siempre.

Una vez fijados la clave TLS, el certificado y las credenciales, conviene ejecutar el comando de estado de gnome-remote-desktop con la opción de mostrar credenciales, para verificar que la clave y el certificado encajan (mismo nombre base y ruta) y que usuario y contraseña son los que pretendías. Esta verificación previa ahorra muchos quebraderos de cabeza luego.

Después de la parte de TLS y cuentas, se habilita y arranca el servicio RDP del escritorio remoto a nivel de sistema, se comprueba con systemctl que está activo, se activa el servicio de GDM y el servicio de inicio de sesión remoto a nivel de sistema, y se configura gnome-remote-desktop como servicio predeterminado para que arranque en cada reinicio.

Por último, está bien confirmar que el servidor escucha efectivamente en el puerto 3389, típico de RDP, con una orden como: sudo ss -lnpA inet | grep -e gnome-remote. Si ves el puerto 3389 abierto y asociado al proceso correcto, el lado servidor está listo.

Servidores sin cabeza y FreeRDP: acceso de uno o varios usuarios

En muchos despliegues modernos se trabaja con servidores sin monitor (headless) en la nube. En esos casos GNOME no muestra paneles de compartir escritorio, y resulta más práctico tratar la máquina como un servidor RDP genérico con sesiones multiusuario.

FreeRDP entra aquí como una implementación libre del Remote Desktop Protocol que puede actuar tanto como cliente como, en ciertos escenarios, integrarse con servicios de servidor. Esta combinación permite tener sesiones para uno o varios usuarios simultáneos, cada uno con su propia sesión gráfica, algo muy útil en laboratorios de prácticas o entornos formativos o en una infraestructura de escritorio virtual donde varios alumnos acceden a la misma máquina anfitriona.

La preparación del entorno suele seguir un orden muy parecido al que se ve en guías para Oracle Linux: abrir terminal, conectarte por SSH al nodo (por ejemplo ol-node-01), actualizar paquetes, instalar GNOME y FreeRDP y comprobar si es necesario reiniciar. Con eso se transforma una máquina sin escritorio en un servidor listo para ofrecer sesiones gráficas vía red.

En despliegues automatizados con Ansible, a veces se requiere ajustar variables como ansible_python_interpreter para localhost cuando se instala el SDK de Oracle Cloud Infrastructure. Esto se debe a que el paquete se ubica en la ruta de módulos de Python del sistema y Ansible necesita saber qué intérprete usar. También se suelen parametrizar detalles como el tipo de instancia (por ejemplo VM.Standard3.Flex) o la versión de Oracle Linux pasada en la línea de comandos mediante os_version.

Una vez ejecutada la automatización, el playbook acostumbra a mostrar las direcciones IP públicas y privadas de las instancias, lo que permite saber desde qué dirección remota conectarse vía RDP o SSH. A partir de ahí, bastará con abrir túneles o exponer puertos según la política de seguridad que definas.

Acceso desde el cliente: Remmina, Connections y otros frontends RDP

Una vez configurado el servidor GNOME con RDP, necesitas un cliente de escritorio remoto compatible. En Linux se manejan varias opciones, pero no todas se llevan igual de bien con gnome-remote-desktop y FreeRDP.

Entre los clientes que se sabe que funcionan bien están Remmina y GNOME Connections en Linux, y xfreerdp en macOS. En laboratorios como los de Oracle Linux, Remmina suele venir preinstalado en el escritorio Luna Desktop para simplificar las pruebas, ya que ofrece una interfaz muy flexible y admite una larga lista de protocolos (RDP, VNC, SSH, etc.).

Para conectarte a un servidor RDP remoto a través de un túnel SSH, se puede abrir una terminal y usar SSH con la opción -L para reenvío de puerto local. Por ejemplo, mapear el puerto remoto 3389 al puerto local 13389. Así la conexión RDP se hace contra localhost:13389 pero viaja cifrada dentro del túnel SSH.

Una vez montado el túnel, abres Remmina, creas una nueva conexión, eliges RDP – Remote Desktop Protocol como protocolo, y rellenas parámetros como:

• Servidor: localhost:13389 (o el puerto local que hayas elegido).
• Nombre de usuario RDP: el definido al configurar las credenciales RDP en el servidor.
• Contraseña: la que fijaste en grdctl.

Si lo prefieres, puedes lanzar la conexión directamente desde un terminal con una orden tipo remmina -c rdp://usuario@localhost:13389. Al conectarte, lo habitual es que veas el gestor de inicio de GNOME (GDM); desde ahí ya inicias sesión con las credenciales de usuario Linux (por ejemplo usuario oracle / contraseña oracle en ciertos laboratorios).

Si te encuentras con problemas de conexión, la solución típica es revisar primero la conectividad SSH y el túnel. En entornos de nube como Oracle Cloud Infrastructure puede que necesites pasos adicionales de networking: apertura de puertos en la VCN, configuración de listas de seguridad, o reglas de NAT para exponer la instancia. En virtualizadores como Oracle VM VirtualBox, en cambio, se juega con el reenvío de puertos en la red NAT de la máquina virtual para redirigir conexiones RDP desde el host.

Firewall y seguridad del puerto RDP: acceso directo vs. túnel SSH

El servicio RDP se expone por defecto en el puerto TCP 3389. En redes internas confiables puedes abrir este puerto en el firewall para que los clientes se conecten directamente, pero hay matices importantes a tener en cuenta.

Aunque el protocolo RDP moderno, y las implementaciones como gnome-remote-desktop con FreeRDP, usan TLS para cifrar la comunicación, no es buena idea dejar 3389 abierto hacia Internet sin protección adicional. Incluso en Linux, exponer RDP sin filtrar suele implicar ataques de fuerza bruta, escaneos masivos y potenciales vulnerabilidades en la pila de RDP.

Por eso, muchas guías etiquetan la apertura directa del puerto en el firewall como un paso opcional y no recomendado. Lo ideal es combinar RDP con un túnel seguro, como SSH, o con una VPN que encamine el tráfico de los clientes autorizados a la red donde se ubica el servidor.

Si aun así decides abrir el puerto 3389 para acceso directo en una red privada, deberás crear reglas en el firewall (por ejemplo con firewalld, nftables o iptables) que permitan ese tráfico, preferiblemente restringiendo por IP origen para reducir la superficie de ataque. Aun en ese caso, es vital que las cuentas de usuario usen contraseñas robustas y que el sistema se mantenga al día de parches.

Rendimiento del escritorio remoto: GNOME frente a XFCE, Xubuntu o MATE

El rendimiento de un escritorio remoto depende tanto de la red como del entorno gráfico y el protocolo elegido. No es lo mismo servir un GNOME completo con efectos y animaciones sobre RDP que un escritorio ligero XFCE corriendo sobre X2Go.

En experiencias con Ubuntu 20.04/22.04 LTS en Azure Lab Services, se ha observado que GNOME sobre RDP puede introducir latencias perceptibles, especialmente si la conexión no es muy buena o si el escritorio está cargado de efectos visuales. En cambio, escritorios ligeros como XFCE, Xubuntu o MATE tienden a funcionar más fluidos con menos recursos.

Una opción muy optimizada para redes lentas es X2Go, que utiliza el protocolo NX y se beneficia de avances en Xlibre. Este enfoque comprime y optimiza muy bien las actualizaciones de pantalla, permitiendo trabajar de forma razonable incluso en enlaces con tiempos de espera altos, sobre todo en escenarios Linux-a-Linux. Muchos laboratorios recomiendan precisamente la combinación XFCE + X2Go por esa relación rendimiento/consumo.

En setups con Xubuntu y X2Go, se suele aconsejar desactivar la composición de ventanas para mejorar aún más el rendimiento, ya que el compositor añade carga gráfica innecesaria en un escritorio remoto. Tras deshabilitarla y reiniciar la máquina, la experiencia suele ser mucho más fluida.

MATE es otra alternativa intermedia, con un consumo algo mayor que XFCE pero menor que GNOME, y también se integra bien con X2Go usando el mismo puerto 22 que SSH, lo que simplifica la configuración de red en laboratorios y entornos educativos.

Configuraciones de escritorio remoto habituales en laboratorios Linux

En plataformas como Azure Lab Services o entornos docentes, se manejan varias combinaciones frecuentes de escritorio y tecnología de acceso remoto, cada una con sus ventajas:

La combinación XFCE + X2Go se recomienda a menudo como la opción con mejor rendimiento global. La instalación consiste en añadir el entorno XFCE, instalar el servidor X2Go y, a partir de ahí, los alumnos se conectan con el cliente X2Go, sin cambiar nada en el firewall porque X2Go reutiliza el puerto SSH 22 que ya está abierto.

Otra variante es Xubuntu + X2Go, que en esencia es similar pero con la personalización y paquetes que trae Xubuntu. Aquí, para asegurar un rendimiento óptimo, se insiste en deshabilitar la composición de ventanas y reiniciar la plantilla antes de publicarla a los alumnos.

Con MATE + X2Go el planteamiento es idéntico: instalar MATE, añadir el servidor X2Go y usar el cliente X2Go desde los puestos de los alumnos. En todos estos casos, se aprovecha que X2Go se apoya en SSH, evitando abrir puertos adicionales.

En cambio, si se quiere ofrecer un escritorio GNOME completo en Azure Lab Services, la recomendación es usar RDP. Eso requiere un paso adicional durante la creación del laboratorio: habilitar el tipo de conexión RDP para que se abra el puerto 3389, ya que, por defecto, solo está abierto el 22 para SSH y no se puede cambiar después de crear el laboratorio.

Una vez activado RDP, se instala GNOME en la VM de plantilla, se añade el servidor RDP, se aplican ajustes de rendimiento (limitación de efectos gráficos, ajustes de compresión de RDP, etc.) y ya se puede conectar desde el cliente RDP del sistema operativo del alumno.

Clientes RDP y VNC desde Linux: Remmina, Vinagre y otros

Desde el lado cliente Linux, tienes varias herramientas para conectarte a escritorios remotos usando RDP, VNC o SSH. Una de las más completas es Remmina, que además está muy extendida en entornos GNOME y Debian.

Remmina es un proyecto de software libre que soporta protocolos como RDP, VNC, SSH, SPICE, X2Go, entre otros. En Debian, la instalación típica pasa por actualizar la lista de paquetes, aplicar actualizaciones y después instalar remmina junto con los plugins necesarios, por ejemplo remmina-plugin-rdp y remmina-plugin-secret para tener soporte completo de RDP y almacenamiento seguro de credenciales.

Una vez instalado, puedes lanzar Remmina desde Actividades o desde la terminal. Permite hacer conexiones rápidas escribiendo directamente la dirección IP o el nombre de host remoto en la barra superior, o bien crear perfiles guardados con detalles de resolución, calidad de imagen, credenciales, etc.

Si necesitas trabajar de forma habitual con un servidor Windows desde un Debian con GNOME, lo normal es crear un perfil RDP en Remmina, apuntar al nombre DNS o IP del servidor (por ejemplo un Windows Server 2016), introducir el usuario de dominio y contraseña, y ajustar el modo de pantalla completa o ventana.

Remmina también ofrece un pequeño panel flotante cuando estás en pantalla completa, que se desliza desde la parte superior. Desde ahí se puede salir a modo ventana, cerrar la sesión, o ajustar algunos parámetros sin soltar el ratón.

Otra aplicación clásica de GNOME es Vinagre, pensada originalmente como cliente de escritorio remoto sencillo. Soporta VNC, RDP y SSH, y para instalarla en distribuciones basadas en Debian basta con añadir el paquete vinagre. Es menos potente que Remmina en cuanto a opciones, pero para conexiones puntuales o entornos muy GNOME-puros sigue siendo una herramienta válida.

VNC y alternativas: TigerVNC, TightVNC y VNC Viewer

VNC es otra familia de tecnologías de escritorio remoto muy arraigada en Linux. Aquí suele haber dos piezas: un servidor VNC en la máquina remota y un cliente como VNC Viewer en el equipo desde el que te conectas.

TigerVNC es una implementación de alto rendimiento que sigue un modelo cliente/servidor clásico. Para usarlo en Linux, puedes instalar el paquete desde el centro de software o el gestor de paquetes de tu distribución. Una vez instalado, dispones de utilidades para arrancar un servidor VNC en el equipo que quieres controlar y del visor para conectarte desde otro.

El cliente de TigerVNC suele contar con pestañas de configuración como Compresión, Seguridad, Entrada o Pantalla, donde se ajusta el nivel de compresión, los cifrados y métodos de autenticación, los dispositivos de entrada aceptados o el escalado de la pantalla. Estas opciones son muy útiles para adaptar la experiencia a enlaces lentos o pantallas de distinta resolución.

TightVNC es otra alternativa gratuita orientada tanto a administración remota como a tareas más rutinarias. En Linux, se puede instalar el servidor con tightvncserver y levantar sesiones gráficas independientes, mientras que el cliente se gestiona a menudo con VNC Viewer, disponible para varias plataformas.

VNC Viewer se instala desde el paquete correspondiente a tu distribución y se integra con los servidores VNC que tengas en la red. La experiencia suele ser muy directa: introduces la IP o el nombre del servidor, la contraseña de acceso y ya puedes interactuar con el escritorio remoto.

Soluciones comerciales y multiplataforma: RealVNC Connect, AnyDesk y RustDesk

Más allá de RDP y VNC puros, hay soluciones completas de escritorio remoto que ofrecen servicios de intermediación, cifrado avanzado y gestión centralizada. Para Linux destacan RealVNC Connect, AnyDesk o RustDesk, todas accesibles desde un GNOME moderno.

AnyDesk es muy popular por su sencillez y rendimiento. Utiliza un códec propietario, DeskRT, diseñado específicamente para conexiones de escritorio remoto, lo que le permite ofrecer baja latencia y buena calidad de imagen incluso en conexiones con ancho de banda limitado. En escenarios de poco ancho de banda puede aparecer algo de pixelación o desenfoque, pero la experiencia sigue siendo usable.

En seguridad, AnyDesk cifra las sesiones con TLS 1.2 e intercambio de claves RSA 2048, lo que mantiene las comunicaciones protegidas frente a escuchas. Además soporta sesiones múltiples y conexiones desatendidas, ideales para acceder a ordenadores en sedes remotas o sin personal presencial.

RealVNC Connect, por su parte, está muy orientado a empresas. Ofrece cifrado de extremo a extremo, autenticación multifactor (MFA), integración con SSO, y puede conectarse a infraestructura de directorios como servidores de dominio Windows o Azure. Una ventaja clave es su enfoque en el cumplimiento y la gestión centralizada de permisos, dispositivos y registros de acceso.

En el plano de rendimiento, al estar basado en VNC, RealVNC Connect es bastante adaptativo: ajusta la calidad gráfica a la conexión y permite definir manualmente escalado y calidad de imagen, priorizando detalle o fluidez según te interese incluso antes de iniciar la sesión.

En cuanto a RustDesk, se presenta como una alternativa libre que no requiere prácticamente configuración: puedes usar el servidor público, alojar tu propio servidor o conectar punto a punto. Está desarrollado en Rust y usa el protocolo RFB para enviar actualizaciones de pantalla, con funciones como transferencia de archivos, control de permisos, modo sin supervisión o la posibilidad de montar fácilmente tu propia infraestructura si quieres total control.

A la hora de elegir, hay que ponderar varios factores: si manejas datos sensibles y necesitas cumplimiento estricto, RealVNC Connect suele ser la apuesta más sólida. Para soporte remoto rápido y multiplataforma con poca configuración, AnyDesk y Chrome Remote Desktop ofrecen experiencias muy sencillas. Y para entornos muy Linuxeros que también gestionan Windows y macOS, RealVNC Connect y RustDesk combinan bien compatibilidad, seguridad y flexibilidad.

RDP frente a otras opciones: facilidad de instalación y seguridad

En muchas guías se advierte de que las soluciones basadas en RDP requieren bastante trabajo adicional de seguridad. A diferencia de servicios que vienen con intermediación en la nube o autenticación avanzada integrada, RDP expuesto a Internet sin filtrar suele ser un imán de ataques.

Si quieres usar RDP en Linux con seguridad aceptable, se recomienda casi siempre protegerlo detrás de VPN, usar listas de control de acceso en el firewall y evitar a toda costa exponer el puerto 3389 libremente. Por contra, herramientas como RealVNC Connect o AnyDesk no te obligan a tocar redirecciones de puertos ni túneles SSH, porque gestionan el tránsito a través de sus propios servicios y suelen incluir mecanismos de autenticación adicionales de serie.

En facilidad de instalación, cada solución ocupa su lugar: mientras que Remmina en Debian o Ubuntu se instala con un par de comandos y empieza a funcionar al vuelo, montar xRDP o X2Go implica abrir puertos, crear reglas de firewall y, en entornos más estrictos, manejar listas de IP permitidas o bloqueadas a nivel de red y usuarios.

Chrome Remote Desktop es probablemente de lo más simple de configurar para uso personal: basta con vincularlo a una cuenta de Google y seguir el asistente. Sin embargo, precisamente porque depende de la infraestructura de autenticación y gestión de Google, algunas empresas lo consideran poco alineado con sus políticas de seguridad.

Escenarios de uso: empresas, soporte remoto y entusiastas de Linux

No todos los entornos tienen las mismas necesidades, así que conviene distinguir algunos escenarios típicos de uso del escritorio remoto en Linux con GNOME y otros escritorios.

Para empresas que manejan información sensible, la prioridad está en la seguridad, el cumplimiento normativo y la gestión centralizada. En este contexto, RealVNC Connect destaca por sus capacidades de cifrado de extremo a extremo, MFA, integración con SSO y RADIUS, y herramientas de administración de usuarios y dispositivos.

Para pequeños equipos de soporte que ayudan a usuarios en ubicaciones remotas, herramientas como AnyDesk o Chrome Remote Desktop encajan muy bien, ya que permiten conexiones rápidas y multiplataforma con una configuración mínima, perfectas para atender incidencias puntuales sin complicarse con VPNs o reglas de firewall avanzadas.

En el mundo de los entusiastas de Linux y administradores de sistemas, combinaciones como X2Go, xRDP o VNC con GNOME, XFCE o MATE permiten construir entornos a medida, con máximo control sobre puertos, cifrado y recursos. Para quienes prefieren trabajar desde un escritorio Linux pero necesitan gestionar también servidores Windows y macOS, RealVNC Connect y Remmina ofrecen un equilibrio interesante entre funcionalidad y usabilidad.

Sea cual sea el caso, la clave está en tener claro qué pesa más para ti: si lo que buscas es seguridad de nivel corporativo, si te compensa priorizar facilidad de uso para usuarios no técnicos, o si necesitas sobre todo rendimiento en redes limitadas.

Con todo este panorama, se ve que el escritorio remoto en GNOME y en Linux en general no es una única herramienta, sino un abanico de opciones que van desde RDP servido por gnome-remote-desktop con FreeRDP y accesible mediante Remmina, pasando por X2Go y escritorios ligeros como XFCE o MATE para ganar rendimiento, hasta soluciones comerciales como RealVNC Connect, AnyDesk o RustDesk que ponen el foco en la seguridad y la comodidad; elegir bien qué combinación usar en tu Debian con GNOME u otra distribución pasa por valorar red, recursos, seguridad y, sobre todo, cómo vas a trabajar tú y tu equipo día a día.