SSH Login – Public Key vs Password

Hai semuanya, apa kabar? Kali ini kita akan coba bahas tentang metode akses SSH ke server. Akses SSH ke server biasanya kita lakukan dengan format seperti ini: ssh user@server, lalu masukkan password-nya. Tapi, ada metode lain yang dapat diterapkan pada server, yaitu menggunakan public key. Opsi password juga bisa dimatikan. Jadinya, kalau kita akses ke server tapi di server tujuan key kita belum ada, maka kita tidak bisa akses ke server tersebut.

Apa Itu SSH?

Secure Shell (SSH) adalah protokol yang digunakan untuk mengakses remote server melalui Terminal. Semua perintah yang kita jalankan lewat sesi SSH terenkripsi, jadinya lebih aman dari ancaman penyadapan. Untuk memastikan bahwa yang mengakses server adalah pihak yang tepat, maka ada dua metode autentikasi yang digunakan, yaitu password & public key.

Password Login

Klasik, kita umumnya sudah paham cara kerja password login secara umum.

  • Kita jalankan perintah ssh user@server.
  • Server minta kita masukkan password.
  • Kita ketik password untuk akses ke server.
  • Proses pencocokan password oleh server.
  • Cocok=masuk.

Kelebihannya adalah relatif lebih sederhana, tidak perlu setup konfigurasi kompleks dan tidak ada file tambahan (dari kita/klien untuk login) yang diperlukan. Namun, beberapa kelemahan dari password login adalah lebih rentan terhadap brute force attack, password bisa bocor, lebih mudah ditebak, dan rawan serangan seperti Man in the middle (MITM).

Public Key Login

Mekanismenya adalah menggunakan keypair atau kunci berpasangan, yaitu private key dan public key:

  • Private key disimpan pada komputer pengguna/klien. Tidak boleh dibagikan ke pihak lain (baca: rahasia). Private key membuktikan kepemilikan akun/sistem.
  • Public key. File ini yang akan diberikan ke server (contoh direktorinya ada di ~/.ssh/authorized_keys). Public key yang dipegang oleh server bukan berarti server mengetahui private key kita. Mekanisme public key sudah dirancang agar siapa pun yang punya public key tidak bisa menebak private key.

Untuk bisa masuk ke server dengan metode public key, server tujuan harus sudah punya public key kita terlebih dahulu. Gimana maksudnya? “Kalau public key harus sudah terdaftar di server, gimana cara daftarin pertama kali? Kan saya belum bisa login”.

Akses via public key tidak “ajaib” terdaftar di server. Perlu ada yang menambahkan pubkey kita ke server. Skenario yang umum adalah ada seorang Admin yang bertugas untuk mendaftarkan pubkey kita.

Kita bisa buat pubkey di komputer kita dengan perintah berikut:

ssh-keygen -t ed25519

Hasil dari perintah tersebut adalah (contoh) id_ed25519 (private key SIMPAN, jangan dibagikan) dan id_ed25519.pub (pubkey). Kita bisa berikan pubkey-nya ke admin untuk ditambahkan pada server.

Misalnya kita setup VM cloud, biasanya mekanisme “setor key ke admin” dilakukan pada saat pembuatan instance/VM. Contohnya:

  • Saat bikin VM, kita diminta paste public key.
  • Cloud provider otomatis menaruh public key itu ke authorized_keys di VM baru.
  • Selesai, kita langsung bisa SSH tanpa setup tambahan.

Kelebihan dari metode ini adalah tahan terhadap serangan brute force, lebih aman (karena private key disimpan pribadi), kontrol lebih baik (bisa diatur/dibatasi per device), dan bisa diintegrasikan dengan sistem automatisasi.

Kelemahan.. atau tantangan dari implementasi pubkey login adalah perlu konfigurasi di awal, cenderung agak sulit untuk pemula, dan kita harus jaga baik-baik private key-nya untuk tetap punya akses ke server tujuan.

Namun, dari tantangan tersebut ada aspek-aspek yang “diuntungkan”:

  • Keamanan: Admin bisa memastikan hanya orang yang benar-benar berhak yang bisa masuk.
  • Audit: Setiap pubkey bisa dilacak siapa pemiliknya.
  • Kontrol: Kalau ada karyawan resign, admin cukup hapus public key-nya dari server. Tidak perlu ganti password semua orang.

Bandingkan dengan password: kalau satu karyawan resign, dan dia tahu password-nya, kamu harus ganti password server untuk semua orang.

Tulisan kali ini sampai di sini dulu ya. Sampai jumpa. Bye.

By Zaidan

Leave a Reply

Your email address will not be published. Required fields are marked *