Keamanan SSH: Cara Mengunci Akses Jarak Jauh ke Server-mu

Begitu sebuah server online, dia langsung mulai diketuk-ketuk. Dalam hitungan menit setelah mesin baru mendapat IP publik, bot otomatis dari berbagai penjuru dunia akan mencoba masuk lewat SSH — menebak username, menggempur password, mengintai apa pun yang masih kebuka. Ini bukan paranoia; ini cuma suara latar belakang internet yang memang begitu adanya. Kalau server-mu jalan di atas Linux, SSH adalah satu pintu paling penting untuk diamankan, karena dialah pintu yang memberi seseorang akses shell.

Kabar baiknya, menguncinya rapat-rapat itu tidak ribet. Cukup beberapa pengaturan, dilakukan sekali dan dengan benar, dan SSH-mu berubah dari sasaran empuk jadi sesuatu yang bikin serangan otomatis sekadar memantul. Mari kita telusuri apa sebenarnya makna keamanan SSH dan cara menyiapkannya dengan benar, mulai dari dasarnya.

Kenapa SSH adalah pintu yang paling penting

SSH itu singkatan dari Secure Shell. Inilah protokol yang kamu pakai untuk menyambung ke server jarak jauh dan menjalankan perintah di sana, seolah-olah kamu sedang duduk persis di depannya. Kalau kamu sudah ketemu SSH di tahap dasar, kamu sudah kenal bentuk kesehariannya: dasar SSH membahas cara kerja koneksi dan perintah sehari-harinya. Artikel ini soal lapisan di atasnya — bagaimana memastikan hanya orang yang berhak yang bisa lewat.

Begini alasan kenapa SSH menarik begitu banyak perhatian penyerang. Kebanyakan layanan lain di server cuma melakukan satu hal sempit: web server membagikan halaman, database menjawab query. Tapi SSH membagikan shell — kendali penuh atas mesin lewat command line. Kalau ada yang berhasil menembus SSH, dia tidak cuma dapat satu halaman atau satu baris data; dia dapat seluruh server. Itulah kenapa SSH jadi hal pertama yang layak dikuatkan, dan kenapa membereskannya dengan benar lebih penting daripada hampir semua hal lain yang akan kamu lakukan.

Enkripsi di dalam SSH sendiri sudah kuat — secara realistis tidak ada yang sanggup membobol matematikanya. Titik lemahnya hampir selalu di cara kamu login: password yang gampang ditebak, akun yang seharusnya tidak bisa dijangkau, pengaturan default yang dibiarkan begitu saja. Itulah pintu-pintu yang benar-benar dilewati penyerang, dan persis itulah yang akan kita tutup.

Cara kerja autentikasi SSH

Untuk mengamankan SSH, pertama-tama kamu perlu paham dua cara dia membolehkan kamu membuktikan siapa dirimu. Saat kamu menyambung, server harus yakin bahwa kamu memang berhak masuk. Ada dua metode utama untuk itu.

Autentikasi password adalah yang paling jelas: kamu mengetik username dan password, kalau cocok, kamu masuk. Sederhana, tapi punya cacat fatal di server publik — password itu sesuatu yang bisa ditebak. Bot mencoba jutaan kombinasi umum, dan kalau password-mu lemah atau dipakai ulang di mana-mana, cepat atau lambat salah satunya kena.

Autentikasi berbasis key bekerja dengan cara berbeda dan jauh lebih kuat. Alih-alih satu rahasia bersama yang kamu ketik, kamu punya pasangan key: dua berkas yang saling berkaitan. Yang satu adalah private key, yang tinggal di komputermu sendiri dan tidak pernah keluar dari situ. Yang lain adalah public key, yang kamu taruh di server. Keduanya terhubung secara matematis: apa pun yang dibuktikan dengan private key bisa diverifikasi dengan yang public, tapi kamu tidak bisa membalik dari public key untuk menemukan private key-nya.

   LAPTOP KAMU                          SERVER
  ┌───────────────┐                ┌───────────────┐
  │  private key  │                │  public key   │
  │ (tinggal di   │                │ (ditaruh di   │
  │  sini, rahasia)│                │  sini, boleh  │
  │               │                │  dibagi)      │
  └───────┬───────┘                └───────┬───────┘
          │                                │
          │ "buktikan kamu pegang private  │
          │  key pasangan public ini"      │
          │ ─────────────────────────────► │
          │                                │  memeriksa buktinya
          │  ◄────────────── akses diberikan│

Saat kamu menyambung, server meminta klienmu membuktikan bahwa dia memegang private key yang cocok dengan public key yang tersimpan. Klienmu melakukannya tanpa pernah mengirim private key melintasi jaringan. Tidak ada rahasia yang lewat di kabel, dan tidak ada yang bisa ditebak — kemungkinan nilai sebuah private key begitu banyak sampai mencoba membobolnya secara paksa itu sia-sia belaka. Inilah fondasi keamanan SSH yang baik, dan hampir semua hal lain dibangun di atasnya.

Langkah satu: pakai key SSH, bukan password

Perbaikan pertama dan terbesar yang bisa kamu lakukan adalah berhenti login dengan password dan beralih ke pasangan key. Perubahan tunggal ini menghapus seluruh kategori serangan tebak-password, karena memang tidak ada password yang bisa ditebak.

Membuat pasangan key cukup satu perintah di mesinmu sendiri:

# Membuat pasangan key modern yang kuat
ssh-keygen -t ed25519 -C "john.doe@example.com"

Ini menghasilkan dua berkas, biasanya di folder tersembunyi .ssh di dalam home directory-mu: private key (misalnya id_ed25519) dan public key (id_ed25519.pub). Bagian -t ed25519 memilih jenis key yang modern, cepat, dan sangat aman — inilah pilihan default yang direkomendasikan saat ini. Komentar setelah -C cuma label biar kamu ingat key mana ini.

Untuk memakainya, kamu menyalin bagian public ke server. Cara paling gampang adalah perintah bantuan:

# Menyalin public key ke daftar yang diizinkan di server
ssh-copy-id john@ip-server-kamu

Perintah ini menambahkan public key-mu ke sebuah berkas di server bernama ~/.ssh/authorized_keys. Setelah itu, saat kamu menjalankan ssh john@ip-server-kamu, klienmu membuktikan dia memegang private key yang cocok dan kamu langsung diterima — tanpa diminta password sama sekali.

Langkah dua: matikan login password sepenuhnya

Menyiapkan key itu bagus, tapi kalau login password masih diizinkan, penyerang tetap bisa menggempur password ke server-mu sepanjang hari. Para bot tidak tahu dan tidak peduli bahwa kamu pribadi pakai key — pintunya masih ada untuk mereka goyang-goyang. Jadi begitu key-mu berhasil, langkah berikutnya adalah mematikan autentikasi password sepenuhnya.

Perilaku SSH diatur oleh sebuah berkas konfigurasi di server, hampir selalu di /etc/ssh/sshd_config. Kamu menyuntingnya dengan editor (pakai sudo, karena ini berkas sistem) lalu mencari pengaturan yang relevan:

# Di dalam /etc/ssh/sshd_config
PasswordAuthentication no

Dengan satu baris itu, server berhenti menerima password untuk SSH sama sekali. Mulai sekarang, satu-satunya jalan masuk adalah dengan key yang valid. Aliran bot tebak-password yang tak ada habisnya itu kini membentur tembok — tidak ada password untuk ditebak, jadi mereka gagal seketika, setiap kali.

Setelah mengubah konfigurasi, kamu menyuruh SSH memuat ulang supaya perubahannya berlaku:

# Memuat ulang service SSH agar perubahan konfigurasi diterapkan
sudo systemctl restart ssh

Langkah tiga: cegah root login langsung

Akun root adalah administrator maha kuasa di server Linux — dia bisa melakukan apa saja secara harfiah, tanpa pengaman. Itu menjadikannya sasaran paling berharga yang mungkin ada, dan penyerang tahu username root ada di hampir setiap mesin Linux, jadi itulah hal pertama yang mereka coba. Membiarkan root login lewat SSH berarti bot cukup menebak satu akun dengan benar, dan itu pun akun yang paling berbahaya.

Solusinya adalah melarang root login langsung, dan sebagai gantinya login sebagai user biasa, lalu naik ke hak akses root dengan sudo hanya saat kamu butuh. Di berkas konfigurasi yang sama:

# Di dalam /etc/ssh/sshd_config
PermitRootLogin no

Sekarang penyerang sama sekali tidak bisa menyasar root secara langsung. Dia harus lebih dulu menembus akun biasa baru kemudian menembus sudo di atasnya — dua gembok, bukan satu. Ini berpasangan secara alami dengan ide memberi setiap orang akun biasanya sendiri, yang nyambung dengan cara user dan grup dikelola di Linux: orang nyata dapat akun bernama, dan root tetap jadi tujuan yang kamu naiki, bukan pintu yang kamu lewati lurus.

Langkah empat: rapikan sisa konfigurasinya

Dengan key terpasang, password mati, dan root terkunci, kamu sudah menutup lubang-lubang terbesar. Beberapa pengaturan lagi menghaluskan sisa sudut yang tersisa. Tidak ada satu pun dari ini yang dramatis sendirian, tapi digabung mereka mengecilkan paparanmu.

Batasi siapa yang boleh login. Secara default, akun user mana pun di sistem bisa SSH masuk. Kamu bisa membatasinya jadi sebuah daftar pendek yang eksplisit, jadi akun valid sekalipun yang tidak ada di daftar tetap ditolak:

# Hanya user-user ini yang boleh menyambung lewat SSH
AllowUsers john jane

Ubah port default (opsional). SSH mendengarkan di port 22 secara default, dan bot memindai port itu tanpa henti. Memindahkan SSH ke port tidak standar tidak akan menghentikan penyerang yang gigih — ini bukan keamanan sungguhan kalau berdiri sendiri — tapi ini drastis memangkas volume derau otomatis yang menabrak log-mu, karena kebanyakan pemindai massal cuma mengecek port default.

# Memindahkan SSH dari port terkenal (pertahanan berlapis, bukan pengganti)
Port 2222

Atur batas waktu login dan batasi percobaan. Ini membatasi berapa lama koneksi yang belum terautentikasi boleh menganggur dan berapa kali percobaan yang dia dapat, sehingga koneksi yang macet atau jahat tidak bisa berlama-lama:

LoginGraceTime 30
MaxAuthTries 3

Bagaimana akses key terpetakan ke berkas

Ada baiknya membayangkan di mana semua ini secara fisik berada, karena keamanan key SSH sebenarnya cuma pengelolaan cermat atas beberapa berkas dan izinnya. Di sisi server, authorized key tiap user berada di home directory mereka masing-masing:

/home/john/
└── .ssh/
    ├── authorized_keys     ← public key yang boleh login sebagai john
    └── (izinnya penting: 700 untuk .ssh, 600 untuk berkasnya)

SSH sengaja galak soal izin ini. Kalau folder .ssh atau berkas authorized_keys bisa dibaca atau ditulis oleh user lain, SSH sering kali menolak memakai key itu sama sekali sebagai langkah pengaman — karena berkas key yang bisa disunting siapa saja adalah berkas key yang bisa ditambahi siapa saja. Persis inilah kenapa memahami izin berkas berbuah di sini: izin yang tepat bukan birokrasi, tapi bagian dari model keamanannya. Folder-nya sebaiknya 700 (cuma pemilik yang boleh menyentuh) dan berkasnya 600 (cuma pemilik yang boleh membaca atau menulis).

Satu baseline yang masuk akal, lengkap sekaligus

Kamu tidak perlu mengarang kebijakanmu sendiri. Ini konfigurasi awal yang kukuh dan lazim, mencakup semua hal di atas — jenis baseline yang menahan banjir otomatis sambil tetap nyaman dipakai:

# /etc/ssh/sshd_config — baseline yang sudah dikuatkan
PasswordAuthentication no       # key saja, tidak ada tebak-password
PermitRootLogin no              # tidak ada root langsung; pakai sudo
AllowUsers john jane            # hanya akun ini yang boleh menyambung
MaxAuthTries 3                  # sedikit percobaan per koneksi
LoginGraceTime 30               # jangan biarkan koneksi berlama-lama
Port 2222                       # lepas dari default (opsional, kurangi derau)

Terapkan, muat ulang SSH, dan pastikan kamu masih bisa login dari sesi baru sebelum menutup sesi yang sedang berjalan. Kebiasaan hati-hati itu — ubah, uji di jendela baru, baru percaya — adalah pembeda antara server yang sudah dikuatkan dan terkunci di luar gara-gara ulah sendiri. Dengan ini terpasang, serangan latar yang terus-menerus terhadap server-mu cuma menabrak pintu tertutup yang hanya mau menerima key.

Kenapa ini penting di luar server-mu sendiri

Gampang mengira bahwa menguatkan SSH cuma penting buat mesin besar yang penting. Tidak begitu. Sebuah VPS pribadi kecil tanpa apa pun yang berharga di dalamnya tetap jadi hadiah buat penyerang — bukan demi datamu, tapi sebagai pijakan untuk melancarkan serangan ke orang lain, menambang kripto, atau bergabung ke botnet. Setiap server yang bisa dijangkau adalah sasaran, titik. Mengunci SSH bukan soal seberapa penting kamu mengira server-mu; itu kebersihan dasar agar jadi bagian internet yang bertanggung jawab.

Dan imbalannya luar biasa dibanding usahanya. Pengaturan di artikel ini mungkin cuma butuh sepuluh menit untuk diterapkan sekali, dan dia menutup pintu bagi sebagian besar serangan dunia nyata — yang otomatis dan oportunistik, yang menyusun hampir seluruh derau itu. Tidak perlu kepintaran khusus; cukup tutup pintu-pintu yang gampang, dan para bot pindah ke sasaran yang lebih empuk.

Penutup

Ini gambaran utuhnya dalam satu tempat:

• SSH adalah pintu bernilai tertinggi di server karena dia membagikan shell penuh — kendali atas seluruh mesin — jadi dialah hal pertama yang layak dikuatkan.
• Enkripsinya kuat; titik lemahnya ada di cara kamu login. Hampir semua serangan adalah tebak-password otomatis, jadi tujuannya adalah menghapus apa pun yang bisa ditebak.
• Pakai autentikasi berbasis key alih-alih password: private key tinggal di mesinmu, public key tinggal di server, dan tidak ada rahasia yang melintasi jaringan.
• Matikan login password (PasswordAuthentication no) begitu key-mu bekerja, supaya tak ada lagi password untuk ditebak — tapi selalu uji key di sesi baru lebih dulu.
• Larang root login langsung (PermitRootLogin no) dan pakai akun biasa plus sudo, mengubah satu gembok jadi dua.
• Rapikan sisanya: batasi siapa yang boleh menyambung (AllowUsers), opsional pindah dari port 22, batasi percobaan, dan jaga izin berkas key tetap ketat (700/600).

Begitu SSH terkunci, langkah berikutnya yang alami adalah lapisan di depannya: memutuskan port mana yang bahkan bisa dijangkau dari luar sejak awal. Itulah tugas firewall — tembok yang mengatur siapa yang bahkan boleh mengetuk pintunya.