ద్వారా Matt Connor 2026-08-13 · అప్‌డేట్ చేయబడింది 2026-08-16

Linux VPSలో Remote Desktop: xrdp, XFCE లేదా RustDesk?

Linux VPSలో నిజమైన graphical desktop కోసం xrdp, XFCE అమర్చండి. port 3389 తెరవకుండా SSH tunnel వాడటం, RustDesk సరిపోయే సందర్భం, ఎంపిక తేడాలు తెలుసుకోండి.

Linux VPSలో remote desktop అంటే వాస్తవంగా ఏమిటి

“Linux VPSలో remote desktop” అనే శోధనకు రెండు వేర్వేరు ఉత్పత్తులు సరిపోతాయి. తప్పు ఎంపిక చేస్తే ఒక మధ్యాహ్నం సమయం వృథా కావచ్చు. మొదటిది remote-access broker. RustDesk యొక్క self-hosted server దీనికి సాధారణ ఉదాహరణ. ఇది మీకు ఇప్పటికే ఉన్న రెండు కంప్యూటర్ల మధ్య sessionను relay చేస్తుంది. ఉదాహరణకు, మీ laptop మరియు ఇంటి PC మధ్య. అద్దెకు తీసుకున్న serverలో ఎలాంటి desktop ప్రదర్శించబడదు. అది రెండు endpointsను పరస్పరం పరిచయం చేసి, అవి నేరుగా ఒకదానితో ఒకటి చేరుకోలేనప్పుడు packetsను forward చేస్తుంది. రెండవది అద్దెకు తీసుకున్న serverలోనే నడిచే నిజమైన graphical desktop. ఇందులో pixels data centreలో render అయి, మీకు stream చేయబడతాయి. దీనికి xrdp, VNC (virtual network computing) లేదా container workspace ఉపయోగించవచ్చు.

వాటిని వేరు చేసే ఒక ప్రశ్న ఉంది. ఇది పనిచేసిన తర్వాత mouse pointer ఎక్కడ ఉంటుంది? మీరు ఇప్పటికే కలిగి ఉన్న కంప్యూటర్‌లో pointer ఉండాలంటే broker కావాలి. VPSలోనే pointer ఉండాలంటే VPSలో desktop కావాలి. దిగువ వివరణలో ఎక్కువ భాగం రెండవ సందర్భానికే సంబంధించినది, ఎందుకంటే చాలా guides ఈ సందర్భాన్ని వివరించవు.

మీ పనికి సరిపోయే ఎంపిక

మీ స్వంత relay తో RustDesk. అపరిచితులు నిర్వహించే public rendezvous server ద్వారా session traffic వెళ్లకుండా ఇది రక్షిస్తుంది, ఎందుకంటే key pair మీ వద్ద ఉంటుంది. ఇది నియంత్రించబడుతున్న machine ను రక్షించదు. మీరు client install చేసిన అదే PC, దానిలో ఉన్న అదే password తో కొనసాగుతుంది.
SSH tunnel లేదా VPN ద్వారా xrdp. TCP 3389 పై internet-wide scanning మరియు RDP login box పై password guessing నుంచి ఇది రక్షిస్తుంది, ఎందుకంటే ఆ port internet కు ఎప్పుడూ ప్రత్యక్షంగా ఉండదు. Tunnel ఇప్పటికే పొందిన వ్యక్తి నుంచి weak account password ను ఇది రక్షించదు.
అదే tunnel ద్వారా VNC. RDP కంటే పాతది, సరళమైనది అయిన protocol ఉపయోగించి, disconnection తర్వాత కూడా కొనసాగే desktop session ను ఇది అందిస్తుంది. ఒంటరిగా ఇది ఏదీ రక్షించదు. మొత్తం security tunnel పై ఆధారపడి ఉంటుంది. అందువల్ల public port పై VNC మాత్రమే నడపడం ఇక్కడి అత్యంత చెడు ఎంపిక.
Webtop లేదా Kasm వంటి container workspace. తొలగించి మళ్లీ నిర్మించగల container లో browser లేదా పూర్తి desktop ను ఇది అందిస్తుంది. ఆ browser ఉపయోగించే వనరుల నుంచి మీ నిజమైన machine ను ఇది రక్షిస్తుంది. Host ను మాత్రం రక్షించదు. ఈ images విస్తృత privileges తో, లోపల password లేని sudo తో నడుస్తాయి. అందువల్ల hostile workload కు ఈ container ను విశ్వసించదగిన boundary గా పరిగణించకూడదు.

Ubuntu 24.04లో xrdp మరియు XFCEను ఇన్‌స్టాల్ చేయడం

VPS సర్వర్ image లో graphical desktop ఉండదు. ముందుగా ఒక desktop ను ఇన్‌స్టాల్ చేయాలి. తరువాత RDP (remote desktop protocol) మాట్లాడే open-source సర్వర్ అయిన xrdp ను ఇన్‌స్టాల్ చేయాలి. Windows client కూడా ఇదే protocol ను ఉపయోగిస్తుంది. తేలికపాటి desktop ను ఎంచుకోండి. సాధారణంగా XFCE సరైన ఎంపిక.

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

August 2026 నాటికి Ubuntu 24.04లో universe component ద్వారా xrdp 0.9.24 మరియు xorgxrdp అందుబాటులో ఉన్నాయి. xorgxrdp ను పేరు ద్వారా ఇన్‌స్టాల్ చేయండి. ఇది recommended package మాత్రమే అయినప్పటికీ, దీన్ని ఇన్‌స్టాల్ చేయాలి. కొత్త session కోసం xrdp ప్రారంభించే X server backend ఇదే. ఇది లేకపోతే login box మీ password ను స్వీకరించిన తరువాత మిమ్మల్ని మళ్లీ login box కు తీసుకెళ్తుంది.

ఇప్పుడు ప్రారంభించాల్సిన desktop ను session కు తెలియజేయండి. xrdp /etc/xrdp/startwm.sh ను అమలు చేస్తుంది. ఆ file ఉన్నప్పుడు అది ~/.xsession ను అమలు చేస్తుంది.

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

చివరగా, clients కు అందించే TLS (transport layer security) key ను xrdp చదవాలి. ఆ file mode 640తో ఉంటుంది. దాని group యజమాని ssl-cert.

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

ఆ listing లో -rw-r----- 1 root ssl-cert కనిపిస్తుంది. id xrdp groups లో ssl-cert ను చూపించకపోతే, ముందుగా sudo adduser xrdp ssl-cert ను, తరువాత sudo systemctl restart xrdp ను అమలు చేయండి. ఈ దశను వదిలేస్తే xrdp key ను తెరవలదు. అప్పుడు /var/log/xrdp.log ఆ వైఫల్యాన్ని snakeoil filename ఉన్న line లో నమోదు చేస్తుంది.

ఇంటర్నెట్‌కు port 3389 ను ఎందుకు తెరవకూడదు

ఇంటర్నెట్‌లోని ప్రతి వ్యవస్థ TCP 3389 ను నిరంతరం scan చేస్తుంది. RDP login box ప్రతి password ప్రయత్నానికి స్పందిస్తుంది. దీన్ని తెరవకండి. బదులుగా xrdp ను loopback address కు bind చేసి, మీరు ఇప్పటికే విశ్వసించే tunnel ద్వారా దాన్ని యాక్సెస్ చేయండి.

/etc/xrdp/xrdp.ini ను సవరించి, [Globals] section లో listener ను మార్చండి.

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

షిప్ అయ్యే file తన comments లో ఆ syntax ను వివరిస్తుంది: tcp://.:3389 అంటే 127.0.0.1:3389, tcp://:3389 అంటే ప్రతి interface. Restart చేసి నిర్ధారించండి. ఇక్కడ typo ఉంటే service అన్ని addresses పై listening చేస్తూనే ఉంటుంది, కానీ స్పష్టమైన error కనిపించకపోవచ్చు.

sudo systemctl restart xrdp
ss -tlnp | grep 3389

మీకు కావలసింది 127.0.0.1:3389. 0.0.0.0:3389 కనిపిస్తే xrdp మీ మార్పును పరిగణించలేదు. సాధారణంగా line file లో తరువాత ఉన్న వేరే section heading కిందకు వెళ్లడం దీనికి కారణం.

ఇప్పుడు మీ స్వంత machine నుంచి tunnel ప్రారంభించండి.

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

-N అంటే “connection ను తెరవండి, కానీ command ను అమలు చేయవద్దు” అని అర్థం. అందువల్ల session port ను తరలించడానికి మాత్రమే ఉంటుంది. ఆ terminal ను తెరిచి ఉంచి, RDP client ను 127.0.0.1:3389 కు point చేయండి. Linux client లో software FreeRDP 3. Ubuntu 24.04 లో దాని binary పేరు xfreerdp3:

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

Windows లో built-in mstsc ను ఉపయోగించి, computer గా 127.0.0.1 ను నమోదు చేయండి. మొదటిసారి connect చేసినప్పుడు FreeRDP certificate ను trust చేయమని అడుగుతుంది. అది Do you trust the above certificate? (Y/T/N) ను చూపిస్తుంది. self-signed snakeoil certificate ఉపయోగిస్తున్నప్పుడు ఇది సాధారణమే.

ssh bind [127.0.0.1]:3389: Address already in use అని చూపిస్తే, మీ స్వంత machine లో ఇప్పటికే ఏదో ఒక process 3389 ను ఉపయోగిస్తోంది. ssh -N -L 13389:127.0.0.1:3389 you@vps.example.com తో local end ను మార్చి, 127.0.0.1:13389 కు connect చేయండి.

ప్రతి వ్యక్తికి ఒక tunnel ఏర్పాటు చేయడం త్వరగా అసౌకర్యంగా మారుతుంది. అందువల్ల team కోసం private network మెరుగైన పరిష్కారం. box ను self-hosted WireGuard VPN వెనుక ఉంచి, దానికి tunnel address 10.8.0.1 ఇవ్వండి. xrdp VPN లోపల మాత్రమే స్పందించేలా port=tcp://10.8.0.1:3389 ను సెట్ చేయండి. ఏ విధానాన్ని ఎంచుకున్నా, 3389 కోసం firewall rule అసలు ఉండకూడదు. మీ ప్రస్తుత rules ఏమి అనుమతిస్తున్నాయో తెలియకపోతే, VPSలో ufw firewall ప్రాథమికాలు నుంచి ప్రారంభించి, connect చేసిన తర్వాత కాకుండా connect చేయడానికి ముందే పరిశీలించండి.

2 GB VPSలో remote desktop ఎంత RAM ఉపయోగిస్తుంది

మీరు ఎంచుకునే desktop వల్ల 2 GB plan సౌకర్యవంతంగా ఉంటుందా లేదా పూర్తిగా సరిపోకపోతుందా అనేది నిర్ణయమవుతుంది. దిగువ గణాంకాలు Ubuntu 24.04లో login చేసిన వెంటనే memory వినియోగానికి సంబంధించిన సాధారణ rounded విలువలు. ఇవి మీ machineలో కొలిచినవి కావు; ప్రచురితమైన పోలికల ఆధారంగా ఇచ్చినవి. Connect అయిన వెంటనే మీ స్వంత వినియోగాన్ని free -m తో కొలవండి.

ChartTypical memory in use after login, Ubuntu 24.04 (published figures)

label

idle_ram_mb

LXQt

300

XFCE

400

MATE

500

KDE Plasma

800

GNOME

1,200

The data behind this chart

[
  {
    "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 desktops మధ్య ఉన్న తేడానే ముఖ్యమైన విషయం. LXQt సుమారు 300 MB, XFCE సుమారు 400 MB memory ఉపయోగిస్తాయి. అందువల్ల 2 GB machineలో browser కోసం రెండింటిలోనూ కొంత memory మిగులుతుంది. మీరు ఒక్క window కూడా తెరవకముందే GNOMEకు సుమారు 1,200 MB అవసరం. కాబట్టి 2 GBలో మిగిలిన memory కోసం browser మరియు desktop పోటీ పడతాయి.

నిజమైన ఖర్చు desktop shellది కాదు; browserదే. ఆధునిక browser ప్రతి active tabకు సాధారణంగా 150 నుంచి 400 MB వరకు ఉపయోగిస్తుంది. అందువల్ల XFCE నడుస్తున్న 2 GB VPS కొద్దిమంది tabsను నిర్వహించిన తర్వాత swapping ప్రారంభిస్తుంది. Processలను terminate చేయకుండా machine నెమ్మదించేందుకు swap జోడించండి: sudo fallocate -l 2G /swapfile, తరువాత sudo chmod 600 /swapfile, sudo mkswap /swapfile, sudo swapon /swapfile అమలు చేసి, reboot తర్వాత కూడా swap అందుబాటులో ఉండేలా /etc/fstabలో సరిపోలే line జోడించండి. ఎటువంటి warning లేకుండా ఏదైనా process ఆగిపోతే dmesg | grep -i "killed process" అమలు చేయండి. ఆ line ప్రకారం kernel యొక్క out-of-memory killer ఆ processను ముగించింది. సాధారణంగా ప్రభావితమయ్యేది browserే.

CPU మరో పరిమితి. దీన్ని తక్కువగా అంచనా వేయడం సులభం. VPSలో GPU ఉండదు. అందువల్ల X, llvmpipe ద్వారా software renderingకు మారుతుంది. అంటే ప్రతి pixelను CPU render చేయాలి. భారమైన pageను scroll చేయడం, video play చేయడం రెండూ సాధారణ CPU loadగా కనిపిస్తాయి. Machine పూర్తిగా నిలిచిపోవడం బదులు frame rate తగ్గుతుంది. VPSలో గేమ్‌లు ఆడగలరా అని మీరు ఆలోచించినప్పుడు ఎదురయ్యే పరిమితి కూడా ఇదే. 3D పనులకు సమాధానం లేదు. కారణం ఇదే.

xrdp sessionలో ధ్వని మరియు clipboard

Ubuntu 24.04 ఆడియో కోసం PipeWire ను ఉపయోగిస్తుంది. xrdp యొక్క sound redirection మాత్రం PulseAudio ఆధారంగా రూపొందించబడింది. అందువల్ల తాజా installationలో video పనిచేసినా ధ్వని వినిపించదు. Ubuntu ఈ రెండింటి మధ్య bridge ను packageగా అందిస్తుంది.

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

RDP session నుంచి పూర్తిగా log out చేసి మళ్లీ log in అవ్వండి, ఎందుకంటే session ప్రారంభమైనప్పుడు module load అవుతుంది. Reconnect చేయడం సరిపోదు. తరువాత session లోపల ఈ command ను పరిశీలించండి:

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

పేరు xrdp ను సూచించే sink కనిపించాలి. Test tone మీ client ద్వారా వినిపించాలి. xrdp sink కనిపించకపోతే module ఈ sessionలో load కాలేదు. మీ client కూడా audio కోసం అభ్యర్థించాలి. అంటే xfreerdp3 పై /sound flag ఉండాలి. Windows clientలో Local Resources కింద "Remote audio" settingను కూడా enable చేయవచ్చు.

మీ session కోసం xrdp-chansrv నడుస్తున్నప్పుడు text clipboard రెండు దిశల్లో పనిచేస్తుంది. xrdp దీన్ని మీ కోసం start చేస్తుంది. దీన్ని pgrep -a xrdp-chansrv తో నిర్ధారించండి. Session మధ్యలో copy and paste పనిచేయడం ఆగిపోతే ఆ process ఆగిపోయినట్లు అర్థం. Reconnect చేస్తే అది మళ్లీ start అవుతుంది. Textకు బదులుగా files copy చేయడం వేరే channel ద్వారా జరుగుతుంది. దాన్ని drive redirection అంటారు: xfreerdp3 పై /drive:home,/home/you ఒక local folderను remote sessionలో mount చేస్తుంది.

మొదటి login సమయంలో సాధారణంగా కనిపించే ఆశ్చర్యకరమైన విషయం Authentication is required to create a color managed device అనే సందేశంతో కూడిన dialog. దీనికి నిర్దిష్ట కారణం ఉంది. colord service అనుమతి కోసం polkit ను అడుగుతుంది. polkit స్థానికంగా కూర్చున్న session గా పరిగణించే session కు మాత్రమే ఆ చర్యకు అనుమతిని నిశ్శబ్దంగా ఇస్తుంది. RDP session ను స్థానిక session గా పరిగణించదు. అందువల్ల polkit మీ password ను అడుగుతుంది. Ubuntu 24.04 లో polkit 124 వస్తుంది. ఇందులో పాత local authority .pkla files తొలగించబడ్డాయి. కాబట్టి /etc/polkit-1/localauthority/50-local.d/45-allow-colord.pkla రాయమని చెప్పే ప్రతి guide 24.04 లో ఎలాంటి ప్రభావం చూపదు. బదులుగా JavaScript rule రాయండి.

/* /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 ను run చేసి మళ్లీ connect అవ్వండి. లక్షణాల ఆధారంగా గుర్తించగల మరో రెండు వైఫల్యాలు ఉన్నాయి.

Login box మీ password ను స్వీకరించిన వెంటనే మళ్లీ అదే login box కు వస్తుంది. Session ప్రారంభమై వెంటనే ఆగిపోయింది. ముందుగా /var/log/xrdp-sesman.log ను చదవండి. తరువాత మీ home directory లోని ~/.xsession-errors ను పరిశీలించండి. xorgxrdp లేకపోవడం, ఇన్‌స్టాల్ చేయని desktop ను సూచించే ~/.xsession, మీరు రాయలేని home directory లేదా పూర్తిగా నిండిన disk — ఇవన్నీ ఈ పరిస్థితికి దారితీస్తాయి.

మీరు connect అయినప్పుడు X cursor తో grey screen కనిపిస్తుంది. X ప్రారంభమైంది, కానీ desktop ప్రారంభం కాలేదు. ఇది మళ్లీ ~/.xsession సమస్య. SSH ద్వారా xfce4-session ను చేతితో run చేసి, అది చూపించే error ను చదవండి.

self-hosted RustDesk server చేసే పని

RustDesk రెండు processes‌గా విభజించబడుతుంది. hbbs అనేది clients register అయ్యే ID మరియు rendezvous server. నేరుగా peer-to-peer connection విఫలమైనప్పుడు session traffic‌ను relay చేసే service hbbr. వీటిలో ఏదీ desktop‌ను నడపదు. రెండూ ఒకే image నుంచి వస్తాయి. Project ప్రచురించే compose file ఇదే; ఇందులో relay address‌ను మీ స్వంత host name‌కు మార్చారు:

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

దీన్ని ప్రారంభించి, మొదటిసారి start అయినప్పుడు server రూపొందించిన public key‌ను చదవండి:

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

ప్రతి client‌లో మీ host name మరియు ఆ public key అవసరం. RustDesk client‌లోని Network settings కింద రెండింటినీ నమోదు చేయాలి. సరిపోలే private key ./data/id_ed25519 లో ఉంటుంది. Data directory‌ను తొలగిస్తే server కొత్త key pair‌ను రూపొందిస్తుంది. అందువల్ల ప్రతి client‌ను కొత్త keyతో మళ్లీ configure చేయాలి. ఆ directory‌కు backup తీసుకోండి.

Firewall ఈ ports‌కు నేరుగా అనుమతి ఇవ్వాలి. hbbs TCP 21115, 21116, 21118 మరియు UDP 21116 ports‌ను ఉపయోగిస్తుంది. hbbr TCP 21117 మరియు 21119 ports‌ను ఉపయోగిస్తుంది.

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 వెనుక ఎందుకు ఉంచలేము

ప్రతి సేవకు ఒకే reverse proxy వద్ద TLS termination నిర్వహించే నిర్వాహకులు సాధారణంగా ఈ విధానాన్ని ప్రయత్నించి విఫలమవుతారు. hbbs మరియు hbbr HTTPపై కాకుండా TCP మరియు UDP ద్వారా తమ స్వంత binary protocols ను ఉపయోగిస్తాయి. Route చేయడానికి Host header ఉండదు. పరిశీలించడానికి HTTP request కూడా ఉండదు. అందువల్ల nginx లోని server block లేదా Traefik HTTP router కు సరిపోల్చడానికి ఏదీ ఉండదు. 21116 పై ఉన్న UDP listener ఏ స్థాయిలోనూ HTTP అంశం కాదు.

రెండు విధానాలు పనిచేస్తాయి. nginx stream block ద్వారా TCP ports ను forward చేయగలదు. ఇది సాధారణ అర్థంలో reverse proxy కాకుండా plain layer 4 forwarding. అలాగే 21118 మరియు 21119 ports RustDesk web client ఉపయోగించే websockets ను మోస్తాయి. అవి సాధారణ HTTP కాబట్టి, ఈ రెండు ports ను మీ proxy వెనుక ఉంచవచ్చు. అలా చేస్తే, 21118 మరియు 21119 ను proxy మాత్రమే చేరుకోగలిగేలా firewall rules జోడించండి. ఎందుకంటే websocket connections లోని X-Real-IP header పై ఆధారపడి వాస్తవ client address ను hbbs గుర్తిస్తుంది.

కంటైనర్‌లో తాత్కాలిక బ్రౌజర్

కొన్నిసార్లు మీకు కావలసింది మారని IPతో, మీ స్వంత మెషీన్‌కు దూరంగా నడిచే స్వచ్ఛమైన బ్రౌజర్ మాత్రమే. కంటైనర్ workspace దీన్ని చాలా తక్కువ software install తో అందిస్తుంది. LinuxServer యొక్క Webtop తక్కువ వనరులు ఉపయోగించే ఎంపిక:

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 ద్వారా HTTP, port 3001 ద్వారా HTTPS అందుతాయి. ఎక్కడా RDP client లేకుండానే browser tab లో desktop ను తెరవవచ్చు. Image tags ద్వారా అనేక base distributions పై XFCE, KDE, MATE మరియు i3 అందుబాటులో ఉంటాయి. ఈ project documentation ప్రమాదాన్ని స్పష్టంగా చెబుతుంది: కంటైనర్‌కు host పై privileged access ఉంటుంది. ఇందులో passwordless sudo తో terminal కూడా ఉంటుంది. అందువల్ల రక్షణ లేకుండా దీన్ని internet కు అందుబాటులో ఉంచకూడదు. అందుకే పై ports అన్ని addresses పై publish చేయకుండా 127.0.0.1 కు bind చేయబడ్డాయి. xrdp కోసం ఉపయోగించిన అదే SSH tunnel లేదా అదే VPN ద్వారా దీన్ని access చేయండి.

Kasm Workspaces ఇదే భావనను చాలా పెద్ద స్థాయిలో అందిస్తుంది. ఇందులో web console, user accounts మరియు session ముగిసినప్పుడు reset అయ్యే ప్రతి-session containers ఉంటాయి. చిన్న VPS కంటే దీనికి ఎక్కువ machine resources అవసరం. August 2026 నాటికి documentation లో పేర్కొన్న కనీస అవసరాలు 2 CPU cores, 4 GB memory మరియు 50 GB SSD. దీనికి అదనంగా ప్రతి user session కు default గా 2 cores మరియు 2768 MB కేటాయించబడతాయి. 2 GB plan పై ఇది నడవదు. Installation కోసం download చేసి script అమలు చేయాలి:

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, drawing commands కు బదులుగా framebuffer updates ను పంపుతుంది. అందువల్ల slow link పై ఇది RDP కంటే ఎక్కువ భారంగా అనిపిస్తుంది. దీనిలో sound channel కూడా ఉండదు. ఒక సందర్భంలో మాత్రం ఇది ఉపయోగకరంగా ఉంటుంది: మీరు disconnect చేసిన తర్వాత కూడా desktop session నడుస్తూ ఉండాలి, తిరిగి వచ్చినప్పుడు అదే session మళ్లీ అందుబాటులో ఉండాలి. TigerVNC దీన్ని అందిస్తుంది. vncserver -localhost yes :1 Xvnc ను TCP 5901 లో 127.0.0.1 కు bind చేస్తుంది. ఇతర ఏ ప్రదేశం నుంచి వచ్చే connections ను ఇది నిరాకరిస్తుంది. అందువల్ల ssh -N -L 5901:127.0.0.1:5901 you@vps.example.com తో xrdp ను tunnel చేసినట్లే దీన్ని కూడా tunnel చేయాలి. VNC port ను ఎప్పుడూ public గా publish చేయవద్దు. చాలా VNC servers handshake సమయంలో password ను మాత్రమే రక్షిస్తాయి. ఆ తర్వాతి డేటాను రక్షించవు. కాబట్టి public port పై session contents network లో plain text గా చదవగలిగే విధంగా ఉంటాయి.

VPS మంచి desktop అవుతుందా?

ప్రతిరోజూ ఉపయోగించే ప్రధాన desktop‌గా కాదు. దీనికి కారణాలు అనేకం ఉన్నాయి. GPU ఉండదు, కాబట్టి అన్ని గ్రాఫిక్స్ పనులను CPU నిర్వహిస్తుంది. ప్రతి keystroke network round trip కోసం వేచి ఉంటుంది. SSHలో 40 ms latency సరిపడినట్లు అనిపించినా, text editorలో అది స్పష్టంగా తెలుస్తుంది. Videoను రెండుసార్లు compress చేస్తారు: మొదట site, తరువాత RDP encoder. మీ files మీరు ప్రత్యక్షంగా నియంత్రించని diskలో ఉంటాయి. Heavy desktop వినియోగం web server కోసం నిర్ణయించిన monthly bandwidth పరిమితిని త్వరగా వినియోగిస్తుంది.

తాత్కాలికంగా ఉపయోగించి తొలగించే machineగా మాత్రం ఇది చాలా మంచిది. దానికి కారణం కూడా ఇదే లక్షణాలు. IP address స్థిరంగా ఉంటుంది, అలాగే data centreకు చెందినదిగా ఉంటుంది. ఒక serviceకు స్థిరమైన address కనిపించాల్సినప్పుడు ఇది ఉపయోగకరం. Machineను image నుంచి నిమిషాల్లో rebuild చేయవచ్చు. కాబట్టి ఏదైనా హానికరమైనది ప్రవేశించిన session వల్ల మీకు నష్టం ఉండదు. ఇది మీ నిజమైన hardware నుంచి వేరుగా ఉంటుంది. మీ laptop మూసివేసినా ఇది నడుస్తూనే ఉంటుంది. Hourly billing వల్ల తాత్కాలిక desktop చవకగా ఉంటుంది.

ఈ machine ఏ పని కోసం అనేది ఇంకా నిర్ణయించుకుంటుంటే, desktop install చేయడానికి ముందు VPS ఏ పనులకు ఉపయోగకరమో తెలిపే ఆచరణాత్మక జాబితా చదవడం మంచిది. Desktop కావడానికి కారణం ఒక Windows application మాత్రమే అయితే, ముందుగా Linux మరియు Windows Server మధ్య వాస్తవ తేడాలు పరిశీలించండి. ఎందుకంటే licence వల్ల మొత్తం ఖర్చు మారుతుంది.

FAQ

2 GB VPSపై remote desktop నడపవచ్చా?

అవును, తక్కువ వనరులు ఉపయోగించే desktop తో నడపవచ్చు. Login చేసిన తర్వాత XFCE లేదా LXQt సుమారుగా 300 నుంచి 400 MB ఉపయోగిస్తాయి. అందువల్ల కొన్ని tabs ఉన్న browser కు తగిన memory మిగులుతుంది. 2 GBలో GNOME లేదా KDE Plasma నడిపితే applications కోసం దాదాపు memory మిగలదు. 2 GB swap file జోడించండి. అప్పుడు memory pressure processes ను terminate చేయడానికి బదులుగా machine ను నెమ్మదిస్తుంది. ఎటువంటి message లేకుండా ఏదైనా అదృశ్యమైతే, kernel out-of-memory killer కోసం dmesg | grep -i "killed process" ను పరిశీలించండి.

నా VPS firewallలో port 3389 తెరవాలా?

వద్దు. TCP 3389ను నిరంతరం scan చేస్తుంటారు. బయటకు కనిపించే RDP login box password guessing కు అవకాశం ఇస్తుంది. /etc/xrdp/xrdp.ini లో port=tcp://.:3389 ను set చేయండి, తద్వారా xrdp 127.0.0.1లో మాత్రమే listen చేస్తుంది. ss -tlnp | grep 3389 తో దీనిని నిర్ధారించి, ssh -N -L 3389:127.0.0.1:3389 you@vps.example.com తో దీనికి connect అవ్వండి. ఒకరు లేదా ఇద్దరికంటే ఎక్కువ మంది ఉపయోగిస్తే, xrdpను loopbackకు బదులుగా WireGuard addressకు bind చేయండి.

xrdp "Authentication is required to create a color managed device" అని ఎందుకు అడుగుతుంది?

colord service అనుమతి కోసం polkitను అడుగుతుంది. Locally seated sessionకు మాత్రమే polkit ఆ చర్యకు password లేకుండా అనుమతి ఇస్తుంది. RDP session seated session కాదు. అందువల్ల ప్రతి login సమయంలో password prompt కనిపిస్తుంది. Ubuntu 24.04లో పాత .pkla పరిష్కారం పనిచేయదు. polkit 124 local authority filesను తొలగించింది. JavaScript rule కలిగిన /etc/polkit-1/rules.d/45-allow-colord.rules ను సృష్టించండి. ఆ rule, org.freedesktop.color-manager. తో ప్రారంభమయ్యే action ids కోసం polkit.Result.YES ను return చేయాలి. తరువాత sudo systemctl restart polkit ను run చేయండి.

self-hosted RustDesk serverను nginx లేదా Traefik వెనుక ఉంచవచ్చా?

ప్రధాన serviceను ఉంచలేరు. hbbs మరియు hbbr HTTPకు బదులుగా తమ స్వంత binary protocolsను ఉపయోగిస్తాయి. అందువల్ల route చేయడానికి Host header ఉండదు. అదనంగా UDP 21116 HTTP proxy ద్వారా వెళ్లదు. Firewallలో TCP 21115 నుంచి 21119 వరకు మరియు UDP 21116ను open చేసి, clientsను నేరుగా connect అవ్వనివ్వండి. Web client ఉపయోగించే websocket ports 21118 మరియు 21119 HTTP ఆధారితమైనవి. వాటిని proxy వెనుక ఉంచవచ్చు. అలా చేస్తే proxy మాత్రమే వాటిని చేరగలిగేలా firewallలో పరిమితం చేయండి. ఎందుకంటే ఆ connectionsపై hbbs X-Real-IP ను నమ్ముతుంది.

నా xrdp sessionలో sound ఎందుకు లేదు?

Ubuntu 24.04 PipeWireను ఉపయోగిస్తుంది. అయితే xrdp sound redirection PulseAudio కోసం రూపొందించబడింది. అందువల్ల bridge install చేసే వరకు audio అందుబాటులో ఉండదు. sudo apt install -y pipewire-module-xrdp ను run చేయండి. తరువాత session నుంచి పూర్తిగా log out చేసి, మళ్లీ log in అవ్వండి. Module session ప్రారంభంలో load అవుతుంది. Reconnect చేసినంత మాత్రాన అది load కాదు. xrdp పేరుతో ఉన్న sink కోసం pactl list short sinks తో తనిఖీ చేయండి. Client audioను request చేస్తోందని నిర్ధారించండి. xfreerdp3 పై ఇది /sound flag, Windows clientలో "Remote audio"గా ఉంటుంది.

#remote-desktop#xrdp#rustdesk#vnc#self-hosting

Linux VPSలో remote desktop అంటే వాస్తవంగా ఏమిటి

మీ పనికి సరిపోయే ఎంపిక

Ubuntu 24.04లో xrdp మరియు XFCEను ఇన్‌స్టాల్ చేయడం

ఇంటర్నెట్‌కు port 3389 ను ఎందుకు తెరవకూడదు

2 GB VPSలో remote desktop ఎంత RAM ఉపయోగిస్తుంది

xrdp sessionలో ధ్వని మరియు clipboard

polkit popup మరియు మొదటి login సమయంలో ఎదురయ్యే ఇతర వైఫల్యాలు

self-hosted RustDesk server చేసే పని

RustDesk ను nginx లేదా Traefik వెనుక ఎందుకు ఉంచలేము

కంటైనర్‌లో తాత్కాలిక బ్రౌజర్

VNC మరియు ఇది ఇప్పటికీ ఉపయోగపడే సందర్భం

VPS మంచి desktop అవుతుందా?

FAQ

2 GB VPSపై remote desktop నడపవచ్చా?

నా VPS firewallలో port 3389 తెరవాలా?

xrdp "Authentication is required to create a color managed device" అని ఎందుకు అడుగుతుంది?

self-hosted RustDesk serverను nginx లేదా Traefik వెనుక ఉంచవచ్చా?

నా xrdp sessionలో sound ఎందుకు లేదు?