Remote Desktop

Sejauh ini seluruh section ini bekerja dalam teks: shell, berkas, dan kunci — dan untuk otomasi, teks memang rajanya. Tetapi ada saat-saat ketika layar benar-benar dibutuhkan: membantu kolega yang kesulitan di desktopnya, menjalankan aplikasi grafis yang hanya ada di server, atau mengelola mesin virtual lewat konsol grafisnya. Kebutuhan itu dilayani sekeluarga protokol remote desktop, dan bab ini memetakan pilihannya — VNC, RDP, SPICE, hingga X forwarding bawaan SSH — sebelum dua bab berikutnya membedah VNC dan xrdp satu per satu. Karena tidak ada server grafis di lingkungan latihan, bab ini bertumpu pada konsep, tabel, dan satu simulasi tunnel yang berjalan sungguhan: arsitektur keamanan yang membedakan remote desktop yang aman dari yang terbuka.

Kapan GUI Jarak Jauh Dibutuhkan #

Daftar kasusnya jauh lebih pendek daripada daftar kasus shell jarak jauh, dan itu disengaja. GUI jarak jauh pantas dipakai untuk: dukungan teknis yang perlu melihat layar user, aplikasi grafis khusus (CAD, IDE berat, alat desain) yang terpasang di workstation jauh, serta konsol grafis mesin virtual dan server instalasi. Sebaliknya, pekerjaan rutin — membaca log, me-restart service, menambal konfigurasi — tetap lebih cepat, lebih dapat diaudit, dan lebih dapat diotomasi lewat SSH. Prinsip praktisnya: remote desktop adalah pelengkap, bukan pengganti; sistem yang hanya bisa dikelola lewat GUI adalah sistem yang sulit diotomasi.

Peta Protokol: VNC, RDP, dan SPICE #

Tiga nama mendominasi lanskap remote desktop di Linux:

VNC (Virtual Network Computing) berbicara protokol RFB dan mengirim gambar layar yang berubah — sederhana, tetapi klasiknya tanpa enkripsi. RDP datang dari dunia Microsoft; dengan xrdp, server Linux menerima klien Windows bawaan tanpa perangkat lunak tambahan, menjadikannya favorit di kantor campuran. SPICE dibesarkan di dunia virtualisasi KVM: satu level lebih dekat ke mesin virtualnya, dengan akselerasi dan latensi yang dirancang untuk konsol VM.

VNC punya kebiasaan penomoran yang perlu dihafal: satu server VNC adalah satu display bernomor, dan portnya selalu 5900 ditambah nomor display itu. Aritmetikanya bisa kita lihat sekali jalan:

for tampilan in 0 1 2 3; do
  echo "display :$tampilan -> port $((5900 + tampilan))"
done

Output yang Dihasilkan:

display :0 -> port 5900
display :1 -> port 5901
display :2 -> port 5902
display :3 -> port 5903

1. for tampilan in 0 1 2 3: loop berjalan untuk empat nomor display pertama — cukup untuk melihat polanya.
2. $((5900 + tampilan)): ekspansi aritmetika bash menghitung port untuk tiap display; ketika kita menemukan port 5902 terbuka di sebuah mesin, kebalikannya juga bisa dihitung: itu display :2.

Konsekuensi praktisnya: firewall VNC harus membuka rentang port (5900 sampai 5900 + jumlah display), dan localhost:5901 pada klien VNC berarti “port 5901”, bukan “display :1” pada mesin itu.

X Forwarding: GUI di Dalam Kanal SSH #

Sebelum VNC dan RDP populer, X11 sudah punya jawaban: protokol X dirancang sejak awal agar aplikasi dan layar boleh berada di mesin berbeda — aplikasi berjalan di server, jendelanya muncul di layar kita. SSH membungkus mekanisme itu dengan ssh -X; variabel DISPLAY di sesi jauh lalu menunjuk kembali ke laptop kita, dan setiap aplikasi grafis yang dijalankan dari sesi itu menggambar jendelanya lewat kanal terenkripsi tersebut. Perintahnya sederhana: ssh -X budi@server-kantor firefox membuka jendela Firefox milik server di desktop laptop.

Kenyamanannya dibayar dua hal. Pertama, protokol X cerewet: tiap gerakan jendela dan gambar berupa puluhan pesan bolak-balik, sehingga tautan WAN membuatnya terasa lumpuh. Kedua, ssh -X menerapkan pemeriksaan keamanan ekstensi X yang membuat sebagian aplikasi rewel; opsi ssh -Y (trusted forwarding) melepaskan pemeriksaan itu untuk mesin yang kita percaya penuh.

Keamanan: Selalu Bungkus dengan Tunnel SSH #

Satu baris ringkasan untuk seluruh keluarga ini: enkripsi bukan urusan protokol desktop, melainkan urusan SSH. VNC klasik mengautentikasi dengan challenge-password pendek lalu mengirim isi layar apa adanya — siapa pun yang menyadap jaringan ikut menonton. Praktik yang benar sudah lama baku: protokol desktop dibiarkan mendengarkan hanya di 127.0.0.1 mesin jauh (atau di firewalled), dan kita menyusun terowongan SSH dengan port forwarding lokal. Bentuknya satu baris:

ssh -fN -L 5901:localhost:5900 budi@server-kantor

Baca barisnya dari tengah: ssh menyambung ke budi@server-kantor; opsi -L 5901:localhost:5900 menyuruh klien mendengarkan di port 5901 pada laptop kita, dan semua yang masuk ke situ diantar lewat kanal SSH terenkripsi menuju localhost:5900 sebagaimana dilihat dari server-kantor — alias loopback server itu sendiri, tepat di mana server VNC bersembunyi. Opsi -N berarti jangan buka shell (murni terowongan), -f meletakkan ssh ke background setelah autentikasi. Klien VNC lalu cukup diberi localhost:5901. Berikut contoh tampilan dua langkah itu:

$ ssh -fN -L 5901:localhost:5900 budi@server-kantor
$ ss -tln | grep 5901
LISTEN 0      128        127.0.0.1:5901         0.0.0.0:*

Baris ss membuktikan kenop terowongan: sebuah listener baru muncul di 127.0.0.1:5901 pada laptop — hanya bisa dipakai dari laptop itu sendiri, tidak terbuka ke jaringan sekitar.

Mekanisme terowongan itu sendiri bisa dibedah tanpa SSH sama sekali — karena intinya hanyalah satu proses penerus paket TCP. Simulasi berikut menjalankan “layanan panel” yang hanya mendengarkan loopback port 8123 (pengganti server VNC di mesin jauh), lalu sebuah penerus kecil yang berperan persis seperti ssh -L: mendengarkan di port 9000, dan menyerahkan semua isinya ke 8123:

mkdir -p panel
printf '<h1>panel internal server-kantor</h1>\n' > panel/index.html
python3 -m http.server 8123 --bind 127.0.0.1 --directory panel >/dev/null 2>&1 &
layanan=$!
cat > terowongan.py <<'PY'
import socket
import threading

def relay(masuk, keluar):
    while True:
        data = masuk.recv(4096)
        if not data:
            break
        keluar.sendall(data)
    masuk.close()
    keluar.close()

srv = socket.socket()
srv.setsockopt(socket.SOL_SOCKET, socket.SO_REUSEADDR, 1)
srv.bind(("127.0.0.1", 9000))
srv.listen(5)
while True:
    klien, _ = srv.accept()
    tujuan = socket.create_connection(("127.0.0.1", 8123))
    threading.Thread(target=relay, args=(klien, tujuan), daemon=True).start()
    threading.Thread(target=relay, args=(tujuan, klien), daemon=True).start()
PY
python3 terowongan.py &
terowongan=$!
for i in 1 2 3 4 5 6 7 8 9 10; do
  curl -s -o /dev/null 127.0.0.1:9000/ && break
  sleep 0.2
done
curl -s 127.0.0.1:9000/ | grep '<h1>'
kill "$terowongan" "$layanan"

Output yang Dihasilkan:

<h1>panel internal server-kantor</h1>

Mari kita bedah bagian-bagiannya:

1. Baris 1–3 (mkdir, printf, python3 -m http.server ... &): layanan “panel” dinyalakan dan sengaja diikat hanya ke 127.0.0.1 — persis sikap server VNC yang benar: dari luar mesin, layanan ini tidak bisa disentuh.
2. srv.bind(("127.0.0.1", 9000)): sisi terowongan mendengarkan di port 9000 loopback — padanan listener ssh -L pada laptop kita.
3. socket.create_connection(("127.0.0.1", 8123)): untuk setiap klien yang datang, penerus membuka koneksi baru ke layanan tujuan — persis bagian localhost:8123 dari -L 9000:localhost:8123, dijalankan dari sisi server.
4. Dua relay di thread terpisah: satu thread menyalin klien→layanan, satu lagi layanan→klien; dua arah berjalan sendiri-sendiri, seperti kanal SSH yang meneruskan dua arah sekaligus.
5. curl -s 127.0.0.1:9000/: klien hanya mengenal satu alamat — port 9000 di “localhost miliknya” — dan tetap tiba di layanan yang bersembunyi di port 8123.
6. Bagian yang hilang dari simulasi ini: enkripsi. Pada ssh -L, kedua relay ini hidup di dalam kanal SSH tersandi; itulah satu-satunya perbedaan, dan itulah seluruh inti keamanannya.

Pada skenario sesungguhnya, layanan berjalan di mesin jauh dan terowongan menjembatani jaringan; pada simulasi ini keduanya berbagi satu mesin, sehingga yang bisa kita saksikan adalah mekanisme penerusannya, bukan jaraknya.

Dengan peta protokol dan pola keamanan di tangan, bab berikutnya mulai dari yang paling banyak dipakai: memasang dan mengamankan VNC sungguhan, dari konfigurasi servernya hingga klien yang menyambung lewat tunnel.

Referensi lanjut: halaman VNC di wiki Arch untuk ikhtisar server dan klien VNC di Linux, serta ssh(1) untuk opsi -L, -X, dan -Y yang menjadi jantung pola keamanan bab ini.