Belajar Linux - Remote Access Menggunakan SSH & Secure File Transfer

#Pendahuluan

Setelah di episode 17 sebelumnya kita membahas Networking Fundamentals & Diagnostic Tools — memahami antarmuka, routing, DNS, hingga memeriksa port dengan ss — kalian sekarang bisa membaca kondisi jaringan sebuah server. Tapi ada pertanyaan yang lebih mendasar: bagaimana kalian masuk ke server itu dari jarak jauh? Server produksi tidak pernah dipasangi monitor dan keyboard — ia hidup di datacenter atau cloud, dan satu-satunya pintu masuk yang benar adalah SSH.

SSH (Secure Shell) adalah protokol yang mengamankan seluruh sesi terminal kalian dengan enkripsi. Bayangkan telnet — pendahulunya yang jujur tapi bodoh: semua yang kalian ketik, termasuk password, dikirim dalam teks polos dan bisa disadap siapa pun di jalur. SSH memperbaiki itu total: koneksi dienkripsi end-to-end, identitas server diverifikasi, dan identitas kalian dibuktikan dengan password atau kunci kriptografi.

Namun, SSH yang diinstal secara default justru adalah risiko terbesar: password lemah, akun root bisa login, dan autentikasi password terbuka untuk serangan brute-force 24 jam sehari. Di episode 18 ini, kita akan membahas SSH dari nol: koneksi dasar, autentikasi kunci, hardening konfigurasi server, transfer file, dan tunnel — termasuk cara menghindari jebakan yang paling memalukan: mengunci diri sendiri keluar dari server kalian.

#Pembahasan Utama

#Koneksi Dasar: Mengetuk Pintu dengan Benar

Koneksi SSH paling sederhana berbentuk ssh user@host. Dengan sintaks lengkap, port yang tidak standar, dan verbosity untuk debugging:

ssh user@192.168.1.10

ssh -p 2222 user@192.168.1.10

ssh -vvv user@192.168.1.10

ssh user@192.168.1.10 "uptime && uname -r"

Baris terakhir adalah pola yang sangat berguna dalam otomasi: kalian tidak perlu login interaktif untuk menjalankan satu perintah di remote — cukup lampirkan perintah dalam tanda kutip. Ini adalah fondasi dari skrip administrasi multi-server.

Saat pertama kali terhubung ke server baru, kalian akan melihat peringatan host key authenticity:

The authenticity of host '192.168.1.10 (192.168.1.10)' can't be established.
ED25519 key fingerprint is SHA256:9x...k8.
Are you sure you want to continue connecting (yes/no/[fingerprint])?

Ini adalah mekanisme anti-man-in-the-middle. Verifikasi fingerprint-nya dari sumber tepercaya (misal console server), lalu ketik yes. Setelah itu key tersimpan di ~/.ssh/known_hosts dan tidak akan ditanyakan lagi.

#Autentikasi Kunci: Kunci Fisik Lebih Aman dari Kata Sandi

Password bisa ditebak, dibobol brute-force, atau di-screenshot oleh shoulder-surfer. Kunci SSH adalah pasangan file kriptografi: kunci privat yang hanya kalian miliki dan kunci publik yang dipasang di server. Kalian hanya membuktikan kepemilikan kunci privat tanpa pernah mengirimkannya.

ssh-keygen -t ed25519 -C "nama@email.com"

Generating public/private ed25519 key pair.
Enter file in which to save the key (/home/user/.ssh/id_ed25519):
Enter passphrase (empty for no passphrase):
Your identification has been saved in /home/user/.ssh/id_ed25519
Your public key has been saved in /home/user/.ssh/id_ed25519.pub

Alasan memakai ED25519 dibanding RSA: kurva kriptografinya lebih kuat dengan kunci yang jauh lebih pendek, dan generasinya lebih cepat. Jika sistem lawas memaksa RSA, gunakan ssh-keygen -t rsa -b 4096.

Setelah kunci dibuat, salin kunci publik ke server dengan ssh-copy-id:

ssh-copy-id user@192.168.1.10

Perintah ini otomatis menambahkan kunci publik kalian ke ~/.ssh/authorized_keys di server. Sekarang login tanpa password:

ssh user@192.168.1.10

#Hardening sshd_config: Menutup Pintu yang Tidak Perlu

Konfigurasi server SSH ada di /etc/ssh/sshd_config. Sebelum server kalian terekspos ke internet, ada tiga perubahan wajib. Mari lihat sebelum dan sesudahnya memakai marker diff:

#Port 22
#PermitRootLogin yes
#PasswordAuthentication yes

#Port 22
Port 2222
#PermitRootLogin yes
PermitRootLogin no
#PasswordAuthentication yes
PasswordAuthentication no
PubkeyAuthentication yes

Perubahan di atas menutup tiga lubang terbesar: port default yang selalu diserang, login root langsung, dan autentikasi password yang rawan brute-force. Setelah mengedit, selalu validasi dulu konfigurasinya sebelum me-restart layanan:

sudo sshd -t

sudo systemctl restart sshd

Ingat juga: setiap perubahan port SSH harus diikuti pembaruan firewall (episode 19) — membuka port 22 sementara layanan pindah ke 2222 adalah kebocoran yang tidak perlu.

#Transfer File: scp dan rsync

SSH tidak hanya untuk terminal; ia juga menjadi saluran aman transfer file.

scp adalah cara paling sederhana untuk sekali transfer:

scp ./backup.sql user@192.168.1.10:/home/user/

scp user@192.168.1.10:/home/user/backup.sql ./

scp -r ./dist/ user@192.168.1.10:/var/www/

rsync adalah level berikutnya — ia mentransfer hanya perbedaan antar file, sangat hemat bandwidth dan bisa melanjutkan transfer yang terputus. Ini alat standar untuk deployment dan backup.

rsync -avz ./dist/ user@192.168.1.10:/var/www/

rsync -avz --progress --delete ./dist/ user@192.168.1.10:/var/www/

rsync -avz --dry-run --delete ./dist/ user@192.168.1.10:/var/www/

Untuk port SSH non-standar (yang kalian atur di bagian hardening), tambahkan -e "ssh -p 2222" agar rsync tahu lewat pintu mana ia harus pergi:

rsync -avz -e "ssh -p 2222" ./dist/ user@192.168.1.10:/var/www/

Pola backup inkremental dengan --link-dest. Salah satu fitur rsync yang paling dihargai admin adalah hardlink backup: kalian mendapatkan serangkaian snapshot penuh yang tampak seperti backup harian lengkap, padahal file yang tidak berubah hanyalah hardlink ke snapshot sebelumnya — sangat hemat disk tanpa mengorbankan kemudahan restore.

rsync -avz --link-dest=../backup-2026-08-01 /var/www/ user@backup.example.com:/backup/backup-2026-08-02/

Snapshot tanggal 2 hanya menyimpan file yang berubah; sisanya menjadi hardlink ke snapshot tanggal 1. Kalian bisa restore kapan pun tanpa menebak-menebak isi backup.

#SSH Tunneling: Menyelundupkan Trafik Melewati Kanal Aman

Koneksi SSH sudah dienkripsi. Maka masuk akal bila kita menyalurkan trafik lain lewat SSH — teknik yang disebut tunneling atau port forwarding. Kasus paling nyata: database di server hanya mendengarkan di localhost (pola aman dari episode 17), sehingga kalian perlu akses dari laptop tanpa membuka port ke publik.

Local port forwarding (-L): port di mesin lokal diteruskan ke host tertentu dari perspektif server.

ssh -L 5433:127.0.0.1:5432 user@192.168.1.10

Sekarang dari laptop, koneksi ke 127.0.0.1:5433 secara transparan menuju PostgreSQL di server — tanpa membuka port database ke internet. Konsep ini sama dengan SSH tunnel yang dipakai banyak developer untuk mengakses database di VPS.

Remote port forwarding (-R): kebalikannya — port di server diteruskan ke mesin lokal. Berguna ketika kalian butuh mengakses laptop dari luar (misal webhook development).

ssh -R 8080:127.0.0.1:3000 user@192.168.1.10

Jump host (-J): ketika server tujuan hanya bisa dijangkau lewat server bastion (jump box) — pola standar di perusahaan.

ssh -J user@bastion.example.com user@10.0.0.5

ssh -J user@bastion.example.com -L 5433:127.0.0.1:5432 user@10.0.0.5

#Sisi Klien: Konfigurasi ~/.ssh/config

Jika kalian mengelola banyak server, mengetik -p 2222 user@... berulang kali itu tidak efisien. ~/.ssh/config mendefinisikan alias untuk setiap host:

Host prod-web
    HostName 192.168.1.10
    User deploy
    Port 2222
    IdentityFile ~/.ssh/id_ed25519_prod
 
Host db-prod
    HostName 10.0.0.5
    User admin
    ProxyJump prod-web

Setelah file ini dibuat, koneksi jadi sesingkat ini:

ssh prod-web

#Agent Forwarding: Kenyamanan yang Bisa Menjadi Malapetaka

Agent forwarding (ssh -A) memungkinkan server mempergunakan kunci privat lokal kalian untuk SSH ke server berikutnya — sangat nyaman untuk melompat antar server. Tapi ada harga yang mahal: siapa pun dengan akses root di server perantara dapat menyalahgunakan kunci kalian. Aturan aman: gunakan -A hanya pada server yang benar-benar kalian percayai, dan jadikan default ForwardAgent no di sshd_config.

#Kesalahan Umum (Common Pitfalls)

1. Mengunci diri dari sshd_config. Sudah ditekankan: validasi dengan sshd -t, pastikan kunci sudah terpasang sebelum mematikan password auth, dan punya jalur akses alternatif.

2. Permission kunci terlalu terbuka. Kunci privat harus 600 (chmod 600 ~/.ssh/id_ed25519), direktori ~/.ssh harus 700. SSH sangat ketat soal ini — pesan error Permissions too open tidak bisa dibohongi dengan menurunkan security.

3. ssh-copy-id hanya menyalin sekali. Setelah PasswordAuthentication no, kalian tidak bisa memakai ssh-copy-id lagi (perlu password). Rencanakan: pasang kunci sebelum mematikan password auth.

4. Lupa memperbarui known_hosts setelah server di-reinstall. Server baru membawa kunci host baru; SSH menolak koneksi dengan REMOTE HOST IDENTIFICATION HAS CHANGED. Ini justru fitur keamanan — verifikasi kunci baru dari sumber tepercaya, lalu bersihkan entri lama dengan ssh-keygen -R <host>.

5. scp -r vs rsync untuk sinkronisasi berulang. scp menyalin semuanya setiap kali; untuk deployment berulang gunakan rsync yang hemat bandwidth. Untuk transfer sekali pakai, scp sudah cukup.

6. Tunnel yang terputus diam-diam. Koneksi tunnel yang putus tidak langsung terlihat. Gunakan opsi -o ServerAliveInterval=60 -o ServerAliveCountMax=3 untuk mendeteksi dan memutus koneksi mati — atau gunakan autossh untuk auto-reconnect.

#Penutup

Pada episode 18 ini, kalian telah menguasai SSH sebagai gerbang utama administrasi server: koneksi dasar dan eksekusi remote, autentikasi kunci dengan ssh-keygen dan ssh-copy-id, hardening sshd_config (ganti port, matikan root login, matikan password auth), transfer file dengan scp dan rsync, tunnel SSH (-L, -R, -J) untuk menyalurkan trafik aman, serta peringatan serius soal agent forwarding.

Poin kunci yang perlu kalian bawa pulang:

• SSH adalah kanal terenkripsi — pintu utama dan satu-satunya yang benar untuk administrasi remote.
• Kunci ED25519 lebih kuat dan praktis dibanding RSA panjang; kunci privat wajib 600.
• Sebelum restart sshd: validasi sshd -t, dan pastikan ada jalur masuk alternatif.
• rsync lebih efisien untuk sinkronisasi berulang; selalu --dry-run sebelum --delete.
• -J (jump host) lebih aman dari -A (agent forwarding) untuk melompat antar server.
• Port SSH yang diubah harus diikuti pembaruan firewall — dan itulah topik berikutnya.

Di episode 19 selanjutnya kita akan membangun pertahanan lapis luar server lewat topik Linux Firewall Management (UFW, Firewalld & Iptables). Kalian akan belajar memfilter lalu lintas berdasarkan port dan sumber, memahami perbedaan tiga tool firewall utama di ekosistem Linux, dan — yang sama pentingnya — menghindari jebakan yang membuat kalian terblokir dari server sendiri. Sampai jumpa!