SSD Nodes Learn Hosting plans →
गाइड Matt Connorलेखक: Matt Connor · अपडेट किया गया: 2026-08-25

Linux VPS पर Remote Desktop कैसे सेटअप करें

Linux VPS पर xrdp और XFCE के साथ graphical desktop सेटअप करने का सही तरीका जानें। सुरक्षा के लिए port 3389 खोलने के बजाय SSH tunnel का उपयोग करें और RustDesk के अंतर को समझें।

Linux VPS पर remote desktop का वास्तविक अर्थ

"Linux VPS पर remote desktop" सर्च करने पर दो अलग-अलग उत्पाद सामने आते हैं, और गलत विकल्प चुनने से आपका काफी समय बर्बाद हो सकता है। पहला एक remote-access broker है। RustDesk का self-hosted server इसका एक सामान्य उदाहरण है: यह आपके द्वारा पहले से उपयोग किए जा रहे दो उपकरणों, जैसे कि आपके लैपटॉप और घर के PC, के बीच एक session को relay करता है। किराए पर लिया गया सर्वर कोई desktop नहीं बनाता है। यह केवल दोनों सिरों को एक-दूसरे से जोड़ता है और जब वे सीधे एक-दूसरे से संपर्क नहीं कर पाते, तो packets को forward करता है। दूसरा, किराए पर लिए गए सर्वर पर चलने वाला एक वास्तविक graphical desktop है, जहाँ pixels data centre में बनते हैं और आप तक stream किए जाते हैं। यह xrdp, VNC (virtual network computing), या container workspace है।

एक सवाल इन दोनों के बीच अंतर स्पष्ट करता है। एक बार जब यह काम करने लगे, तो mouse pointer कहाँ रहता है? यदि आप अपने पास मौजूद किसी मशीन का उपयोग कर रहे हैं, तो आपको एक broker की आवश्यकता है। यदि आप सीधे VPS पर काम करना चाहते हैं, तो आपको VPS पर एक desktop चाहिए। नीचे दी गई जानकारी का अधिकांश हिस्सा दूसरे मामले पर केंद्रित है, क्योंकि अधिकांश मार्गदर्शिकाएँ (guides) इसी को छोड़ देती हैं।

कौन सा विकल्प आपके काम के लिए उपयुक्त है

  • अपने स्वयं के relay के साथ RustDesk। यह session को किसी अनजान व्यक्ति द्वारा चलाए जा रहे public rendezvous server से गुजरने से बचाता है, क्योंकि key pair आपके पास होता है। यह उस machine की सुरक्षा नहीं करता जिसे control किया जा रहा है, क्योंकि वह वही PC रहता है जिस पर आपने client install किया है, और उसका password भी वही रहता है।
  • SSH tunnel या VPN के माध्यम से xrdp। यह आपको TCP 3389 की निरंतर internet-wide scanning और RDP login box पर password guessing के प्रयासों से बचाता है, क्योंकि वह port कभी भी internet के सामने नहीं होता। यदि किसी के पास पहले से ही tunnel का access है, तो यह कमजोर account password को सुरक्षा प्रदान नहीं करता है।
  • उसी tunnel के माध्यम से VNC। यह आपको एक desktop session देता है जो disconnection के बाद भी बना रहता है, और यह RDP से पुराना और सरल protocol है। अपने आप में यह कुछ भी सुरक्षित नहीं करता है: tunnel ही सारी सुरक्षा का काम करती है, इसलिए public port पर केवल VNC का उपयोग करना यहाँ सबसे खराब विकल्प है।
  • Webtop या Kasm जैसा container workspace। यह आपको एक browser या पूरा desktop एक ऐसे container में देता है जिसे आप हटाकर फिर से बना सकते हैं, जो आपकी वास्तविक machine को उस हर चीज से बचाता है जिसे वह browser छूता है। यह host की सुरक्षा नहीं करता है: ये images व्यापक विशेषाधिकारों और बिना password वाले sudo के साथ चलती हैं, इसलिए container ऐसी सीमा नहीं है जिस पर आप hostile workload के मामले में भरोसा कर सकें।

Ubuntu 24.04 पर xrdp और XFCE इंस्टॉल करना

VPS सर्वर इमेज में कोई ग्राफिकल डेस्कटॉप नहीं होता है। आप एक डेस्कटॉप इंस्टॉल करते हैं, और फिर xrdp इंस्टॉल करते हैं। यह एक ओपन-सोर्स सर्वर है जो RDP (रिमोट डेस्कटॉप प्रोटोकॉल) का उपयोग करता है, वही प्रोटोकॉल जिसका उपयोग Windows क्लाइंट करते हैं। एक हल्का डेस्कटॉप चुनें, और XFCE इसके लिए सबसे उपयुक्त विकल्प है।

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

अगस्त 2026 तक, Ubuntu 24.04 के universe कंपोनेंट में xrdp 0.9.24 और xorgxrdp उपलब्ध हैं। xorgxrdp को नाम से इंस्टॉल करें, भले ही यह केवल एक अनुशंसित पैकेज हो: यह वह X सर्वर बैकएंड है जिसे xrdp नए सत्र के लिए शुरू करता है। इसके बिना, लॉगिन बॉक्स आपका पासवर्ड स्वीकार कर लेगा, लेकिन आपको वापस लॉगिन बॉक्स पर ही भेज देगा।

अब सत्र को बताएं कि कौन सा डेस्कटॉप शुरू करना है। xrdp /etc/xrdp/startwm.sh चलाता है, जो उस फाइल के मौजूद होने पर ~/.xsession को निष्पादित करता है।

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

अंत में, xrdp को उस TLS (ट्रांसपोर्ट लेयर सिक्योरिटी) की (key) को पढ़ने की आवश्यकता होती है जिसे वह क्लाइंट्स को प्रदान करता है। उस फाइल का मोड 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 की (key) को नहीं खोल पाएगा, और /var/log/xrdp.log लाइन में snakeoil फाइलनाम के साथ विफलता को रिकॉर्ड करेगा।

आपको इंटरनेट पर port 3389 क्यों नहीं खोलना चाहिए

TCP 3389 को इंटरनेट पर मौजूद हर चीज़ द्वारा लगातार स्कैन किया जाता है, और एक RDP लॉगिन बॉक्स हर पासवर्ड प्रयास का विनम्रतापूर्वक उत्तर देता है। इसे न खोलें। इसके बजाय xrdp को loopback address पर bind करें, और इसे एक ऐसे tunnel के माध्यम से एक्सेस करें जिस पर आप पहले से भरोसा करते हैं।

/etc/xrdp/xrdp.ini को edit करें और [Globals] सेक्शन में listener को बदलें।

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

shipped फाइल में वह सिंटैक्स उसके अपने comments में प्रलेखित है: tcp://.:3389 का अर्थ है 127.0.0.1:3389, और tcp://:3389 का अर्थ है सभी इंटरफेस। इसे restart करें और पुष्टि करें, क्योंकि यहाँ एक टाइपो (typo) सेवा को चुपचाप सभी पतों पर खुला छोड़ देता है।

sudo systemctl restart xrdp
ss -tlnp | grep 3389

आपको 127.0.0.1:3389 चाहिए। 0.0.0.0:3389 देखने का मतलब है कि xrdp ने आपके संपादन को अनदेखा कर दिया है, आमतौर पर इसलिए क्योंकि वह लाइन फाइल में नीचे किसी अन्य सेक्शन हेडिंग के अंतर्गत चली गई है।

अब अपनी मशीन से tunnel खोलें।

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

-N का अर्थ है "कनेक्शन खोलें लेकिन कोई कमांड न चलाएं", इसलिए सेशन केवल पोर्ट को ले जाने के लिए मौजूद रहता है। उस टर्मिनल को चालू रखें और RDP क्लाइंट को 127.0.0.1:3389 पर पॉइंट करें। 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) प्रिंट करता है, जो self-signed 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 से कनेक्ट करें।

प्रति व्यक्ति एक tunnel बनाना थकाऊ हो जाता है, इसलिए एक टीम के लिए बेहतर उत्तर एक प्राइवेट नेटवर्क है। बॉक्स को एक self-hosted WireGuard VPN के पीछे रखें, इसे tunnel एड्रेस 10.8.0.1 दें, और port=tcp://10.8.0.1:3389 सेट करें ताकि xrdp केवल VPN के अंदर ही उत्तर दे। किसी भी स्थिति में, 3389 के लिए firewall नियम बिल्कुल नहीं होना चाहिए। यदि आप सुनिश्चित नहीं हैं कि आपके वर्तमान नियम क्या अनुमति देते हैं, तो VPS पर ufw firewall की बुनियादी बातें से शुरुआत करें और कनेक्ट करने से पहले जाँचें, बाद में नहीं।

2 GB VPS पर remote desktop कितनी RAM का उपयोग करता है

आप कौन सा desktop चुनते हैं, यह तय करता है कि 2 GB का plan आपके लिए आरामदायक होगा या बेकार। नीचे दिए गए आंकड़े Ubuntu 24.04 पर login के तुरंत बाद उपयोग की जाने वाली memory के अनुमानित मान हैं, जिन्हें प्रकाशित तुलनाओं से लिया गया है, न कि आपकी मशीन पर मापा गया है। कनेक्ट करने के तुरंत बाद free -m का उपयोग करके स्वयं मापें।

ChartTypical memory in use after login, Ubuntu 24.04 (published figures)
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 पर रहता है, इसलिए दोनों ही 2 GB के box पर browser के लिए जगह छोड़ते हैं। GNOME को एक भी window खोलने से पहले लगभग 1,200 MB की आवश्यकता होती है, जो 2 GB पर browser को बची हुई memory के लिए desktop से संघर्ष करने पर मजबूर कर देता है।

असली लागत desktop shell नहीं, बल्कि browser है। एक आधुनिक browser प्रति active tab 150 से 400 MB के बीच memory लेता है, इसलिए XFCE चलाने वाला 2 GB का VPS कुछ tabs तो संभाल लेगा, लेकिन उसके बाद swapping शुरू हो जाएगी। Swap जोड़ें ताकि processes को kill करने के बजाय मशीन धीमी हो जाए: sudo fallocate -l 2G /swapfile, फिर sudo chmod 600 /swapfile, sudo mkswap /swapfile, sudo swapon /swapfile चलाएं, और /etc/fstab में एक matching line जोड़ें ताकि यह reboot के बाद भी बना रहे। जब कोई चीज़ बिना किसी चेतावनी के गायब हो जाए, तो dmesg | grep -i "killed process" चलाएं। उस line का अर्थ है कि kernel के out-of-memory killer ने उसे समाप्त कर दिया है, और browser ही आमतौर पर इसका शिकार होता है।

CPU दूसरी सीमा है, और इसे कम आंकना आसान है। VPS में कोई GPU नहीं होता, इसलिए X, llvmpipe के माध्यम से software rendering पर निर्भर करता है, जिसका अर्थ है कि CPU हर pixel को draw करता है। भारी page को scroll करना और video चलाना दोनों ही CPU load के रूप में दिखाई देते हैं, और मशीन के freeze होने के बजाय frame rate गिर जाता है। यदि आप सोच रहे थे कि क्या आप VPS पर gaming कर सकते हैं, तो आप उसी बाधा का सामना करेंगे: किसी भी 3D चीज़ के लिए उत्तर 'नहीं' है, और ठीक इसी कारण से।

xrdp सत्र में साउंड और क्लिपबोर्ड

Ubuntu 24.04 ऑडियो के लिए PipeWire का उपयोग करता है, जबकि xrdp का साउंड रीडायरेक्शन PulseAudio के लिए बनाया गया था। इसलिए, एक नए इंस्टॉलेशन में वीडियो तो काम करता है, लेकिन साउंड नहीं आता। Ubuntu इसके लिए एक ब्रिज पैकेज प्रदान करता है।

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 का उल्लेख हो, और आपको अपने क्लाइंट के माध्यम से टेस्ट टोन सुनाई देनी चाहिए। यदि xrdp सिंक नहीं दिखता है, तो इसका मतलब है कि मॉड्यूल इस सत्र में लोड नहीं हुआ है। आपके क्लाइंट को भी ऑडियो का अनुरोध करना होगा: यह xfreerdp3 पर /sound फ्लैग है, या Windows क्लाइंट में Local Resources के अंतर्गत "Remote audio" सेटिंग है।

जब आपके सत्र के लिए xrdp-chansrv चल रहा होता है, तो टेक्स्ट क्लिपबोर्ड दोनों दिशाओं में काम करता है; xrdp इसे आपके लिए शुरू करता है। इसकी पुष्टि pgrep -a xrdp-chansrv से करें। यदि सत्र के दौरान कॉपी और पेस्ट काम करना बंद कर देता है, तो इसका मतलब है कि वह प्रक्रिया समाप्त हो गई है, और रीकनेक्ट करने से वह पुनः शुरू हो जाएगी। टेक्स्ट के बजाय फ़ाइलों को कॉपी करना एक अलग चैनल है जिसे ड्राइव रीडायरेक्शन कहा जाता है: xfreerdp3 पर /drive:home,/home/you एक स्थानीय फ़ोल्डर को रिमोट सत्र में माउंट करता है।

Polkit पॉपअप और पहली बार लॉगिन करने पर आने वाली अन्य त्रुटियाँ

पहली बार लॉगिन करने पर सबसे आम समस्या Authentication is required to create a color managed device वाला डायलॉग बॉक्स है। इसका कारण विशिष्ट है। colord सर्विस polkit से अनुमति मांगती है, polkit यह अनुमति केवल उसी सेशन को चुपचाप देता है जिसे वह स्थानीय रूप से सक्रिय (locally seated) मानता है, और RDP सेशन को सक्रिय नहीं माना जाता है, इसलिए polkit आपसे पासवर्ड मांगता है। Ubuntu 24.04 में polkit 124 है, जिसमें पुरानी स्थानीय अथॉरिटी .pkla फाइलें हटा दी गई हैं, इसलिए वे सभी गाइड जिनमें /etc/polkit-1/localauthority/50-local.d/45-allow-colord.pkla लिखने के लिए कहा गया है, वे 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 है: SSH के माध्यम से मैन्युअल रूप से xfce4-session चलाएं और जो त्रुटि यह प्रिंट करता है उसे पढ़ें।

self-hosted RustDesk सर्वर क्या करता है

RustDesk दो प्रक्रियाओं में विभाजित होता है। hbbs वह ID और rendezvous सर्वर है जिसके साथ क्लाइंट रजिस्टर होते हैं, और hbbr वह relay है जो तब session को ले जाता है जब direct peer-to-peer कनेक्शन विफल हो जाता है। इनमें से कोई भी desktop नहीं चलाता है। दोनों एक ही image से आते हैं, और यह वह 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 करें, और फिर उस public key को पढ़ें जिसे सर्वर ने अपनी पहली शुरुआत पर generate किया है:

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 को delete करने पर सर्वर एक नया pair generate करता है, इसलिए प्रत्येक client को फिर नई key के साथ reconfigure करना पड़ता है। उस directory का backup लें। यदि यह आपकी टीम के लिए हर मशीन तक पहुँचने का तरीका बन जाता है, न कि केवल सप्ताहांत का प्रयोग, तो RustDesk relay का एक समर्पित build Ed25519 key handling, latest के बजाय pinned image tags, और आपके plan द्वारा भुगतान की जाने वाली relay bandwidth के लिए अनुसरण करने योग्य है।

Firewall को इन ports को सीधे अनुमति देनी होगी। 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 के पीछे क्यों काम नहीं करता है

जो पाठक पहले से ही अपने सभी ट्रैफिक के लिए एक reverse proxy पर TLS termination का उपयोग करते हैं, वे इसे आज़माते हैं और विफल हो जाते हैं। hbbs और hbbr अपने स्वयं के binary protocols का उपयोग TCP और UDP पर करते हैं, न कि HTTP का। इसमें routing के लिए कोई Host header नहीं होता और न ही निरीक्षण करने के लिए कोई HTTP request होती है, इसलिए nginx server block या Traefik HTTP router के पास मिलान करने के लिए कुछ नहीं होता है। 21116 पर UDP listener किसी भी layer पर HTTP नहीं है।

दो तरीके काम करते हैं। nginx TCP ports को stream block के साथ forward कर सकता है, जो सामान्य reverse proxy के बजाय plain layer 4 forwarding है। और ports 21118 तथा 21119 उन websockets को ले जाते हैं जिनका उपयोग RustDesk web client करता है, जो सामान्य HTTP है, इसलिए उन दोनों को आपके proxy के पीछे रखा जा सकता है। यदि आप ऐसा करते हैं, तो firewall rules जोड़ें ताकि केवल proxy ही 21118 और 21119 तक पहुँच सके, क्योंकि hbbs वास्तविक client address का पता लगाने के लिए websocket connections पर X-Real-IP header पर भरोसा करता है।

कंटेनर में एक डिस्पोजेबल ब्राउज़र

कभी-कभी आपको केवल एक साफ-सुथरे ब्राउज़र की आवश्यकता होती है जिसका IP बदलता न हो, और जो आपकी अपनी मशीन से अलग रहे। एक कंटेनर वर्कस्पेस बहुत कम सॉफ्टवेयर इंस्टॉल करके यह काम कर देता है। 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 और 3001 पर HTTPS सेवा मिलती है, और आप बिना किसी RDP क्लाइंट के ब्राउज़र टैब में ही डेस्कटॉप तक पहुँच जाते हैं। इमेज टैग्स में कई बेस डिस्ट्रीब्यूशन पर XFCE, KDE, MATE और i3 शामिल हैं। प्रोजेक्ट का अपना डॉक्यूमेंटेशन जोखिम के बारे में स्पष्ट है: कंटेनर के पास होस्ट का प्रिविलेज्ड एक्सेस होता है और इसमें पासवर्ड रहित sudo वाला टर्मिनल शामिल है, इसलिए इसे असुरक्षित रूप से इंटरनेट पर नहीं छोड़ना चाहिए। यही कारण है कि ऊपर दिए गए पोर्ट्स को सभी एड्रेस पर पब्लिश करने के बजाय 127.0.0.1 पर बाइंड किया जाता है। इसे उसी SSH टनल या VPN के माध्यम से एक्सेस करें जिसका उपयोग आपने xrdp के लिए किया था।

Kasm Workspaces भी इसी विचार पर आधारित है, लेकिन यह काफी बड़े आकार का है। इसमें वेब कंसोल, यूजर अकाउंट्स और प्रति-सत्र (per-session) कंटेनर होते हैं जो सत्र समाप्त होने पर रीसेट हो जाते हैं। इसे एक छोटे VPS की तुलना में अधिक मशीन संसाधनों की आवश्यकता होती है। अगस्त 2026 तक, डॉक्यूमेंटेड न्यूनतम आवश्यकता 2 CPU कोर, 4 GB मेमोरी और 50 GB SSD है, और प्रत्येक यूजर सत्र के लिए इसके ऊपर अतिरिक्त 2 कोर और 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 की तुलना में भारी महसूस होता है और इसमें कोई sound channel नहीं होता है। यह एक स्थिति में अपनी जगह बनाता है: जब आप एक ऐसा desktop session चाहते हैं जो disconnect होने के बाद भी चलता रहे, और वापस आने पर आपको वही session दोबारा मिल जाए। TigerVNC ऐसा करता है। vncserver -localhost yes :1 Xvnc को 127.0.0.1 पर TCP 5901 के साथ bind करता है, और कहीं और से आने वाले connections को अस्वीकार कर देता है, इसलिए आप इसे बिल्कुल xrdp की तरह ssh -N -L 5901:127.0.0.1:5901 you@vps.example.com के साथ tunnel करते हैं। VNC port को कभी भी public न करें। अधिकांश VNC servers handshake के दौरान पासवर्ड की सुरक्षा करते हैं, लेकिन उसके बाद कुछ नहीं, इसलिए public port पर session की सामग्री को नेटवर्क पर आसानी से पढ़ा जा सकता है।

क्या VPS एक अच्छा डेस्कटॉप है?

दैनिक उपयोग के लिए, नहीं, और इसके कई कारण हैं। इसमें GPU नहीं होता, इसलिए CPU को ही सब कुछ रेंडर करना पड़ता है। हर कीस्ट्रोक नेटवर्क राउंड ट्रिप का इंतज़ार करता है, और 40 ms की लेटेंसी जो SSH में सामान्य लगती है, टेक्स्ट एडिटर में महसूस होने लगती है। वीडियो दो बार कंप्रेस होता है, एक बार साइट द्वारा और दूसरी बार RDP एनकोडर द्वारा। आपकी फाइलें ऐसी डिस्क पर होती हैं जिस पर आपका भौतिक नियंत्रण नहीं है, और डेस्कटॉप का भारी उपयोग उस मासिक बैंडविड्थ को खत्म कर देता है जिसे वेब सर्वर के लिए निर्धारित किया गया था।

एक डिस्पोजेबल मशीन के रूप में यह बहुत अच्छा है, और यही गुण इसके कारण भी हैं। IP एड्रेस स्थिर होता है और डेटा सेंटर का होता है, जो तब आवश्यक है जब किसी सर्विस को एक सुसंगत एड्रेस की आवश्यकता हो। मशीन कुछ ही मिनटों में इमेज से रीबिल्ड हो जाती है, इसलिए यदि किसी सेशन में कोई समस्या आ जाए तो आपका कोई नुकसान नहीं होता। यह आपके वास्तविक हार्डवेयर से अलग रहता है, और आपके लैपटॉप के बंद होने पर भी चलता रहता है। प्रति घंटा बिलिंग एक अस्थायी डेस्कटॉप को सस्ता बनाती है।

यदि आप अभी भी यह तय कर रहे हैं कि यह मशीन किस काम के लिए है, तो VPS किन कार्यों के लिए अच्छा है, इसकी व्यावहारिक सूची को डेस्कटॉप इंस्टॉल करने से पहले पढ़ना उचित है। और यदि आप डेस्कटॉप इसलिए चाहते थे क्योंकि आपको कोई एक Windows एप्लिकेशन चलाना है, तो पहले Linux और Windows Server के बीच वास्तविक अंतर को समझें, क्योंकि लाइसेंस के कारण समाधान की लागत बदल जाती है।

FAQ

क्या मैं 2 GB VPS पर remote desktop चला सकता हूँ?

हाँ, एक हल्के desktop environment के साथ। login के बाद XFCE या LXQt लगभग 300 से 400 MB RAM का उपयोग करते हैं, जिससे browser और कुछ tabs के लिए पर्याप्त जगह बच जाती है। 2 GB RAM पर GNOME या KDE Plasma चलाने से applications के लिए लगभग कुछ नहीं बचता। 2 GB की swap file जोड़ें ताकि memory का दबाव बढ़ने पर machine धीमी हो जाए, न कि processes बंद हो जाएं। यदि कोई process बिना किसी संदेश के बंद हो जाती है, तो 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 सेट करें ताकि xrdp केवल 127.0.0.1 पर listen करे, इसे ss -tlnp | grep 3389 से confirm करें, और इसे ssh -N -L 3389:127.0.0.1:3389 you@vps.example.com के माध्यम से access करें। यदि एक या दो से अधिक लोग हैं, तो xrdp को loopback के बजाय WireGuard address पर bind करें।

xrdp "Authentication is required to create a color managed device" क्यों पूछता है?

colord service polkit से अनुमति मांगती है, और polkit यह क्रिया केवल स्थानीय रूप से seated session को चुपचाप प्रदान करता है। RDP session seated नहीं होता, इसलिए आपको हर login पर password prompt मिलता है। Ubuntu 24.04 पर पुराना .pkla समाधान काम नहीं करता, क्योंकि polkit 124 ने local authority files को हटा दिया है। /etc/polkit-1/rules.d/45-allow-colord.rules बनाएँ जिसमें एक JavaScript rule हो जो org.freedesktop.color-manager. से शुरू होने वाली action ids के लिए polkit.Result.YES return करे, फिर sudo systemctl restart polkit चलाएँ।

क्या मैं self-hosted RustDesk server को nginx या Traefik के पीछे रख सकता हूँ?

मुख्य service को नहीं। hbbs और hbbr HTTP के बजाय अपने स्वयं के binary protocols का उपयोग करते हैं, इसलिए routing के लिए कोई Host header नहीं होता, और UDP 21116 किसी HTTP proxy से होकर नहीं गुजर सकता। firewall पर TCP 21115 से 21119 और UDP 21116 खोलें और clients को सीधे connect होने दें। web client द्वारा उपयोग किए जाने वाले websocket ports 21118 और 21119, HTTP हैं और proxy के पीछे रह सकते हैं। यदि आप ऐसा करते हैं, तो उन्हें firewall करें ताकि केवल proxy ही उन तक पहुँच सके, क्योंकि hbbs उन connections पर X-Real-IP पर भरोसा करता है।

मेरी xrdp session में sound क्यों नहीं है?

Ubuntu 24.04 PipeWire का उपयोग करता है जबकि xrdp का sound redirection PulseAudio के लिए बनाया गया था, इसलिए जब तक आप bridge install नहीं करते, audio नहीं मिलेगा। sudo apt install -y pipewire-module-xrdp चलाएँ, फिर session से पूरी तरह log out होकर दोबारा log in करें, क्योंकि module session शुरू होने पर load होता है और reconnect करने से यह load नहीं होगा। xrdp नाम वाले sink के लिए pactl list short sinks से जाँच करें, और सुनिश्चित करें कि client audio का अनुरोध कर रहा है, जो xfreerdp3 पर /sound flag है या Windows client में "Remote audio" विकल्प है।