Belajar Tmux - Security & Hardening Best Practice

#Pendahuluan

Di episode 19 sebelumnya kita membahas multi-server & shared session — broadcast perintah ke banyak server sekaligus, kolaborasi real-time dalam session bersama, dan tata kelola permission antar client. Semakin besar jangkauan tmux kalian, semakin besar pula permukaan yang harus diamankan: sebuah session yang bisa di-attach oleh siapa pun adalah terminal yang bisa diendus oleh siapa pun — setiap keystroke, setiap output, setiap clipboard terbuka lebar.

Keamanan sering dianggap "bukan urusan tmux", padahal justru sebaliknya. Tmux berada di antara terminal dan aplikasi kalian — posisi paling strategis dalam sistem. Ia melihat password yang kalian ketik di prompt sudo, token yang dicetak script, dan log yang memuat data sensitif. Kalau lapisan ini bocor, semua yang berjalan di atasnya ikut terpapar. Episode 20 ini adalah security baseline: kita mengunci session, mencegah attach tidak sah, mengamankan socket, menyembunyikan secrets dari konfigurasi, dan menerapkan kebijakan yang masuk akal untuk server production. Semua contoh merujuk tmux 3.7b sebagai versi stabil terbaru.

#Mengapa Keamanan Session Tmux Itu Penting

Model threat tmux sesederhana ini: siapa pun yang bisa terhubung ke socket bisa meng-attach ke session, dan siapa pun yang bisa attach bisa membaca serta mengetik di dalamnya. Tidak ada autentikasi tambahan — jika socket-nya bisa dijangkau, kendali atas terminal itu pindah tangan.

Ada empat permukaan serangan utama:

1. Socket server — file Unix socket yang menjadi pintu masuk. Permission longgar berarti user lain di mesin yang sama bisa menempel ke session kalian.
2. Client yang sudah terpasang — attach read-write berarti perintah bisa diketik atas nama kalian, termasuk sudo dan git push.
3. Konfigurasi & environment — secrets yang bocor ke ~/.tmux.conf yang di-commit atau ke environment yang di-snapshot tmux.
4. Interpretasi input — escape sequence yang disalahartikan bisa menjadi celah keyboard injection.

Analoginya seperti rumah: mengunci pintu tapi membiarkan jendela terbuka tidak ada artinya. Di ruang kerja digital kalian, session tmux adalah ruang kerja; kunci pintunya adalah socket permission; dan alarmnya adalah lock command. Pada episode ini kita pasang semuanya.

#Mengunci Session dengan Lock Command

#lock-session, lock-client, dan lock-server

Tmux punya tiga perintah lock dengan jangkauan berbeda. Ketiganya menjalankan lock-command dan membuat layar terkunci sampai password user dimasukkan kembali:

tmux lock-session -t myname

tmux lock-client -t %0
tmux lock-server

Ketika terkunci, layar menampilkan password prompt dan tidak ada input yang diteruskan ke pane sampai user yang benar memasukkan password. Ini melindungi session dari orang yang lewat di depan terminal — persis seperti lock screen di laptop.

#Lock Otomatis dengan lock-after-time

Mengunci manual hanya berguna kalau kalian ingat. Untuk mesin bersama atau terminal yang sering ditinggal, atur auto-lock: setelah sejumlah detik tanpa aktivitas, tmux mengunci client sendiri.

set -g lock-after-time 600
set -g lock-command 'clear'

lock-after-time adalah server option: nilai 600 berarti 10 menit tanpa aktivitas, lalu tmux mengunci. lock-command 'clear' mengganti perintah default (biasanya lock(1) atau vlock) dengan clear — layar dibersihkan sebelum password diminta, sehingga informasi yang tertinggal di layar tidak terlihat oleh orang lain.

#Mencegah Attach yang Tidak Sah

#Attach Read-Only: Melihat Tanpa Menyentuh

Ketika seseorang harus ikut melihat progress tanpa bisa mengetik, jangan beri mereka kendali penuh. Attach read-only memberi client izin melihat semua output tetapi tidak meneruskan satu tombol pun ke pane:

tmux attach -r -t myname
tmux attach -f read-only -t myname

attach -r adalah singkatan dari client flag read-only (plus ignore-size). Client read-only masih bisa menjalankan detach-client dan switch-client — misalnya berpindah session — tapi tidak bisa mengetik di pane. Ini sangat berguna untuk screen share: rekan melihat output yang sama persis, tanpa risiko menekan tombol di session produksi.

#Mengeluarkan Client yang Tidak Dikehendaki

Session bersama (episode 19) bisa "ditumpangi" client yang tidak kalian undang. Untuk membersihkan, detach client lain dari session:

tmux detach-client -s myname
tmux detach-client -a
tmux list-clients -t myname

detach-client -s myname mengeluarkan semua client lain dari session myname — client yang menjalankan perintah ini aman. -a mengeluarkan semua client kecuali yang aktif. Periksa dulu siapa saja yang terhubung dengan tmux list-clients sebelum bertindak.

#Access Control di Level Server

Untuk lingkungan multi-user, tmux 3.3+ punya access control list (ACL) via server-access. Kalian bisa memberi akses, mencabut akses, atau memaksa user tertentu attach read-only:

tmux server-access -a devnull
tmux server-access -r devnull
tmux server-access -d devnull
tmux server-access -l

#Keamanan Socket dan Environment

#Memilih Socket yang Tepat

Socket server tmux secara default berada di $TMPDIR (atau /tmp jika tidak diset) dalam direktori tmux-<UID> — misalnya /tmp/tmux-1000/default. Dua parameter menentukan keamanannya: lokasi dan umask.

• tmux -L nama memakai socket $TMPDIR/tmux-<UID>/nama — berguna untuk memisahkan server tmux per konteks, misalnya -L work vs -L personal.
• tmux -S /path/penuh menempatkan socket di path absolut yang kalian tentukan — fleksibel tapi harus dijaga permission-nya.
• umask saat server pertama kali dimulai menentukan permission direktori socket. Jalankan tmux dengan umask 077 agar tidak ada file socket yang bisa diakses user lain.

Socket kustom per konteksPeriksa permission direktori socket

umask 077
tmux -L work new-session -s prod
tmux -L work attach -t prod

ls -ld "$TMPDIR/tmux-$(id -u)/"
ls -la "$TMPDIR/tmux-$(id -u)/"

#Jangan Menaruh Secrets di Konfigurasi

Celah paling umum di dunia nyata bukan socket yang bocor, melainkan konfigurasi yang di-commit ke git. Contoh klasik:

setenv -g DB_PASSWORD 'supersecret'
set -g status-left "DB: #{DB_PASSWORD}"

Baris setenv di atas menaruh password di konfigurasi yang kemungkinan besar berakhir di repositori dotfiles publik. Lebih parah: update-environment di tmux ikut menyalin variabel dari shell, sehingga secrets yang tadinya lokal bisa "menempel" di environment server tmux. Aturannya sederhana:

• Never commit secrets. Konfigurasi tmux hanya menyimpan struktur, bukan nilai.
• Kirim variabel lewat environment saat menjalankan tmux: DB_PASSWORD='secret' tmux new -s prod — nilainya hidup di proses, bukan di file.
• Gunakan setenv -h untuk menandai variabel sebagai hidden sehingga tidak diwariskan ke pane: tmux setenv -h TOKEN.

DB_PASSWORD='supersecret' tmux new-session -s prod
tmux setenv -h TOKEN
tmux show-environment

#Security di Lingkungan Remote dan Production

#escape-time dan Risiko Keyboard Injection

Tmux menafsirkan urutan yang diawali ESC sebagai escape sequence (tombol panah, Alt+key, dan lain-lain). Semakin lama tmux menahan rangkaian byte untuk memutuskan interpretasinya — nilai escape-time — semakin lebar jendela di mana byte yang datang (misalnya output program yang diawali ESC) bisa disalahartikan sebagai penekanan tombol. Di sinilah dasar risiko keyboard injection: output dari satu pane bisa memicu keybinding tmux seolah-olah user mengetiknya.

set -sg escape-time 10

Menurunkan escape-time ke 10 milidetik menyempitkan jendela itu sekaligus membuat input terasa lebih responsif — sisi performa ini akan kita bahas di episode 21. Di tmux 3.5+ nilai default memang sudah 10, tetapi menuliskannya secara eksplisit melindungi kalian jika menyalin konfigurasi dari mesin dengan tmux lama yang masih memakai 500.

#Best Practice di Server Produksi

Prinsip yang menaungi semuanya sama dengan hardening di lapisan lain: berikan akses seminimal mungkin, dan hapus akses yang tidak lagi diperlukan. Tmux yang sehat adalah tmux yang jarang terlihat — ia bekerja diam-diam di belakang, dan tidak menjadi pintu masuk yang malas.

#Kesalahan Umum (Common Pitfalls)

1. Lupa mengunci mesin bersama. Di terminal kantor bersama, session tanpa lock-after-time berarti siapa pun bisa duduk dan melanjutkan pekerjaan kalian — termasuk mengeksekusi perintah berbahaya. Pasang auto-lock.
2. Menaruh setenv berisi password di ~/.tmux.conf. Konfigurasi ini sering ikut di-commit ke repositori dotfiles. Secret harus hidup di environment proses, bukan di file teks.
3. Memberi attach read-write kepada pengamat. "Cuma lihat sebentar" berakhir dengan keystroke tak sengaja. Gunakan attach -r dan perketat dengan server-access -r bila perlu.
4. Memaksa permission socket 777. Merusak salah satu jaminan keamanan dasar tmux. Untuk berbagi session, pakai mekanisme shared session resmi dari episode 19.
5. Mengabaikan escape-time yang tinggi. Konfigurasi lama yang memakai escape-time 500 membuka jendela interpretasi yang lebih lebar. Turunkan ke 10.
6. Menjalankan server tmux sebagai root. Satu kesalahan ketik di session root berdampak ke seluruh sistem. Jalankan sebagai user dengan privilege seminimal mungkin.

#Penutup

Episode ini memberi kalian security baseline untuk tmux: mengunci session dengan lock-session, lock-client, lock-server, dan lock-after-time; mencegah attach tidak sah lewat attach -r dan detach-client; mengamankan socket dengan -L, -S, umask, dan ACL server-access; serta menghindari secrets bocor dari konfigurasi yang di-commit. Semuanya menutup empat permukaan serangan yang kita petakan di awal: socket, client, konfigurasi, dan interpretasi input.

Poin yang harus kalian bawa pulang:

• Kunci dan auto-lock adalah kebiasaan, bukan fitur opsional.
• Read-only attach membagi informasi tanpa membagi kendali.
• Secret hidup di environment proses, bukan di file konfigurasi.
• Tmux yang paling aman adalah yang paling tidak terlihat.

Di episode 21 selanjutnya kita akan membahas nested tmux & advanced input handling — menangani tmux di dalam tmux saat SSH ke server, serta mengoptimalkan mouse, extended keys, focus events, clipboard OSC 52, dan true color end-to-end. Setelah mengamankan fondasi, kita akan menghaluskan cara kalian berinteraksi dengannya. Sampai jumpa di episode 21!