Віддалений робочий стіл на Linux VPS через xrdp

Що насправді означає віддалений робочий стіл на Linux VPS

Пошук «віддалений робочий стіл на Linux VPS» приводить до двох різних типів продуктів. Якщо вибрати неправильний, можна втратити цілий робочий день. Перший тип — брокер віддаленого доступу. Типовий приклад — self-hosted сервер RustDesk. Він ретранслює сеанс між двома вашими пристроями, наприклад ноутбуком і домашнім ПК. Орендований сервер не запускає графічний робочий стіл. Він лише з’єднує обидві сторони та передає пакети, якщо вони не можуть встановити пряме з’єднання. Другий тип — справжній графічний робочий стіл, запущений на орендованому сервері. У цьому разі зображення формується в дата-центрі та передається вам через мережу. До цього типу належать xrdp, VNC (virtual network computing) або робочий простір у контейнері.

Їх розрізняє одне запитання: де буде вказівник миші після налаштування? Якщо він має бути на пристрої, яким ви вже володієте, потрібен брокер. Якщо він має бути безпосередньо на VPS, потрібен робочий стіл на VPS. Нижче переважно розглянуто другий варіант, оскільки більшість посібників його оминає.

Який варіант відповідає вашому завданню

• RustDesk із власним relay-сервером. Він захищає сеанс від передавання через публічний rendezvous-сервер, яким керують сторонні особи, оскільки ключова пара зберігається у вас. Він не захищає керований комп’ютер: це все одно той PC, на який ви встановили клієнт, із тим паролем, який налаштовано на цьому PC.
• xrdp через SSH-тунель або VPN. Він захищає від постійного сканування TCP 3389 з усього інтернету та від підбирання пароля до форми входу RDP, оскільки цей порт не доступний з інтернету. Він не захищає слабкий пароль облікового запису від того, хто вже має доступ до тунелю.
• VNC через той самий тунель. Він надає desktop-сеанс, який зберігається після розриву з’єднання, використовуючи старіший і простіший протокол, ніж RDP. Сам по собі VNC нічого не захищає: усю роботу із безпеки виконує тунель, тому VNC на публічному порту без тунелю — найгірший варіант у цьому переліку.
• Container workspace, наприклад Webtop або Kasm. Він надає браузер або цілий desktop у контейнері, який можна видалити та відтворити, захищаючи реальну машину від усього, із чим взаємодіє цей браузер. Він не захищає host: ці images працюють із широкими привілеями та без пароля мають sudo усередині, тому контейнер не є межею ізоляції, якій слід довіряти під час роботи зі шкідливим навантаженням.

Встановлення xrdp і XFCE в Ubuntu 24.04

Образ VPS-сервера не містить графічного робочого столу. Спочатку встановіть його, а потім xrdp — сервер із відкритим кодом, який працює з RDP (протоколом віддаленого робочого столу), тим самим протоколом, який використовує клієнт Windows. Виберіть легке робоче середовище. Зазвичай використовують XFCE.

sudo apt update
sudo apt install -y xrdp xorgxrdp xfce4 xfce4-goodies dbus-x11
systemctl is-active xrdp

Станом на August 2026 в Ubuntu 24.04 доступні xrdp 0.9.24 і xorgxrdp у компоненті universe. Встановіть xorgxrdp за назвою, навіть якщо це лише рекомендований пакет: це бекенд X server, який xrdp запускає для нового сеансу. Без нього вікно входу приймає пароль, а потім одразу повертає вас до вікна входу.

Тепер вкажіть сеансу, яке робоче середовище потрібно запускати. xrdp виконує /etc/xrdp/startwm.sh, а цей файл запускає ~/.xsession, якщо файл існує.

echo "xfce4-session" > ~/.xsession
chmod 644 ~/.xsession

На завершення xrdp має читати TLS (захищений транспортний рівень) ключ, який він пропонує клієнтам. Цей файл має режим 640 і належить групі ssl-cert.

ls -l /etc/ssl/private/ssl-cert-snakeoil.key
id xrdp

У списку відображається -rw-r----- 1 root ssl-cert. Якщо серед груп, які виводить id xrdp, немає ssl-cert, виконайте sudo adduser xrdp ssl-cert, а потім sudo systemctl restart xrdp. Якщо пропустити цей крок, xrdp не зможе відкрити ключ, а /var/log/xrdp.log запише помилку з іменем файлу snakeoil у рядку.

Чому не слід відкривати порт 3389 для інтернету

TCP-порт 3389 безперервно сканується всім інтернетом, а вікно входу RDP відповідає на кожну спробу введення пароля. Не відкривайте його. Прив’яжіть xrdp до loopback-адреси та підключайтеся через тунель, якому ви вже довіряєте.

Відредагуйте /etc/xrdp/xrdp.ini і змініть listener у секції [Globals].

[Globals]
port=tcp://.:3389

У коментарях самого файлу описано цей синтаксис: tcp://.:3389 означає 127.0.0.1:3389, а tcp://:3389 — усі інтерфейси. Перезапустіть сервіс і перевірте результат, оскільки помилка тут непомітно залишає сервіс доступним на всіх адресах.

sudo systemctl restart xrdp
ss -tlnp | grep 3389

Потрібно отримати 127.0.0.1:3389. Якщо ви бачите 0.0.0.0:3389, xrdp проігнорував вашу зміну. Зазвичай це відбувається тому, що рядок опинився під іншим заголовком секції нижче у файлі.

Тепер відкрийте тунель зі свого комп’ютера.

ssh -N -L 3389:127.0.0.1:3389 you@vps.example.com

-N означає «відкрити з’єднання, але не виконувати команду», тому сеанс існує лише для передавання порту. Залиште цей термінал запущеним і вкажіть 127.0.0.1:3389 у клієнті RDP. У Linux-клієнті використовується FreeRDP 3. В Ubuntu 24.04 його бінарний файл має назву xfreerdp3:

sudo apt install -y freerdp3-x11
xfreerdp3 /v:127.0.0.1:3389 /u:you /dynamic-resolution +clipboard /sound

У Windows використовуйте вбудований mstsc і введіть 127.0.0.1 як ім’я комп’ютера. Під час першого підключення FreeRDP попросить підтвердити довіру до сертифіката та виведе Do you trust the above certificate? (Y/T/N). Це очікувано для самопідписаного сертифіката snakeoil.

Якщо ssh відповідає bind [127.0.0.1]:3389: Address already in use, на вашому комп’ютері вже використовується порт 3389. Змініть локальний кінець за допомогою ssh -N -L 13389:127.0.0.1:3389 you@vps.example.com і підключіться до 127.0.0.1:13389.

Окремий тунель для кожної людини швидко стає незручним, тому для команди краще використовувати приватну мережу. Розмістіть сервер за self-hosted VPN WireGuard, призначте йому адресу тунелю 10.8.0.1 і налаштуйте port=tcp://10.8.0.1:3389, щоб xrdp відповідав лише всередині VPN. У будь-якому разі правила firewall для порту 3389 взагалі не повинно існувати. Якщо ви не впевнені, що дозволяють поточні правила, почніть із основ firewall ufw на VPS і перевірте їх до підключення, а не після нього.

Скільки RAM використовує віддалений робочий стіл на VPS із 2 GB

Вибране вами desktop-середовище визначає, чи буде тариф із 2 GB комфортним, чи непридатним для роботи. Нижче наведено округлені типові значення використання пам’яті одразу після входу в Ubuntu 24.04. Їх взято з опублікованих порівнянь, а не виміряно на вашій машині. Виміряйте власне значення за допомогою free -m одразу після підключення.

[
  {
    "label": "LXQt",
    "idle_ram_mb": 300
  },
  {
    "label": "XFCE",
    "idle_ram_mb": 400
  },
  {
    "label": "MATE",
    "idle_ram_mb": 500
  },
  {
    "label": "KDE Plasma",
    "idle_ram_mb": 800
  },
  {
    "label": "GNOME",
    "idle_ram_mb": "1,200"
  }
]

У цих 5 desktop-середовищах саме діапазон значень має вирішальне значення. LXQt використовує близько 300 MB, а XFCE — близько 400 MB, тому в обох випадках на VPS із 2 GB залишається місце для браузера. GNOME потребує приблизно 1,200 MB ще до відкриття першого вікна. На VPS із 2 GB браузер у такій конфігурації конкурує з desktop-середовищем за доступну пам’ять.

Основне навантаження створює браузер, а не desktop shell. Сучасний браузер використовує від 150 до 400 MB на кожну активну вкладку. Тому VPS із 2 GB і XFCE витримує кілька вкладок, після чого починає використовувати swap. Додайте swap, щоб машина сповільнювалася, а не завершувала процеси: sudo fallocate -l 2G /swapfile, потім sudo chmod 600 /swapfile, sudo mkswap /swapfile, sudo swapon /swapfile, а також додайте відповідний рядок у /etc/fstab, щоб swap підключався після перезавантаження. Якщо процес несподівано зникає, виконайте dmesg | grep -i "killed process". Це означає, що kernel out-of-memory killer завершив процес. Найчастіше ним виявляється браузер.

CPU — ще одне обмеження, яке легко недооцінити. VPS не має GPU, тому X використовує програмний рендеринг через llvmpipe. У результаті CPU обчислює кожен піксель. Прокручування складної сторінки та відтворення відео проявляються як звичайне навантаження на CPU. Частота кадрів знижується, а машина не зависає. Те саме обмеження виникає, якщо ви з’ясовуєте чи можна грати на VPS: для будь-яких 3D-ігор відповідь негативна саме з цієї причини.

Звук і буфер обміну в сеансі xrdp

Ubuntu 24.04 використовує PipeWire для роботи зі звуком, а перенаправлення звуку в xrdp розраховане на PulseAudio. Тому після свіжого встановлення відео працює, а звук відсутній. Ubuntu містить потрібний bridge.

sudo apt install -y pipewire-module-xrdp pulseaudio-utils alsa-utils

Повністю вийдіть із сеансу RDP і увійдіть знову, оскільки модуль завантажується під час запуску сеансу. Простого повторного підключення недостатньо. Потім перевірте це безпосередньо в сеансі:

pactl list short sinks
speaker-test -c 2 -t wav -l 1

У списку має бути sink, у назві якого згадується xrdp. Тестовий сигнал має відтворюватися через ваш клієнт. Якщо sink xrdp немає, модуль не завантажився в цьому сеансі. Клієнт також має запитувати перенаправлення звуку: для цього використовується прапорець /sound у xfreerdp3 або параметр "Remote audio" у розділі Local Resources клієнта Windows.

Текстовий буфер обміну працює в обох напрямках, якщо для вашого сеансу запущено xrdp-chansrv. xrdp запускає його автоматично. Перевірте це за допомогою pgrep -a xrdp-chansrv. Якщо копіювання та вставлення перестали працювати під час сеансу, цей процес завершився. Повторне підключення запустить його знову. Копіювання файлів, а не тексту, використовує окремий канал під назвою drive redirection: /drive:home,/home/you у xfreerdp3 монтує локальну папку в віддалений сеанс.

Спливаюче вікно polkit та інші помилки під час першого входу

Найчастіша несподіванка під час першого входу — діалогове вікно з повідомленням Authentication is required to create a color managed device. Причина конкретна. Служба colord запитує дозвіл у polkit. polkit без запиту надає цей дозвіл лише сеансу, який вважає локальним. Сеанс RDP не є локальним, тому polkit запитує пароль. В Ubuntu 24.04 використовується polkit 124, у якому вилучено старі файли локальної політики .pkla. Тому всі інструкції, у яких пропонується створити /etc/polkit-1/localauthority/50-local.d/45-allow-colord.pkla, не діють в Ubuntu 24.04. Натомість створіть правило JavaScript.

/* /etc/polkit-1/rules.d/45-allow-colord.rules */
polkit.addRule(function(action, subject) {
    if (action.id.indexOf("org.freedesktop.color-manager.") === 0 &&
        subject.isInGroup("sudo")) {
        return polkit.Result.YES;
    }
});

Виконайте sudo systemctl restart polkit і підключіться повторно. Про ще дві помилки варто знати за їхніми симптомами.

Форма входу приймає пароль і одразу знову з’являється. Сеанс запустився та завершився. Спочатку перегляньте /var/log/xrdp-sesman.log, потім ~/.xsession-errors у вашому домашньому каталозі. Відсутній xorgxrdp, ~/.xsession із назвою невстановленого робочого середовища, домашній каталог без доступу на запис або заповнений диск — усі ці причини призводять до такого результату.

Після підключення відображається сірий екран із курсором X. X запустився, але робоче середовище — ні. Знову йдеться про ~/.xsession: вручну виконайте xfce4-session через SSH і прочитайте помилку, яку воно виведе.

Що робить self-hosted сервер RustDesk

RustDesk складається з двох процесів. hbbs — це сервер ідентифікації та rendezvous, до якого підключаються клієнти, а hbbr — relay, який передає сеанс, якщо пряме peer-to-peer-з’єднання не встановлюється. Жоден із них не запускає робочий стіл. Обидва входять до одного image. Нижче наведено compose-файл, опублікований проєктом, із адресою relay, зміненою на ім’я вашого хоста:

services:
  hbbs:
    container_name: hbbs
    image: rustdesk/rustdesk-server:latest
    command: hbbs -r rustdesk.example.com:21117
    ports:
      - 21115:21115
      - 21116:21116
      - 21116:21116/udp
      - 21118:21118
    volumes:
      - ./data:/root
    restart: unless-stopped
  hbbr:
    container_name: hbbr
    image: rustdesk/rustdesk-server:latest
    command: hbbr
    ports:
      - 21117:21117
      - 21119:21119
    volumes:
      - ./data:/root
    restart: unless-stopped

Запустіть його, а потім прочитайте публічний ключ, який сервер згенерував під час першого запуску:

sudo docker compose up -d
sudo cat ./data/id_ed25519.pub

У кожному клієнті потрібно вказати ім’я вашого хоста та цей публічний ключ. Обидва значення вводяться в розділі Network settings клієнта RustDesk. Відповідний приватний ключ зберігається в ./data/id_ed25519. Якщо видалити каталог даних, сервер згенерує нову пару ключів. Після цього всі клієнти доведеться налаштувати з новим ключем. Створіть резервну копію цього каталогу. Якщо ця схема стане основним способом доступу команди до всіх машин, а не експериментом на вихідні, варто дотримуватися окремої збірки relay RustDesk, щоб правильно обробляти ключ Ed25519, використовувати зафіксовані теги image замість latest і врахувати пропускну здатність relay, за яку зрештою доведеться платити відповідно до вашого тарифу.

Firewall має безпосередньо дозволяти ці порти. hbbs використовує TCP 21115, 21116 і 21118, а також UDP 21116. hbbr використовує TCP 21117 і 21119.

sudo ufw allow 21115/tcp
sudo ufw allow 21116/tcp
sudo ufw allow 21116/udp
sudo ufw allow 21117/tcp
sudo ufw allow 21118/tcp
sudo ufw allow 21119/tcp

Чому RustDesk не працюватиме за nginx або Traefik

Користувачі, які вже завершують TLS для всіх сервісів на одному reverse proxy, часто намагаються зробити це й тут, але безуспішно. hbbs і hbbr використовують власні бінарні протоколи через TCP і UDP, а не HTTP. Заголовка Host для маршрутизації немає, і HTTP-запиту для аналізу також немає. Тому блок nginx server або HTTP-роутер Traefik не має за що зіставляти запит. Слухач UDP на 21116 не є HTTP-компонентом на жодному рівні.

Працюють два варіанти. nginx може переспрямовувати TCP-порти за допомогою блоку stream. Це звичайне переспрямовування на рівні 4, а не reverse proxy у звичному розумінні. Порти 21118 і 21119 передають websocket-з’єднання, які використовує вебклієнт RustDesk. Це звичайний HTTP, тому ці два порти можна розмістити за вашим проксі. Якщо ви зробите це, додайте правила firewall, щоб лише проксі мав доступ до 21118 і 21119, оскільки hbbs покладається на заголовок X-Real-IP у websocket-з’єднаннях, щоб визначити фактичну адресу клієнта.

Браузер у контейнері для одноразового використання

Іноді потрібен лише чистий браузер зі стабільною IP-адресою, ізольований від вашого комп’ютера. Контейнерне робоче середовище дає це з набагато меншою кількістю встановленого програмного забезпечення. Webtop від LinuxServer — легкий варіант:

services:
  webtop:
    image: lscr.io/linuxserver/webtop:latest
    container_name: webtop
    environment:
      - PUID=1000
      - PGID=1000
      - TZ=Etc/UTC
    volumes:
      - /path/to/data:/config
    ports:
      - 127.0.0.1:3000:3000
      - 127.0.0.1:3001:3001
    shm_size: "1gb"
    restart: unless-stopped

Порт 3000 обслуговує HTTP, а порт 3001 — HTTPS. Робочий стіл відкривається у вкладці браузера, тому RDP-клієнт не потрібен. Теги образів охоплюють XFCE, KDE, MATE та i3 на основі кількох дистрибутивів. Власна документація проєкту прямо попереджає про ризик: контейнер має привілейований доступ до хоста та містить термінал із безпарольним sudo, тому його не слід без захисту виставляти в інтернет. Саме тому зазначені порти прив’язані до 127.0.0.1, а не опубліковані на всіх адресах. Підключайтеся до нього через той самий SSH-тунель або ту саму VPN, яку ви використовували для xrdp.

Kasm Workspaces — це та сама ідея, але значно масштабніша: вебконсоль, облікові записи користувачів і окремі контейнери для сеансів, які скидаються після завершення сеансу. Для нього потрібна потужніша машина, ніж зазвичай має невеликий VPS. Станом на August 2026 задокументовані мінімальні вимоги становлять 2 CPU cores, 4 GB пам’яті та 50 GB SSD. Додатково кожен сеанс користувача за замовчуванням отримує 2 cores і 2768 MB. План на 2 GB не зможе його запустити. Встановлення виконується завантаженням і запуском скрипту:

cd /tmp
curl -O https://kasm-static-content.s3.amazonaws.com/kasm_release_1.17.0.7f020d.tar.gz
tar -xf kasm_release_1.17.0.7f020d.tar.gz
sudo bash kasm_release/install.sh

VNC і випадки, коли він досі доречний

VNC передає оновлення framebuffer, а не команди малювання, тому на повільному з’єднанні він працює важче за RDP і не має каналу для звуку. VNC доречний в одній ситуації: потрібно, щоб сеанс робочого столу продовжував працювати після від’єднання, а після повернення відкривався той самий сеанс. TigerVNC це підтримує. vncserver -localhost yes :1 прив’язує Xvnc до 127.0.0.1 через TCP 5901 і відхиляє підключення з будь-яких інших адрес, тому тунелюйте його так само, як xrdp, за допомогою ssh -N -L 5901:127.0.0.1:5901 you@vps.example.com. Ніколи не відкривайте порт VNC у публічний доступ. Більшість VNC-серверів захищає пароль лише під час рукостискання, а після цього не захищає дані. Тому на публічному порту вміст сеансу можна прочитати під час передавання мережею.

Чи підходить VPS як робочий стіл?

Як основний комп’ютер для щоденної роботи — ні. Причини накопичуються. GPU немає, тому все відображає CPU. Кожна натиснута клавіша залежить від мережевого обміну. Затримка 40 мс, яка майже непомітна в SSH, відчувається в текстовому редакторі. Відео стискається двічі: спочатку сайтом, а потім кодувальником RDP. Файли зберігаються на диску, який вам не належить фізично. Інтенсивне використання робочого столу швидко витрачає місячний ліміт трафіку, розрахований на web server.

Як тимчасова машина VPS дуже зручний. Ті самі властивості пояснюють чому. IP-адреса стабільна та належить data centre. Це потрібно, коли сервіс має бачити незмінну адресу. Машину можна відновити з image за кілька хвилин. Тому заражена сесія не створює значних витрат. VPS ізольований від вашого реального обладнання та продовжує працювати, коли ноутбук закритий. Погодинна оплата робить тимчасовий робочий стіл недорогим.

Якщо ви ще визначаєте призначення цієї машини, перед встановленням робочого столу варто прочитати практичний перелік завдань, для яких підходить VPS. Якщо робочий стіл потрібен через одну Windows-програму, спочатку порівняйте це рішення з реальними відмінностями між Linux і Windows Server. Ліцензія впливає на вартість такого рішення.

FAQ

Чи можна запустити віддалений робочий стіл на VPS із 2 GB?

Так, із легким робочим столом. XFCE або LXQt використовує приблизно 300–400 MB після входу в систему, тому для браузера з кількома вкладками залишається достатньо пам’яті. GNOME або KDE Plasma на VPS із 2 GB майже не залишає пам’яті для застосунків. Додайте файл підкачки розміром 2 GB, щоб під час нестачі пам’яті система сповільнювалася, а не завершувала процеси. Якщо щось зникає без повідомлення, перевірте dmesg | grep -i "killed process" на наявність повідомлень про завершення процесів засобом out-of-memory killer ядра.

Чи потрібно відкривати порт 3389 у firewall мого VPS?

Ні. TCP 3389 постійно сканують, а відкритий екран входу RDP провокує підбір паролів. Установіть port=tcp://.:3389 у /etc/xrdp/xrdp.ini, щоб xrdp прослуховував лише 127.0.0.1, перевірте це за допомогою ss -tlnp | grep 3389 і підключайтеся через ssh -N -L 3389:127.0.0.1:3389 you@vps.example.com. Якщо користувачів більше одного або двох, прив’яжіть xrdp до адреси WireGuard, а не до loopback.

Чому xrdp запитує «Authentication is required to create a color managed device»?

Служба colord запитує дозвіл у polkit, а polkit без запиту надає цей дозвіл лише локальній сесії користувача. Сесія RDP не є локальною, тому під час кожного входу з’являється запит пароля. В Ubuntu 24.04 старе виправлення .pkla не працює, оскільки polkit 124 більше не підтримує локальні authority-файли. Створіть /etc/polkit-1/rules.d/45-allow-colord.rules із правилом JavaScript, яке повертає polkit.Result.YES для ідентифікаторів дій, що починаються з org.freedesktop.color-manager., а потім виконайте sudo systemctl restart polkit.

Чи можна розмістити self-hosted сервер RustDesk за nginx або Traefik?

Основну службу — ні. hbbs і hbbr використовують власні бінарні протоколи, а не HTTP, тому для маршрутизації немає заголовка Host. Крім того, UDP 21116 взагалі не може проходити через HTTP proxy. Відкрийте TCP 21115–21119 і UDP 21116 у firewall та дозвольте клієнтам підключатися безпосередньо. Порти websocket 21118 і 21119, які використовує web-клієнт, працюють через HTTP і можуть бути розміщені за proxy. У такому разі налаштуйте firewall так, щоб доступ до них мав лише proxy, оскільки hbbs довіряє X-Real-IP у цих з’єднаннях.

Чому в моїй сесії xrdp немає звуку?

Ubuntu 24.04 використовує PipeWire, тоді як перенаправлення звуку в xrdp розраховане на PulseAudio. Тому звук недоступний, доки не встановити bridge. Виконайте sudo apt install -y pipewire-module-xrdp, потім повністю вийдіть із сесії та увійдіть знову, оскільки модуль завантажується під час запуску сесії, а повторне підключення не завантажить його. Перевірте результат за допомогою pactl list short sinks: серед sink має бути такий, що містить xrdp. Також переконайтеся, що клієнт запитує передачу звуку. У xfreerdp3 для цього використовується прапорець /sound, а в клієнті Windows — параметр «Remote audio».