SSH (Secure Shell) adalah protokol yang memungkinkan kamu mengakses dan mengendalikan komputer lain dari jarak jauh lewat jaringan, dengan seluruh data yang dikirim dienkripsi supaya tidak bisa dibaca pihak lain. Kalau kamu pernah disuruh “SSH ke server” oleh senior atau tim IT, itu artinya kamu diminta login ke komputer lain lewat terminal, bukan lewat tampilan visual biasa.
Kalau kamu baru pertama kali dengar istilah ini karena disuruh atasan atau lagi belajar jadi developer, tenang, ini memang salah satu istilah yang terdengar teknis padahal konsepnya sebenarnya sederhana begitu kamu tahu analoginya.
Kenapa SSH Diciptakan? Ceritanya Bukan dari Nol
SSH nggak muncul begitu saja. Sebelum ada SSH, orang mengakses server jarak jauh pakai protokol bernama Telnet. Masalahnya, Telnet mengirim semua data, termasuk username dan password, dalam bentuk teks polos alias plain text.
Artinya, kalau ada orang yang menyadap jaringan di tengah jalan (misalnya lewat teknik yang disebut packet sniffing), dia bisa langsung membaca password kamu apa adanya, tanpa perlu susah payah memecahkan enkripsi apa pun. Ini jadi celah keamanan besar, apalagi begitu internet mulai dipakai luas untuk kebutuhan bisnis di pertengahan 1990-an.
SSH dibuat sebagai jawaban atas masalah itu. Bedanya mendasar, SSH mengenkripsi seluruh komunikasi dari awal sesi sampai selesai, jadi walaupun ada yang berhasil menyadap datanya, yang mereka dapat cuma kumpulan data acak yang nggak bisa dibaca tanpa kunci dekripsinya.
Bagaimana Cara Kerja SSH? Ini Prosesnya Step by Step
Banyak tutorial cuma bilang “SSH itu enkripsi koneksi”, tapi jarang yang jelasin apa yang sebenarnya terjadi di baliknya. Padahal justru di sinilah letak kekuatan SSH dibanding protokol lama.
1. Membangun Koneksi TCP
Semuanya dimulai dari koneksi TCP biasa ke server tujuan, biasanya lewat port 22 (port default SSH). Di titik ini, klien dan server baru saling “kenalan”, belum ada data sensitif yang dikirim.
2. Negosiasi Versi Protokol dan Algoritma
Klien dan server saling bertukar informasi soal versi SSH yang mereka dukung, lalu menyepakati algoritma enkripsi, algoritma pertukaran kunci, dan metode autentikasi yang akan dipakai. Proses ini penting karena SSH dirancang fleksibel, mendukung banyak algoritma kriptografi, dan kedua pihak perlu satu bahasa yang sama sebelum lanjut.
3. Pertukaran Kunci (Key Exchange)
Di tahap ini terjadi hal yang sering bikin orang bingung: server dan klien menghasilkan kunci sesi (session key) bersama, tanpa pernah mengirim kunci itu secara langsung lewat jaringan. Ini dilakukan lewat algoritma seperti Diffie-Hellman.
Cara sederhananya begini, bayangkan kamu dan temanmu bisa menghasilkan warna cat yang sama persis, padahal kalian nggak pernah menunjukkan warna aslinya satu sama lain, cuma mengirim hasil campuran yang sudah diacak. Orang yang menyadap di tengah jalan cuma lihat hasil campurannya, nggak bisa menebak warna asli yang dipakai. Setelah proses ini selesai, semua komunikasi berikutnya dienkripsi pakai kunci sesi tersebut.
4. Autentikasi Server (Host Verification)
Sebelum kamu login, klien perlu memastikan server yang dihubungi memang server yang benar, bukan server palsu yang menyamar (serangan jenis ini disebut man-in-the-middle). Caranya lewat host key, semacam sidik jari unik milik server.
Ini alasan kenapa pertama kali kamu SSH ke server baru, muncul pesan semacam “authenticity of host can’t be established, are you sure you want to continue connecting?”. Klien SSH kamu belum kenal server itu, jadi dia minta konfirmasi manual. Setelah kamu setuju, host key itu disimpan di file known_hosts supaya nggak ditanya lagi di sesi berikutnya, kecuali host key-nya berubah, yang justru harus jadi tanda bahaya karena bisa berarti ada yang mencoba menyamar sebagai server tujuanmu.
5. Autentikasi Pengguna
Baru di tahap ini kamu benar-benar login, dan ada dua metode umum yang dipakai.
| Metode | Cara Kerja | Tingkat Keamanan |
|---|---|---|
| Password | Kamu masukkan username dan password, dikirim lewat jalur yang sudah terenkripsi | Cukup aman, tapi rentan brute force kalau password lemah |
| Public Key | Server menyimpan public key kamu, kamu menyimpan private key yang cocok pasangannya | Lebih aman, sulit ditembak tebak, dan bisa dipakai tanpa password sama sekali |
Banyak tim engineering akhirnya mewajibkan autentikasi berbasis key dan mematikan login pakai password sama sekali. Alasannya bukan cuma soal keamanan, tapi juga karena password gampang dipakai berulang di banyak server, sementara key pair biasanya unik per mesin atau per orang.
6. Sesi Terenkripsi Dimulai
Setelah autentikasi berhasil, barulah kamu masuk ke shell server dan bisa menjalankan perintah seperti biasa. Semua yang kamu ketik, semua output yang kamu terima, dikirim lewat jalur yang sudah dienkripsi tadi.
SSH Key: Kenapa Banyak yang Disaranin Pakai Ini, Bukan Password
Kalau kamu baru mulai kerja dan senior bilang “pakai SSH key aja, jangan password”, ada alasan praktis di baliknya yang jarang dijelaskan tuntas.
Private key itu file yang tetap ada di komputermu dan tidak pernah dikirim ke mana pun, bahkan saat proses autentikasi berlangsung. Yang dikirim ke server cuma bukti matematis bahwa kamu memegang private key yang cocok dengan public key yang sudah didaftarkan di server itu. Server menantang kamu dengan semacam teka-teki kriptografi, dan cuma pemegang private key yang benar yang bisa menjawabnya dengan tepat.
Ini beda jauh dari cara kerja password, di mana kamu harus benar-benar mengirim kredensialnya (meski lewat jalur terenkripsi) supaya server bisa mencocokkannya. Karena private key nggak pernah berpindah tempat, risiko dia bocor lewat penyadapan jaringan jadi jauh lebih kecil dibanding password.
Masalah yang sering muncul justru bukan di konsepnya, tapi di kelalaian menyimpan private key. Banyak kasus kebocoran server terjadi bukan karena SSH-nya lemah, tapi karena private key ketinggalan di laptop yang dicuri, ter-commit tanpa sengaja ke repository publik, atau disimpan tanpa passphrase tambahan sehingga siapa pun yang memegang filenya langsung bisa pakai.
Kapan SSH Bisa “Gagal” atau Bikin Masalah
Ada beberapa situasi yang bikin orang baru sering bingung dan mengira SSH-nya rusak, padahal sebenarnya itu bekerja sesuai rancangannya.
Pesan “REMOTE HOST IDENTIFICATION HAS CHANGED” yang muncul tiba-tiba sering bikin panik, padahal itu justru fitur keamanan yang sedang bekerja. Pesan itu muncul kalau host key server berubah dari yang tersimpan sebelumnya di known_hosts.
Ini bisa terjadi karena hal wajar, misalnya server di-install ulang, tapi bisa juga jadi sinyal ada serangan man-in-the-middle. Karena itu, solusinya bukan asal hapus baris di known_hosts tanpa mikir, tapi cek dulu apakah memang ada perubahan sah di sisi server.
Koneksi yang “menggantung” lama sebelum akhirnya time out biasanya bukan soal SSH yang lambat, tapi soal firewall yang mendrop paket secara diam-diam alih-alih menolaknya secara eksplisit. Bedanya kelihatan, kalau port ditutup secara aktif, biasanya errornya cepat (“connection refused”). Kalau firewall cuma diam-diam membuang paket, klien akan menunggu sampai waktu tunggu habis, dan ini yang sering bikin orang salah duga masalahnya ada di konfigurasi SSH.
SSH vs Alternatif Lain, Kapan Masih Relevan Dipakai
Di dunia yang makin banyak pakai container dan orkestrasi otomatis, ada yang berpikir SSH mulai kurang relevan. Kenyataannya nggak sesederhana itu.
Untuk kebutuhan debugging langsung di server, mengecek log real-time, atau melakukan perubahan darurat yang belum sempat masuk ke pipeline otomatis, SSH masih jadi andalan karena aksesnya langsung dan fleksibel. Tapi untuk deployment rutin dan skala besar, banyak tim beralih ke tools orkestrasi yang meniadakan kebutuhan login manual sama sekali, justru demi mengurangi risiko human error dan menjaga konsistensi antar server.
Jadi bukan soal SSH ketinggalan zaman, tapi soal SSH lebih cocok dipakai untuk akses langsung dan situasi yang butuh intervensi manual, sementara proses yang berulang dan bisa diotomasi biasanya memang lebih baik nggak lagi bergantung pada login manual satu per satu.
FAQ
Kenapa SSH pakai port 22 secara default, dan apakah wajib dipakai?
Port 22 dipilih sejak awal sebagai standar, tapi bukan aturan wajib secara teknis. Banyak admin sengaja mengganti ke port lain untuk mengurangi jumlah percobaan login otomatis dari bot yang menyasar port default, meski ini cuma lapisan tambahan, bukan pengganti autentikasi yang kuat.
Apakah SSH sama dengan VPN?
Beda. SSH dirancang untuk mengakses dan menjalankan perintah di komputer lain lewat shell, sementara VPN dirancang untuk menghubungkan seluruh perangkatmu ke jaringan tertentu. SSH memang bisa dipakai untuk membuat tunnel terbatas (SSH tunneling), tapi cakupannya jauh lebih sempit dibanding VPN penuh.
Apa yang terjadi kalau private key hilang atau dicuri?
Siapa pun yang memegang private key itu bisa login ke server tempat public key pasangannya terdaftar, tanpa perlu tahu password apa pun. Karena itu, langkah pertama begitu tahu private key bocor adalah mencabut akses public key terkait dari server sesegera mungkin, bukan sekadar mengganti password.
