Zdalny pulpit na Linux VPS: konfiguracja krok po kroku

Co w rzeczywistości oznacza zdalny pulpit na VPS z systemem Linux

Dwa różne produkty odpowiadają na zapytanie „zdalny pulpit na VPS z systemem Linux”, a wybór niewłaściwego oznacza stratę popołudnia. Pierwszym z nich jest broker zdalnego dostępu. Samodzielnie hostowany serwer RustDesk jest typowym przykładem: przekazuje on sesję między dwiema maszynami, które już posiadasz, na przykład laptopem i komputerem domowym. Wynajęty serwer nie renderuje żadnego pulpitu. Łączy on obie strony ze sobą i przesyła pakiety, gdy nie mogą one nawiązać bezpośredniego połączenia. Drugim rozwiązaniem jest rzeczywisty graficzny pulpit działający na wynajętym serwerze, dzięki czemu piksele są renderowane w centrum danych i przesyłane strumieniowo do użytkownika. Są to xrdp, VNC (virtual network computing) lub kontenerowe środowisko pracy.

Jedno pytanie pozwala je rozróżnić. Gdy rozwiązanie już działa, gdzie znajduje się wskaźnik myszy? Jeśli na maszynie, którą już posiadasz, potrzebujesz brokera. Jeśli na samym VPS, potrzebujesz pulpitu na VPS. Drugiemu przypadkowi poświęcono większość poniższej treści, ponieważ jest to scenariusz pomijany w większości poradników.

Wybór odpowiedniego rozwiązania

• RustDesk z własnym przekaźnikiem (relay). Chroni sesję przed przechodzeniem przez publiczny serwer rendezvous obsługiwany przez nieznane podmioty, ponieważ para kluczy pozostaje w posiadaniu użytkownika. Nie zabezpiecza jednak kontrolowanej maszyny, która nadal pozostaje tym samym komputerem z zainstalowanym klientem i jego bieżącymi hasłami.
• xrdp przez tunel SSH lub VPN. Chroni przed ciągłym skanowaniem portu TCP 3389 w Internecie oraz przed próbami odgadnięcia hasła w oknie logowania RDP, ponieważ port ten nie jest wystawiony na zewnątrz. Nie chroni jednak słabego hasła do konta przed osobą, która uzyskała dostęp do tunelu.
• VNC przez ten sam tunel. Zapewnia sesję pulpitu, która przetrwa rozłączenie, wykorzystując protokół starszy i prostszy niż RDP. Sam w sobie nie zapewnia żadnej ochrony: to tunel odpowiada za bezpieczeństwo, dlatego uruchomienie VNC na publicznym porcie jest najgorszym z wymienionych rozwiązań.
• Środowisko kontenerowe, takie jak Webtop lub Kasm. Udostępnia przeglądarkę lub pełny pulpit w kontenerze, który można usunąć i odtworzyć, co chroni fizyczną maszynę przed działaniami wykonywanymi wewnątrz przeglądarki. Nie zabezpiecza jednak hosta: obrazy te działają z szerokimi uprawnieniami i bezhasłowym sudo wewnątrz, dlatego kontenera nie należy traktować jako bezpiecznej granicy w przypadku uruchamiania niebezpiecznych zadań.

Instalacja xrdp i XFCE na Ubuntu 24.04

Obraz serwera VPS jest dostarczany bez graficznego środowiska pulpitu. Należy je zainstalować, a następnie dodać xrdp, czyli otwartoźródłowy serwer obsługujący RDP (remote desktop protocol), ten sam protokół, którego używa klient Windows. Wybierz lekkie środowisko graficzne; XFCE jest standardowym rozwiązaniem.

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

Ubuntu 24.04 zawiera xrdp w wersji 0.9.24 oraz xorgxrdp w repozytorium universe (stan na sierpień 2026). Zainstaluj xorgxrdp, mimo że jest to tylko pakiet zalecany: stanowi on backend serwera X, który xrdp uruchamia dla nowej sesji. Bez niego okno logowania przyjmuje hasło, a następnie natychmiast wraca do ekranu logowania.

Teraz wskaż sesji, które środowisko graficzne ma zostać uruchomione. xrdp wykonuje skrypt /etc/xrdp/startwm.sh, który uruchamia ~/.xsession, jeśli ten plik istnieje.

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

Na koniec, xrdp musi odczytać klucz TLS (transport layer security), który oferuje klientom. Plik ten posiada uprawnienia 640 i należy do grupy ssl-cert.

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

Lista pokazuje -rw-r----- 1 root ssl-cert. Jeśli id xrdp nie wyświetla ssl-cert na liście grup, wykonaj sudo adduser xrdp ssl-cert, a następnie sudo systemctl restart xrdp. Pomiń ten krok, a xrdp nie będzie w stanie otworzyć klucza, a /var/log/xrdp.log zarejestruje błąd z nazwą pliku snakeoil w wierszu.

Dlaczego nie należy otwierać portu 3389 dla Internetu

Port TCP 3389 jest nieustannie skanowany przez wszystkie boty w Internecie, a okno logowania RDP odpowiada na każdą próbę odgadnięcia hasła. Nie należy go otwierać. Zamiast tego należy powiązać xrdp z adresem pętli zwrotnej (loopback) i uzyskiwać do niego dostęp przez zaufany tunel.

Edytuj /etc/xrdp/xrdp.ini i zmień parametr nasłuchiwania w sekcji [Globals].

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

Dostarczony plik dokumentuje tę składnię w swoich komentarzach: tcp://.:3389 oznacza 127.0.0.1:3389, a tcp://:3389 oznacza wszystkie interfejsy. Zrestartuj usługę i sprawdź poprawność, ponieważ literówka w tym miejscu może spowodować, że usługa pozostanie dostępna na wszystkich adresach bez żadnego ostrzeżenia.

sudo systemctl restart xrdp
ss -tlnp | grep 3389

Wymagane jest ustawienie 127.0.0.1:3389. Jeśli widzisz 0.0.0.0:3389, oznacza to, że xrdp zignorowało edycję, zazwyczaj dlatego, że linia znalazła się pod innym nagłówkiem sekcji w dalszej części pliku.

Teraz otwórz tunel ze swojej maszyny.

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

-N oznacza „otwórz połączenie, ale nie wykonuj żadnego polecenia”, dzięki czemu sesja istnieje tylko w celu przenoszenia portu. Pozostaw ten terminal uruchomiony i skieruj klienta RDP na 127.0.0.1:3389. W systemie Linux klientem jest FreeRDP 3, którego plik binarny w Ubuntu 24.04 nazywa się xfreerdp3:

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

W systemie Windows użyj wbudowanego narzędzia mstsc i wpisz 127.0.0.1 jako nazwę komputera. FreeRDP poprosi o zaufanie certyfikatowi przy pierwszym połączeniu i wyświetli Do you trust the above certificate? (Y/T/N), co jest oczekiwanym zachowaniem w przypadku certyfikatu typu snakeoil.

Jeśli ssh odpowie bind [127.0.0.1]:3389: Address already in use, oznacza to, że coś na Twojej maszynie już zajmuje port 3389. Zmień lokalny koniec tunelu za pomocą ssh -N -L 13389:127.0.0.1:3389 you@vps.example.com i połącz się z 127.0.0.1:13389.

Jeden tunel na osobę staje się uciążliwy, więc dla zespołu lepszym rozwiązaniem jest sieć prywatna. Umieść serwer za własnym serwerem WireGuard VPN, nadaj mu adres tunelu 10.8.0.1 i ustaw port=tcp://10.8.0.1:3389, aby xrdp odpowiadało tylko wewnątrz sieci VPN. W każdym przypadku reguła firewalla dla portu 3389 nie powinna w ogóle istnieć. Jeśli nie masz pewności, na co pozwalają obecne reguły, zacznij od podstaw firewalla ufw na VPS i sprawdź to przed nawiązaniem połączenia, a nie po fakcie.

Ile pamięci RAM zużywa zdalny pulpit na VPS z 2 GB pamięci

Wybór środowiska graficznego decyduje o tym, czy plan 2 GB będzie komfortowy, czy bezużyteczny. Poniższe wartości to zaokrąglone, typowe zużycie pamięci zaraz po zalogowaniu do systemu Ubuntu 24.04, zaczerpnięte z opublikowanych porównań, a nie pomiarów na konkretnej maszynie. Własne zużycie należy sprawdzić za pomocą free -m bezpośrednio po nawiązaniu połączenia.

[
  {
    "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"
  }
]

W przypadku tych 5 środowisk graficznych kluczowe jest rozproszenie wyników. LXQt zużywa około 300 MB, a XFCE około 400 MB, więc oba te środowiska pozostawiają na maszynie 2 GB zapas na przeglądarkę. GNOME wymaga około 1,200 MB przed otwarciem jakiegokolwiek okna, co przy 2 GB RAM sprawia, że przeglądarka musi rywalizować ze środowiskiem graficznym o pozostałe zasoby.

Prawdziwym kosztem nie jest powłoka graficzna, lecz przeglądarka. Nowoczesna przeglądarka zużywa od 150 do 400 MB na każdą aktywną kartę, więc VPS z 2 GB RAM i środowiskiem XFCE obsłuży zaledwie kilka kart, zanim zacznie korzystać ze swapu. Należy dodać swap, aby maszyna zwolniła zamiast zabijać procesy: sudo fallocate -l 2G /swapfile, następnie sudo chmod 600 /swapfile, sudo mkswap /swapfile, sudo swapon /swapfile oraz odpowiedni wpis w /etc/fstab, aby konfiguracja przetrwała restart. Jeśli proces znika bez ostrzeżenia, należy uruchomić dmesg | grep -i "killed process". Taki komunikat oznacza, że mechanizm out-of-memory killer jądra systemu zakończył proces, a przeglądarka jest zazwyczaj pierwszą ofiarą.

Procesor jest drugim ograniczeniem i łatwo je nie docenić. VPS nie posiada GPU, więc Xorg przełącza się na renderowanie programowe przez llvmpipe, co oznacza, że procesor rysuje każdy piksel. Przewijanie ciężkiej strony i odtwarzanie wideo przekłada się na bezpośrednie obciążenie procesora, co powoduje spadek liczby klatek na sekundę zamiast całkowitego zawieszenia maszyny. Jest to ta sama bariera, na którą natrafisz, jeśli zastanawiasz się czy można grać na VPS: w przypadku jakiejkolwiek grafiki 3D odpowiedź brzmi nie, właśnie z tego powodu.

Dźwięk i schowek w sesji xrdp

Ubuntu 24.04 korzysta z PipeWire do obsługi dźwięku, natomiast przekierowanie dźwięku w xrdp zostało zaprojektowane dla PulseAudio, dlatego świeża instalacja zapewnia działający obraz, ale brak dźwięku. Ubuntu dostarcza odpowiedni mostek.

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

Wyloguj się całkowicie z sesji RDP i zaloguj ponownie, ponieważ moduł jest ładowany w momencie uruchamiania sesji. Samo ponowne połączenie nie wystarczy. Następnie sprawdź z wnętrza sesji:

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

Powinieneś zobaczyć ujście (sink), którego nazwa zawiera xrdp, oraz usłyszeć sygnał testowy przez klienta. Brak ujścia xrdp oznacza, że moduł nie załadował się do tej sesji. Twój klient musi również żądać przesyłania dźwięku: odpowiada za to flaga /sound w xfreerdp3 lub ustawienie "Remote audio" w sekcji Local Resources w kliencie Windows.

Schowek tekstowy działa w obu kierunkach, gdy xrdp-chansrv jest uruchomiony dla Twojej sesji, co xrdp wykonuje automatycznie. Potwierdź to za pomocą pgrep -a xrdp-chansrv. Jeśli kopiowanie i wklejanie przestanie działać w trakcie sesji, oznacza to, że proces został zakończony, a ponowne połączenie uruchomi go ponownie. Kopiowanie plików, w przeciwieństwie do tekstu, odbywa się osobnym kanałem zwanym przekierowaniem dysków: /drive:home,/home/you w xfreerdp3 montuje lokalny folder w sesji zdalnej.

Wyskakujące okno polkit i inne problemy przy pierwszym logowaniu

Najczęstszym zaskoczeniem przy pierwszym logowaniu jest okno dialogowe z komunikatem Authentication is required to create a color managed device. Przyczyna jest konkretna. Usługa colord prosi polkit o uprawnienia, polkit przyznaje je automatycznie tylko sesjom uznanym za lokalne, a sesja RDP nie jest tak traktowana, więc polkit domaga się podania hasła. Ubuntu 24.04 zawiera polkit 124, w którym usunięto stare pliki lokalnych uprawnień .pkla, dlatego każdy poradnik zalecający utworzenie /etc/polkit-1/localauthority/50-local.d/45-allow-colord.pkla nie przynosi w 24.04 żadnego efektu. Należy zamiast tego utworzyć regułę 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;
    }
});

Uruchom sudo systemctl restart polkit i połącz się ponownie. Warto znać jeszcze dwa inne rodzaje błędów na podstawie ich objawów.

Okno logowania przyjmuje hasło i natychmiast wraca do stanu początkowego. Sesja została uruchomiona i zakończona. Przeczytaj najpierw /var/log/xrdp-sesman.log, a następnie ~/.xsession-errors w swoim katalogu domowym. Brak xorgxrdp, ~/.xsession wskazujący na niezainstalowane środowisko graficzne, brak uprawnień do zapisu w katalogu domowym lub zapełniony dysk – wszystko to prowadzi do tego błędu.

Po połączeniu widać szary ekran z kursorem X. Serwer X wystartował, ale środowisko graficzne nie. To ponownie ~/.xsession: uruchom xfce4-session ręcznie przez SSH i odczytaj wyświetlony błąd.

Funkcja własnego serwera RustDesk

RustDesk dzieli się na dwa procesy. hbbs to serwer identyfikacji i rendezvous, w którym rejestrują się klienci, a hbbr to przekaźnik (relay), który obsługuje sesję, gdy bezpośrednie połączenie peer-to-peer zawiedzie. Żaden z nich nie uruchamia środowiska graficznego. Oba pochodzą z tego samego obrazu, a poniżej znajduje się plik compose opublikowany przez projekt, z adresem przekaźnika zmienionym na własną nazwę hosta:

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

Uruchom usługę, a następnie odczytaj klucz publiczny wygenerowany przez serwer przy pierwszym starcie:

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

Każdy klient wymaga podania nazwy hosta oraz tego klucza publicznego; oba parametry wprowadza się w ustawieniach sieci (Network settings) w kliencie RustDesk. Odpowiadający mu klucz prywatny pozostaje w ./data/id_ed25519. Usunięcie katalogu z danymi spowoduje wygenerowanie przez serwer nowej pary kluczy, co wymusi ponowną konfigurację wszystkich klientów. Wykonaj kopię zapasową tego katalogu. Jeśli rozwiązanie to stanie się głównym sposobem dostępu zespołu do maszyn, a nie tylko weekendowym eksperymentem, warto zapoznać się z dedykowaną kompilacją przekaźnika RustDesk, ze względu na obsługę kluczy Ed25519, przypięte tagi obrazów zamiast latest oraz przepustowość przekaźnika, za którą ostatecznie zapłacisz w ramach swojego planu.

Firewall musi zezwalać na bezpośredni ruch na tych portach. hbbs korzysta z TCP 21115, 21116 i 21118 oraz UDP 21116. hbbr korzysta z TCP 21117 i 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

Dlaczego RustDesk nie działa za nginx lub Traefik

Użytkownicy, którzy kończą połączenia TLS na jednym reverse proxy, często napotykają problemy przy próbie wdrożenia RustDesk. Usługi hbbs oraz hbbr wykorzystują własne protokoły binarne przesyłane przez TCP i UDP, a nie HTTP. Brak nagłówka Host uniemożliwia trasowanie, a brak żądania HTTP wyklucza inspekcję pakietów, dlatego blok server w nginx lub router HTTP w Traefik nie mają danych do dopasowania. Nasłuch UDP na porcie 21116 nie jest usługą HTTP na żadnej warstwie modelu sieciowego.

Działają dwa rozwiązania. nginx może przekazywać porty TCP za pomocą bloku stream, co stanowi zwykłe przekierowanie warstwy 4, a nie reverse proxy w typowym rozumieniu. Porty 21118 oraz 21119 obsługują natomiast websockets wykorzystywane przez klienta webowego RustDesk, co jest standardowym ruchem HTTP, więc te dwa porty mogą znajdować się za proxy. W takim przypadku należy dodać reguły firewall, aby tylko proxy miało dostęp do 21118 i 21119, ponieważ hbbs ufa nagłówkowi X-Real-IP w połączeniach websocket, aby poprawnie określić rzeczywisty adres klienta.

Jednorazowa przeglądarka w kontenerze

Czasami potrzebna jest po prostu czysta przeglądarka z niezmiennym adresem IP, odizolowana od własnego komputera. Środowisko pracy w kontenerze realizuje to zadanie przy znacznie mniejszej liczbie zainstalowanego oprogramowania. Webtop od LinuxServer to lekka opcja:

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

Port 3000 obsługuje HTTP, a 3001 HTTPS; dostęp do pulpitu uzyskuje się w karcie przeglądarki, bez konieczności używania klienta RDP. Tagi obrazów obejmują środowiska XFCE, KDE, MATE oraz i3 na kilku dystrybucjach bazowych. Dokumentacja projektu wprost wskazuje na ryzyko: kontener posiada uprzywilejowany dostęp do hosta i zawiera terminal z dostępem sudo bez hasła, dlatego nie powinien być wystawiony bezpośrednio na działanie Internetu bez zabezpieczeń. Z tego powodu powyższe porty są powiązane z 127.0.0.1, zamiast być publikowane na wszystkich adresach. Należy uzyskiwać do nich dostęp przez ten sam tunel SSH lub tę samą sieć VPN, która była używana dla xrdp.

Kasm Workspaces opiera się na tej samej koncepcji, lecz w znacznie większej skali, oferując konsolę webową, konta użytkowników oraz kontenery sesyjne, które resetują się po zakończeniu sesji. Rozwiązanie to wymaga większych zasobów, niż oferuje mały VPS. Według stanu na sierpień 2026 r. udokumentowane minimum to 2 rdzenie CPU, 4 GB pamięci RAM oraz 50 GB przestrzeni SSD, a każda sesja użytkownika domyślnie wymaga dodatkowo 2 rdzeni i 2768 MB pamięci. Plan z 2 GB pamięci RAM nie pozwoli na uruchomienie tego oprogramowania. Instalacja polega na pobraniu i uruchomieniu skryptu:

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 i jego obecne zastosowania

VNC przesyła aktualizacje bufora ramki zamiast poleceń rysowania, dlatego na wolnych łączach działa mniej płynnie niż RDP i nie obsługuje kanału dźwiękowego. Protokół ten znajduje zastosowanie w jednym przypadku: gdy wymagana jest sesja graficzna, która pozostaje aktywna po rozłączeniu i pozwala na powrót do tego samego stanu po ponownym połączeniu. TigerVNC realizuje to zadanie. vncserver -localhost yes :1 wiąże Xvnc z adresem 127.0.0.1 na porcie TCP 5901 i odrzuca połączenia z innych źródeł, dlatego należy tunelować go w taki sam sposób jak xrdp przy użyciu ssh -N -L 5901:127.0.0.1:5901 you@vps.example.com. Nigdy nie należy udostępniać portu VNC publicznie. Większość serwerów VNC zabezpiecza hasło jedynie podczas nawiązywania połączenia, nie szyfrując dalszej transmisji, co oznacza, że na publicznym porcie zawartość sesji jest możliwa do odczytania w sieci.

Czy VPS sprawdza się jako komputer stacjonarny?

Jako główne narzędzie pracy – nie, a powodów jest wiele. Brak GPU sprawia, że za renderowanie obrazu odpowiada CPU. Każde naciśnięcie klawisza wymaga czasu na przesłanie danych przez sieć, a 40 ms opóźnienia, które w SSH jest akceptowalne, staje się odczuwalne w edytorze tekstu. Obraz wideo jest kompresowany dwukrotnie: najpierw przez stronę, a następnie przez enkoder RDP. Pliki znajdują się na dysku, nad którym nie masz fizycznej kontroli, a intensywne użytkowanie pulpitu szybko wyczerpuje miesięczny limit transferu, który został przewidziany dla serwera WWW.

Jako maszyna tymczasowa VPS sprawdza się bardzo dobrze, a te same cechy to wyjaśniają. Adres IP jest stabilny i należy do centrum danych, co jest pożądane, gdy usługa wymaga stałego adresu. Maszynę można przywrócić z obrazu w kilka minut, więc sesja, w której pojawiło się zagrożenie, nie stanowi problemu. Jest ona odizolowana od Twojego fizycznego sprzętu i działa nawet po zamknięciu laptopa. Rozliczanie godzinowe sprawia, że jednorazowy pulpit jest tani.

Jeśli nadal zastanawiasz się, do czego służy taka maszyna, warto przeczytać praktyczną listę zastosowań VPS przed instalacją środowiska graficznego. Jeśli powodem chęci posiadania pulpitu była jedna aplikacja Windows, rozważ najpierw rzeczywiste różnice między Linux a Windows Server, ponieważ licencja zmienia koszt takiego rozwiązania.

FAQ

Czy mogę uruchomić zdalny pulpit na VPS z 2 GB pamięci RAM?

Tak, pod warunkiem użycia lekkiego środowiska graficznego. XFCE lub LXQt zużywa około 300 do 400 MB po zalogowaniu, co pozostawia wystarczająco dużo miejsca na przeglądarkę z kilkoma kartami. GNOME lub KDE Plasma na 2 GB RAM nie pozostawiają niemal żadnych zasobów dla aplikacji. Należy dodać plik wymiany (swap) o rozmiarze 2 GB, aby w przypadku braku pamięci system zwolnił działanie zamiast zabijać procesy. Jeśli procesy znikają bez komunikatu, należy sprawdzić dmesg | grep -i "killed process" pod kątem działania mechanizmu kernel out-of-memory killer.

Czy powinienem otwierać port 3389 na firewallu mojego VPS?

Nie. Port TCP 3389 jest stale skanowany, a wystawiony ekran logowania RDP zachęca do prób odgadnięcia hasła. Należy ustawić port=tcp://.:3389 w pliku /etc/xrdp/xrdp.ini, aby xrdp nasłuchiwał wyłącznie na 127.0.0.1, potwierdzić to za pomocą ss -tlnp | grep 3389 i łączyć się przez ssh -N -L 3389:127.0.0.1:3389 you@vps.example.com. W przypadku obsługi więcej niż jednej lub dwóch osób, należy powiązać xrdp z adresem WireGuard zamiast z interfejsem pętli zwrotnej.

Dlaczego xrdp pyta o uwierzytelnienie w celu utworzenia urządzenia zarządzanego kolorami?

Usługa colord prosi polkit o uprawnienia, a polkit przyznaje je automatycznie tylko dla sesji lokalnych. Sesja RDP nie jest traktowana jako lokalna, co skutkuje monitem o hasło przy każdym logowaniu. W systemie Ubuntu 24.04 stara metoda .pkla nie działa, ponieważ polkit 124 usunął obsługę plików lokalnych uprawnień. Należy utworzyć plik /etc/polkit-1/rules.d/45-allow-colord.rules zawierający regułę JavaScript, która zwraca polkit.Result.YES dla identyfikatorów akcji zaczynających się od org.freedesktop.color-manager., a następnie wykonać sudo systemctl restart polkit.

Czy mogę umieścić serwer RustDesk za nginx lub Traefik?

Nie w przypadku głównej usługi. hbbs i hbbr używają własnych protokołów binarnych zamiast HTTP, więc brak jest nagłówka Host, na podstawie którego można by kierować ruch, a port UDP 21116 nie może przechodzić przez proxy HTTP. Należy otworzyć porty TCP od 21115 do 21119 oraz UDP 21116 na firewallu i pozwolić klientom na bezpośrednie połączenie. Porty websocket 21118 i 21119, używane przez klienta webowego, obsługują HTTP i mogą znajdować się za proxy. W takim przypadku należy ograniczyć dostęp na firewallu tak, aby tylko proxy miało do nich dostęp, ponieważ hbbs ufa X-Real-IP w ramach tych połączeń.

Dlaczego w mojej sesji xrdp nie ma dźwięku?

Ubuntu 24.04 korzysta z PipeWire, podczas gdy przekierowanie dźwięku w xrdp zostało zaprojektowane dla PulseAudio, dlatego dźwięk nie działa do momentu zainstalowania mostka. Należy wykonać sudo apt install -y pipewire-module-xrdp, a następnie całkowicie wylogować się z sesji i zalogować ponownie, ponieważ moduł jest ładowany przy starcie sesji, a ponowne połączenie go nie załaduje. Należy sprawdzić za pomocą pactl list short sinks, czy istnieje ujście (sink) o nazwie xrdp, oraz upewnić się, że klient żąda dźwięku, co odpowiada fladze /sound w xfreerdp3 lub opcji "Remote audio" w kliencie Windows.