Belajar Kerberos - SSH dengan Kerberos (GSSAPI)

#Pendahuluan

Di episode 12 kita mengamankan pembuktian identitas awal dengan preauth dan FAST — sekarang saatnya menuai manfaatnya. Bayangkan seorang sysadmin yang mengelola 50 server: setiap pagi mengetik password 50 kali, atau menyebar kunci SSH publik ke 50 mesin, lalu mencabutnya satu per satu ketika ada karyawan keluar. Kerberos mengubah semuanya menjadi sekali login. Di episode ini kita menyambungkan protokol tiket kita ke SSH melalui GSSAPI — jalan menuju single sign-on di dunia jaringan.

SSH sudah aman sejak lama lewat password atau kunci publik. Lalu mengapa repot-repot dengan Kerberos? Karena keduanya punya kelemahan administratif: password berarti mengetik berulang-ulang dan password bocor lewat prosesnya; kunci publik berarti distribusi (menempatkan kunci di setiap mesin) dan pencabutan (mencabut akses karyawan yang keluar) yang tersebar di mana-mana. Kerberos memusatkan semuanya: matikan principal di KDC, dan seluruh akses SSH pengguna itu langsung berhenti di mana pun.

#GSSAPI: Bahasa Penghubung untuk SSH

GSSAPI (Generic Security Services Application Program Interface) adalah antarmuka standar yang memungkinkan aplikasi bernegosiasi keamanan tanpa tahu mekanisme di baliknya. Di dunia Linux, mekanisme GSSAPI yang paling umum adalah Kerberos 5. Ketika kalian bilang "SSH pakai GSSAPI", maksudnya: SSH memakai antarmuka GSSAPI, dan implementasi GSSAPI-nya (biasanya libgssapi-krb5) yang menjalankan Kerberos di belakang layar.

Karena GSSAPI adalah standar, klien dan server bisa saling bertukar token keamanan dengan aturan yang seragam. Token inilah yang membawa service ticket Kerberos saat login berlangsung.

#Alur Login SSH dengan Kerberos

Mari ikuti perjalanan alice yang ingin ssh alice@server.example.com:

1. Pagi hari, alice menjalankan kinit dan mendapat TGT.
2. Saat ssh dijalankan, klien meminta autentikasi GSSAPI. SSH mengambil TGT milik alice, lalu meminta service ticket untuk principal host/server.example.com ke KDC.
3. Service ticket dikirim ke server sebagai token GSSAPI.
4. sshd menerima token, mendekripsinya dengan keytab miliknya sendiri, dan membaca identitas alice dari tiket.
5. Bila diaktifkan, server juga bisa meminta delegasi kredensial — meminjam TGT alice untuk dipakai di hop berikutnya.

Tidak ada password yang lewat jaringan, dan tidak ada kunci publik alice yang perlu tersimpan di server. Server hanya perlu satu hal: keytab yang berisi kunci host/server.example.com.

#Server: Konfigurasi sshd dan Host Principal

Di sisi server, pastikan daemon SSH mau menerima autentikasi GSSAPI. Edit /etc/ssh/sshd_config:

/etc/ssh/sshd_config - mengaktifkan GSSAPI

# Autentikasi lewat GSSAPI (Kerberos)
GSSAPIAuthentication yes
# Hapus kredensial Kerberos setelah sesi login berakhir
GSSAPICleanupCredentials yes
# Memungkinkan exchange kunci host berbasis GSSAPI
GSSAPIKeyExchange yes

Setelah diubah, sshd perlu membaca kunci yang cocok dengan identitasnya di Kerberos. Kunci itu disimpan di keytab — default /etc/krb5.keytab — dan harus berisi principal host/server.example.com. Buat dan ekstrak kuncinya lewat kadmin:

kadmin.local -q "addprinc -randkey host/server.example.com"
kadmin.local -q "ktadd -k /etc/krb5.keytab host/server.example.com"

Periksa bahwa keytab berisi entri yang benar:

klist -k /etc/krb5.keytab

Satu hal yang sering dilupakan: nama principal harus persis dengan nama host yang dipakai klien. Jika alice mengetik ssh server.example.com, service ticket yang diminta adalah host/server.example.com. Kalau alice mengetik ssh server saja (tanpa FQDN), permintaannya menjadi host/server — dan gagal karena principal itu tidak ada di KDC. Ini adalah sumber error klasik, dan cara menghindarinya adalah memastikan klien selalu memakai FQDN.

#Klien: Konfigurasi ssh_config

Di sisi klien, kinit harus sukses lebih dulu, lalu SSH perlu diizinkan mencoba GSSAPI. Edit /etc/ssh/ssh_config (atau di file per-user ~/.ssh/config):

~/.ssh/config - mengaktifkan GSSAPI di klien

Host *.example.com
    GSSAPIAuthentication yes
    GSSAPIDelegateCredentials yes
    GSSAPIKeyExchange yes

Baris GSSAPIDelegateCredentials yes penting jika kalian ingin melanjutkan perjalanan Kerberos dari server tujuan (multi-hop). Kita bedah detailnya di bagian berikut.

Dari baris perintah, cara tercepat adalah dengan flag -K yang mengaktifkan delegasi kredensial GSSAPI:

ssh -K alice@server.example.com

Kemudian verifikasi tiket yang terbentuk di server tujuan:

klist

Jika tampil TGT untuk alice@EXAMPLE.COM di cache server, berarti delegasi kredensial bekerja.

#ForwardAgent vs Delegasi Kredensial

Di sinilah banyak orang tertukar. Ada dua cara untuk "melanjutkan akses" dari satu server ke server lain:

• SSH Agent Forwarding (ForwardAgent) — meneruskan socket agent SSH. Artinya, proses di server tujuan bisa meminjam kunci privat SSH yang ada di mesin klien untuk mengautentikasi ke hop berikutnya. Kunci yang diteruskan adalah kunci publik/privat.
• GSSAPI Credential Delegation (GSSAPIDelegateCredentials) — meneruskan tiket Kerberos (TGT). Proses di server tujuan bisa meminta service ticket Kerberos baru atas nama kalian. Kredensial yang diteruskan adalah tiket, bukan kunci.

Pilihannya bergantung pada ekosistem: jika seluruh jaringan kalian sudah ber-Kerberos, delegasi GSSAPI lebih alami dan lebih mudah dicabut (tiket punya umur, kunci tidak). Jika masih ada mesin yang hanya kenal kunci SSH, agent forwarding jadi penolong. Perhatikan pula risiko delegasi: tiket yang didelegasikan memberi kekuatan penuh identitas kalian di server tujuan, jadi hanya aktifkan pada jump host yang kalian percayai — bukan pada sembarang server.

#Troubleshooting Autentikasi GSSAPI

Saat ssh menolak dan kalian melihat prompt password (berarti GSSAPI dilewati), langkah debugging dimulai dari pesan paling jujur di SSH: verbose logging.

ssh -vvv alice@server.example.com

Cari baris yang menyebut gssapi atau Authentications that can continue. Beberapa kegagalan yang paling umum:

1. Principal tidak ada di keytab. Pesan Server not found in Kerberos database (atau no principal in keytab) berarti keytab server tidak berisi host/server.example.com — padahal klien memintanya. Periksa dengan klist -k /etc/krb5.keytab dan cocokkan dengan nama host FQDN yang dipakai klien.

2. Realm tidak dikenal. Jika klien mengira realm-nya berbeda dari server, pertukaran tiket gagal. Pastikan default_realm di /etc/krb5.conf konsisten di kedua sisi, dan nama host server bisa dipetakan ke realm lewat [domain_realm].

3. Tiket klien kedaluwarsa atau hilang. Jalankan klist — jika kosong, kinit dulu. Error aneh seperti Clock skew too great juga muncul jika jam mesin melenceng (ingat preauth di episode 12).

4. Keytab salah permission. sshd yang berjalan sebagai root perlu bisa membaca keytab. Keytab dengan permission 0666 itu bahaya keamanan; keytab dengan permission terlalu ketat tapi pemilik salah juga akan ditolak pembacaannya.

5. Delegasi tidak diizinkan. Jika ssh -K berhasil login tapi klist di server kosong, kemungkinan GSSAPIDelegateCredentials di sisi klien off, atau server tidak mengembalikan tiket delegasi karena ok-as-delegate pada principal klien tidak diizinkan.

#Penutup

Pada episode ini kita mengubah SSH dari sistem autentikasi yang tersebar menjadi bagian dari ekosistem SSO: GSSAPI sebagai jembatan standar, host principal host/server.example.com di keytab sebagai identitas server, GSSAPIAuthentication di sshd_config, GSSAPIDelegateCredentials dan ssh -K untuk penerusan tiket, perbedaan mendasar antara agent forwarding dan delegasi kredensial, serta alur troubleshooting yang terarah.

Inti dari episode ini: SSH ber-Kerberos mengubah identitas server dari kunci yang tersimpan menjadi tiket yang terpusat — satu akun mati di KDC, semua akses SSH pengguna itu padam serentak. Ini investasi kecil pada konfigurasi yang membayar besar pada administrasi sehari-hari.

Di episode 14 kita menindaklanjuti prinsip yang sama ke data yang dibagikan: NFS dengan Kerberos (sec=krb5) — melindungi file share dari IP spoofing, tanpa integritas, dan tanpa enkripsi, menjadi layanan yang memverifikasi siapa pemakai sebenarnya. Sampai jumpa!