Escritorio remoto en Linux sin monitor: sesiones de escritorio reales

Tu servidor es accesible, pero al conectar obtienes pantalla negra, un framebuffer virtual diminuto o sin aceleración GPU — porque la máquina no tiene un monitor conectado. Esta guía muestra cómo obtener una sesión de escritorio real y usable en Linux sin monitor: opciones de hardware y software, comandos paso a paso, unidades systemd, consideraciones sobre Wayland y cómo conectarse de forma segura (incluida la opción de relay gestionado de Tenvo).

Qué significa 'escritorio real' en una máquina sin monitor

Por 'escritorio real' me refiero a una sesión de escritorio que se comporta como si hubiera un monitor conectado: resolución de pantalla completa, salida GPU adecuada (cuando aplique), persistencia de sesión tras reinicios, mapeo de teclado/ratón predecible y la capacidad de ejecutar entornos de escritorio Wayland o X11 en lugar de un pequeño framebuffer 800×600 de Xvfb. Una máquina headless puede presentar una pantalla virtual (emulación por software) o una física (enchufe HDMI dummy o KMS virtual). Tu elección depende de si necesitas aceleración GPU, funciones DRM/KMS o simplemente un escritorio interactivo para administración.

Tres enfoques prácticos — elige según la necesidad

• Hardware HDMI dummy plug — lo más sencillo para aceleración GPU. Inserta un HDMI de $2 que emule un monitor ('headless ghost') para falsear la presencia de una pantalla; la GPU y el display manager crean una sesión normal con la resolución adecuada.
• Virtual X / Xvfb o driver dummy de Xorg + display manager — solo software y ampliamente compatible: crea una sesión X11 completa que puedes exponer vía VNC (TigerVNC) o compartir con x11vnc. Xvfb es lo más simple pero no expone KMS/aceleración GPU.
• RDP vía xrdp (recomendado en muchos casos) — xrdp lanza una sesión X real (o usa XorgXrdp) y ofrece un endpoint RDP. Funciona bien en servidores headless porque no requiere pantalla física y está bien soportado por clientes de Windows/macOS y otros clientes.

Opción A — HDMI dummy plug (truco de hardware)

Si necesitas aceleración GPU (OpenGL, decodificación por hardware, salida de compositor Wayland) este es el truco más rápido y fiable: compra un pequeño HDMI dummy (emulador EDID) que anuncie un monitor 1920×1080 o 2560×1440. Conéctalo al puerto HDMI de la GPU, reinicia si hace falta, y tu display manager (GDM, SDDM, LightDM) creará una sesión normal. Sin hacks de software, sin framebuffers virtuales.

Pros: GPU real, sin cambios de configuración. Contras: se requiere acceso físico; no es posible si el sistema no tiene conector de vídeo o está en un rack sellado.

Opción B — sesión X virtual: Xvfb + desktop + TigerVNC (ejemplo Ubuntu/Debian)

Usa esto cuando no puedas enchufar un dummy o cuando no sea necesaria la aceleración GPU. Produce una sesión de escritorio completa independiente de un monitor físico y funcionará en cualquier distro con X11.

sudo apt update
sudo apt install -y xvfb tigervnc-standalone-server xfce4 xfce4-goodies

# Create a dedicated VNC user (optional)
sudo adduser vncuser

# Example: start a persistent Xvfb display and XFCE
sudo -u vncuser Xvfb :99 -screen 0 1920x1080x24 &
export DISPLAY=:99
sudo -u vncuser startxfce4 &

# Start TigerVNC to expose :99 on TCP 5901
sudo -u vncuser x0vncserver -display :99 -passwordfile /home/vncuser/.vnc/passwd -forever -shared

# Or run tigervncserver directly if you want VNC-managed X sessions
sudo -u vncuser tigervncserver :1 -geometry 1920x1080 -depth 24

Unidad systemd: haz que la pantalla persista tras reinicios. Guarda como /etc/systemd/system/xvfb-vnc.service (edita rutas y usuario):

[Unit]
Description=Xvfb + desktop + VNC
After=network.target

[Service]
Type=simple
User=vncuser
Environment=DISPLAY=:99
ExecStart=/usr/bin/Xvfb :99 -screen 0 1920x1080x24
ExecStartPost=/usr/bin/sleep 1
ExecStartPost=/usr/bin/startxfce4
Restart=on-failure

[Install]
WantedBy=multi-user.target

Notas: Xvfb ofrece solo un framebuffer por software; no hay aceleración GPU por hardware. Para muchas tareas administrativas y aplicaciones GUI es suficiente. Si necesitas una sesión con respaldo GPU, usa el HDMI dummy o el driver dummy de Xorg combinado con el driver GPU (más abajo).

Opción C — driver dummy de Xorg / servidor X headless (para sesiones con display manager)

En lugar de Xvfb puedes configurar Xorg para usar el driver de vídeo 'dummy' para que el display manager del sistema (GDM/LightDM) cree una sesión de login normal en el arranque. Esto se acerca más a una sesión con monitor real y a veces ofrece mejor compatibilidad que Xvfb.

# Install Xorg dummy driver and a lightweight DE (Debian/Ubuntu)
sudo apt install -y xserver-xorg-video-dummy xfce4

# Example minimal /etc/X11/xorg.conf.d/10-dummy.conf
Section "Device"
  Identifier "DummyDevice"
  Driver "dummy"
EndSection

Section "Monitor"
  Identifier "DummyMonitor"
  HorizSync 28.0-80.0
  VertRefresh 48.0-75.0
EndSection

Section "Screen"
  Identifier "DummyScreen"
  Device "DummyDevice"
  Monitor "DummyMonitor"
  SubSection "Display"
    Depth 24
    Modes "1920x1080"
  EndSubSection
EndSection

Tras crear esta configuración, habilita tu display manager y reinicia. El DM debería presentar el greeter normal y crear sesiones a las que puedes acceder con x11vnc (para compartir el escritorio existente) o mediante un servidor VNC asociado a la pantalla X.

Opción D — xrdp: sesiones RDP que funcionan bien en headless

xrdp es una opción sólida porque crea una sesión X bajo demanda y habla RDP, lo cual está ampliamente soportado por clientes. No depende de un monitor conectado y a menudo es el enfoque menos problemático para acceso remoto GUI en servidores.

sudo apt install -y xrdp xfce4 xfce4-terminal
# Configure XFCE for xrdp: create or edit /home/you/.xsession or /etc/xrdp/startwm.sh
echo "startxfce4" > /home/you/.xsession
sudo systemctl enable --now xrdp
# Open firewall for TCP/UDP 3389 only if you control the network; prefer an SSH tunnel or Tenvo relay

Luego conéctate con cualquier cliente RDP al puerto 3389 o vía un túnel SSH. xrdp puede usar XorgXrdp para mejor rendimiento; verifica el empaquetado de tu distro para la versión correspondiente de xorgxrdp.

Wayland: consideraciones y opciones

Los compositores Wayland manejan las salidas de forma diferente y, históricamente, tienen soporte limitado o nulo para pantallas virtuales. GNOME en Wayland no aceptará una pantalla Xvfb; espera una salida DRM/KMS. Tus opciones:

• Usar un HDMI dummy plug para que el compositor crea que hay un monitor presente.
• Ejecutar una sesión Xorg en su lugar (instala una sesión X11 como XFCE o GNOME on Xorg) y usa Xvfb/xrdp/VNC.
• Para compositores basados en wlroots, investiga wlr-rdp o wayvnc (la madurez de los proyectos varía según el compositor).
• Para flotas grandes con requisito Wayland, considera usar una GPU headless de hardware o un driver headless de GPU empresarial — pero eso normalmente requiere paquetes del proveedor y hooks en el kernel.

Si dependes de Wayland, lee nuestro análisis más profundo en Escritorio remoto en Wayland: PipeWire, portales y brechas antes de decidir una solución.

Conectividad de red: relay de Tenvo y notas de seguridad

Una vez que tengas una sesión de escritorio, necesitas una conexión fiable. Tenvo ofrece clientes nativos para macOS/Windows/Linux, un cliente en navegador en beta pública y un relay gestionado multi‑región, que es la opción recomendada por defecto para la mayoría de usuarios. Planes: Free $0, Lite $2.99/mo, Pro $7.99/mo. El relay gestionado elimina la necesidad de reglas de firewall, traversal NAT y mantener una flota TURN/STUN.

Sé explícito sobre cifrado: Tenvo usa TLS con certificados por dispositivo. Una conexión directa peer‑to‑peer es de extremo a extremo entre los dos dispositivos. Cuando el tráfico cae a un relay, TLS termina en el relay, lo que significa que quien opere el relay puede acceder al tráfico de la sesión. Si un requisito de cumplimiento prohíbe infraestructura de terceros, el auto‑hosting es la opción correcta — de lo contrario, el costo operativo del auto‑hosting (parches, custodia de claves, failover) suele ser mayor que el de un relay gestionado. Consulta Self-Hosted Remote Desktop: Why, How, and What Breaks para saber cuándo elegir auto‑hosting.

Si quieres evitar el reenvío de puertos por completo pero aún usar tu propio relay o túnel, revisa Remote Desktop Without Port Forwarding Explained.

Lista de verificación de solución de problemas (pantallas negras, resolución incorrecta, problemas de teclado)

• Pantalla negra tras el login: revisa los logs del display manager (journalctl -u gdm -b o journalctl -u lightdm) y /var/log/Xorg.0.log en busca de errores.
• Framebuffer demasiado pequeño (p. ej., 640×480): configura un modo personalizado en tu configuración dummy de X o usa xrandr para añadir un modo (funciona solo si X expone la salida).
• Mapeo de teclado/ratón incorrecto: verifica la locale y la configuración xkb, y comprueba que el cliente VNC/RDP no esté forzando una distribución; prueba con una consola virtual local (chvt) si es posible.
• Sin GPU/OpenGL: Xvfb no proporciona aceleración GPU. Usa HDMI dummy o un driver headless del proveedor si necesitas aceleración por hardware.
• Greeter de Wayland pero sin sesión: cambia a una sesión X o enchufa un dummy; revisa los logs del compositor (journalctl para gnome-shell o el servicio del compositor).

Para soluciones comunes de pantalla negra consulta nuestra guía de resolución de problemas: Flujo de solución de pantalla negra en escritorio remoto. También inspecciona Xauthority, la propiedad de /tmp/.X11-unix y que el usuario tenga un shell válido y un directorio home correcto.

Cuándo auto‑hostear vs usar el relay gestionado de Tenvo

Elige auto‑hosting solo si tienes una política por escrito que prohíba relays de terceros (residencia de datos, ciertos regímenes de cumplimiento), o la máquina está en una red aislada. De lo contrario, el relay gestionado de Tenvo es el valor práctico por defecto: reduce la carga on‑call, gestiona certificados TLS y ofrece failover multi‑región. Si planeas auto‑hostear, lee las compensaciones en Self-Hosted Remote Desktop: Why, How, and What Breaks y prepárate para ejecutar un clúster de relays, manejar rotación de certificados, logging y monitorización.

Referencia rápida: comandos y comprobaciones

# Check active display
echo "$DISPLAY"
# Test X connectivity
xdpyinfo -display :0 || xdpyinfo -display :99
# View DM logs
sudo journalctl -u gdm -b --no-pager
# Xorg log
sudo tail -n 200 /var/log/Xorg.0.log
# See screen/outputs
DISPLAY=:0 xrandr --listmonitors || DISPLAY=:99 xrandr --listmonitors
# Enable xrdp
sudo systemctl enable --now xrdp

Si migras desde una herramienta de escritorio remoto que siempre 'simplemente funcionaba' con un monitor conectado, recuerda: las máquinas headless cambian las suposiciones que el SO y los drivers hacen sobre las pantallas. Empieza con el arreglo más simple (HDMI dummy) y pasa a soluciones por software si no es posible el acceso físico.

¿Listo para probar? Descarga Tenvo, prueba una conexión desatendida a través del relay gestionado y elige el enfoque de escritorio anterior que coincida con tu GPU y requisitos de cumplimiento: Descargar Tenvo.