Saya melaburkan masa yang agak lama untuk menghadam kegunaan protokol Kerberos menerusi banyaknya sesi percubaan yang mengecewakan. Setelah menempuh bersiri-siri episod kehampaan, kali ini terbayar juga sekian jumlah sumbangan tenaga yang agak melelahkan itu.

Penjelasan yang tuntas mengenai kaedah pengesahan dengan Kerberos ini boleh diperolehi dari YouTube, Kerberos Authentication Explained | A deep dive.

Sungguh! Prosesnya begitu rumit, sementelah betapa sebelum ini banyak kekeliruan yang saya alami dek kurangnya kemahiran dan kefahaman tentang perbezaan antara domain dan REALM, juga dalam bab menguruskan domain.

Makanya, empat topik yang akan saya sentuh di sini iaitu:

1. Pemasangan & Konfigurasi Kerberos di KDC
2. Pemasangan & Konfigurasi Kerberos di Klien
3. Sambungan SSH Menggunakan Pengesahan GSSAPI
4. Penyediaan dua VM Fedora (QEMU/KVM), khusus untuk tujuan belajar Kerberos ini. Saya kebelakangkan topik ini agar tumpuan utama diberikan kepada topik Kerberos terlebih dahulu. Topik ini hanya untuk dirujuk apabila perlu kepada pengetahuan menguruskan VM yang mungkin tidak cukup dimahiri sebelum ini.
   

Tetapan Wajib di Kedua-dua Mesin Maya

• Maklumat rangkaian kedua-dua VM Fedora: VM1 adalah sebagai KDC yakni server manakala VM2 akan bertindak sebagai klien. Nama pengguna untuk kedua-dua VM adalah sama, iaitu hadoop.

  /etc/hosts

  192.168.0.101   master.cluster.loc master   # KDC/Server 
  192.168.0.102   worker.cluster.loc worker   # Klien

• (Optional) Jika perlu memindahkan fail antara VM sebelum menggunakan tiket Kerberos untuk log masuk SSH, disarankan menjana kunci SSH di setiap VM. Kemudian, salin kunci tersebut antara VM secara timbal balik untuk membolehkan sambungan SSH tanpa kata laluan. Setelah itu, barulah digantikan dengan kaedah pengesahan menggunakan TGT melalui proses-proses konfigurasi seterusnya.

  bash

  ssh-keygen
  ssh-copy-id -i ~/.ssh/id_ed25519.pub <hostname / IP address> 

  Fail konfigurasi SSH:

  ~/.ssh/config

  # global options                          
  Host *
    IdentitiesOnly yes
    IdentityFile ~/.ssh/id_ed25519
  
  # host & client specific options
  Host master 
    HostName master.cluster.loc
  
  Host worker 
    HostName worker.cluster.loc

• Uruskan perihal masa yang perlu diselaraskan terlebih dahulu. Fedora menetapkan masa kepada lokal secara lalai. Kita mahu seragamkan masa ini secara automatik melalui rangkaian dan bukan secara lokal. Maka nyahkan terlebih dahulu tetapan lokal. Fedora menetapkan servis chronyd secara lalai untuk NTP maka boleh semak statusnya dari servis berkenaan.

  bash

  sudo timedatectl set-local-rtc 0
  timedatectl
  chronyc tracking

  Reference ID    : 2BD8B124 (ntp2.demimasa.my)
  Stratum         : 3
  Ref time (UTC)  : Sun Feb 09 08:24:45 2025
  System time     : 0.000619294 seconds fast of NTP time
  Last offset     : +0.000626924 seconds
  RMS offset      : 0.061736684 seconds
  Frequency       : 6.417 ppm fast
  Residual freq   : -4.732 ppm
  Skew            : 0.215 ppm
  Root delay      : 0.029564878 seconds
  Root dispersion : 0.054725591 seconds
  Update interval : 64.8 seconds
  Leap status     : Normal
  

  Umumnya, aras Stratum yang bagus adalah 5 dan ke bawah kerana ia menunjukkan bahawa jam telah diseragamkan dengan sumber yang dipercayai. Semestinya aras 1 adalah terbaik tetapi peranti yang mencapai aras 1 keseragaman masa biasanya melibatkan kos yang tinggi, namun tidaklah semahal peranti-peranti yang menjadi sumber primer dalam rujukan bagi keselarasan masa dengan aras Stratum 0. Dalam kes saya ini, aras 3 sudah memadai.

Pemasangan & Konfigurasi Kerberos di KDC

• Pemasangan:
  bash

  sudo dnf install krb5-server krb5-libs krb5-workstation -y

Terdapat empat fail konfigurasi yang mesti ada:

krb5.conf

# To opt out of the system crypto-policies configuration of krb5, remove the
# symlink at /etc/krb5.conf.d/crypto-policies which will not be recreated.
includedir /etc/krb5.conf.d/

[logging]
  default = FILE:/var/log/krb5libs.log
  kdc = FILE:/var/log/krb5kdc.log
  admin_server = FILE:/var/log/kadmind.log

[libdefaults]
  ticket_lifetime = 24h
  renew_lifetime = 7d
  forwardable = true
  pkinit_anchors = FILE:/etc/pki/tls/certs/ca-bundle.crt
  default_realm = CLUSTER.LOC
  default_ccache_name = KEYRING:persistent:%{uid}

[realms]
  CLUSTER.LOC = {
    kdc = master.cluster.loc
    admin_server = master.cluster.loc
  }

[domain_realm]
  .cluster.loc = CLUSTER.LOC
  cluster.loc = CLUSTER.LOC

kdc.conf

[kdcdefaults]
  kdc_ports = 88
  kdc_tcp_ports = 88

[realms]
  CLUSTER.LOC = {
    database_name = /var/kerberos/krb5kdc/principal
    acl_file = /var/kerberos/krb5kdc/kadm5.acl
    key_stash_file = /var/kerberos/krb5kdc/.k5.CLUSTER.LOC
    admin_keytab = /var/kerberos/krb5kdc/kadm5.keytab
    default_principal_flags = +preauth
    max_life = 10h 0m 0s
    max_renewable_life = 7d 0h 0m 0s
    master_key_type = aes256-cts-hmac-sha1-96
    supported_enctypes = aes256-cts-hmac-sha1-96:normal aes128-cts-hmac-sha1-96:normal 
    # aes256-cts-hmac-sha384-192:normal aes128-cts-hmac-sha256-128:normal camellia256-cts-cmac:normal camellia128-cts-cmac:normal
}

kadm5.acl

*/admin@CLUSTER.LOC	*
hadoop/admin@CLUSTER.LOC e *

Pengisian entri baris dirujuk dari Dokumentasi MIT untuk kadm5.acl yang antaranya memetik:

“The extract privilege is not included in the wildcard privilege; it must be explicitly assigned. This privilege allows the user to extract keys from the database, and must be handled with great care to avoid disclosure of important keys like those of the kadmin/* or krbtgt/* principals. The lockdown_keys principal attribute can be used to prevent key extraction from specific principals regardless of the granted privilege.”

.k5login

hadoop@CLUSTER.LOC

• Cipta pangkalan data:-

  bash

  sudo kdb5_util -r CLUSTER.LOC create -s

  Initializing database '/var/kerberos/krb5kdc/principal' for realm 'CLUSTER.LOC',
  master key name 'K/M@CLUSTER.LOC'
  You will be prompted for the database Master Password.
  It is important that you NOT FORGET this password.
  Enter KDC database master key:
  Re-enter KDC database master key to verify:
  

• Mulakan servis:-

  bash

  sudo systemctl enable --now krb5kdc
  sudo systemctl enable --now kadmin

  Dalam Arch Linux, kedua-dua servis dinamakan sebagai krb5-kdc dan krb5-kadmind.

• Teruskan dengan langkah-langkah selanjutnya. Dua langkah pertama menambah prinsipal untuk kegunaan pengguna biasa dan pentadbiran, diikuti dengan penjanaan prinsipal host/master.cluster.loc menggunakan kunci rawak bagi pengesahan hos. Akhir sekali, ktadd digunakan untuk menyimpan kunci tersebut dalam fail keytab bagi membolehkan akses tanpa kata laluan.

  bash

  sudo kadmin.local

  Authenticating as principal root/admin@CLUSTER.LOC with password.
  kadmin.local:  addprinc hadoop@CLUSTER.LOC
  No policy specified for hadoop@CLUSTER.LOC; defaulting to no policy
  Enter password for principal "hadoop@CLUSTER.LOC":
  Re-enter password for principal "hadoop@CLUSTER.LOC":
  Principal "hadoop@CLUSTER.LOC" created.
  kadmin.local:  addprinc hadoop/admin@CLUSTER.LOC
  No policy specified for hadoop/admin@CLUSTER.LOC; defaulting to no policy
  Enter password for principal "hadoop/admin@CLUSTER.LOC":
  Re-enter password for principal "hadoop/admin@CLUSTER.LOC":
  Principal "hadoop/admin@CLUSTER.LOC" created.
  kadmin.local:  addprinc -randkey host/master.cluster.loc
  No policy specified for host/master.cluster.loc@CLUSTER.LOC; defaulting to no policy
  Principal "host/master.cluster.loc@CLUSTER.LOC" created.
  kadmin.local:  ktadd host/master.cluster.loc
  Entry for principal host/master.cluster.loc with kvno 2, encryption type aes256-cts-hmac-sha1-96 added to keytab FILE:/etc/krb5.keytab.
  Entry for principal host/master.cluster.loc with kvno 2, encryption type aes128-cts-hmac-sha1-96 added to keytab FILE:/etc/krb5.keytab.
  kadmin.local:  quit
  

• Sesi percubaan: dapatkan tiket Kerberos di KDC.

  bash

  kinit

• Paparkan maklumat tiket.

  bash

  klist

  Ticket cache: KCM:1000
  Default principal: hadoop@CLUSTER.LOC
  
  Valid starting       Expires              Service principal
  02/09/2025 10:10:02  02/09/2025 20:10:02  krbtgt/CLUSTER.LOC@CLUSTER.LOC 
          renew until 02/10/2025 10:09:58
  

• Sebelum beralih ke konfigurasi untuk klien, salin fail /etc/krb5.conf ke dalam direktori $HOME terlebih dahulu.

  bash

  cp /etc/krb5.conf .

  
  

Konfigurasi Kerberos di Klien

• krb5-libs dan krb5-workstation memang sudah terpasang dalam Fedora Server. Salin fail krb5.conf dari KDC (VM1) ke Klien (VM2) dan alihkannya ke direktori /etc/:

  bash

  scp master:krb5.conf .
  sudo mv krb5.conf /etc

• Pastikan Klien dapat berkomunikasi dengan KDC melalui arahan berikut:

  bash

  sudo dnf install telnet telnet-server -y
  ping -c3 master.cluster.loc    # Check connectivity
  telnet master.cluster.loc 88   # Verify KDC is listening on port 88

• Sesi percubaan: dapatkan tiket Kerberos di Klien.

  bash

  kinit

• Paparkan maklumat tiket.

  bash

  klist

  Ticket cache: KCM:1000
  Default principal: hadoop@CLUSTER.LOC
  
  Valid starting       Expires              Service principal
  02/09/2025 10:17:52  02/09/2025 20:17:52  krbtgt/CLUSTER.LOC@CLUSTER.LOC
          renew until 02/10/2025 10:17:48
  

• Cuba akses kadmin dari klien sebagai root:

  bash

  sudo kadmin -p hadoop/admin

  Authenticating as principal hadoop/admin with password.
  Password for hadoop/admin@CLUSTER.LOC:
  kadmin:  listprincs
  K/M@CLUSTER.LOC
  hadoop/admin@CLUSTER.LOC
  hadoop@CLUSTER.LOC
  host/master.cluster.loc@CLUSTER.LOC
  kadmin/admin@CLUSTER.LOC
  kadmin/changepw@CLUSTER.LOC
  krbtgt/CLUSTER.LOC@CLUSTER.LOC
  kadmin:   
  

  
  

Sambungan SSH Menggunakan Pengesahan GSSAPI

• Konfigurasi universal SSH (tetapkan perkara di bawah ini di kedua-dua VM). Nyahkan komen dan aktifkan opsyen Kerberos serta GSSAPI:

  /etc/ssh/sshd_config

  # Kerberos options
  KerberosAuthentication yes
  
  # GSSAPI options
  GSSAPIAuthentication yes
  GSSAPICleanupCredentials yes
  GSSAPIKeyExchange yes

  /etc/ssh/ssh_config

  Host *
    GSSAPIAuthentication yes
    GSSAPIDelegateCredentials yes
    GSSAPIKeyExchange yes

  Kaedah pengesahan dengan KeyExchange tidak disokong dalam Arch Linux. Sebaliknya, kaedah pengesahan yang digunakan adalah gssapi-with-mic.

• Mulakan semula servis: sudo systemctl restart sshd.

• Di VM2 (Klien): Tambahkan hos klien dan hasilkan kunci rambang untuknya. Saya percaya langkah ini adalah bertepatan dengan perbincangan di ArchWiki pada bab [5.1: Service principals and keytabs with remote kadmin].

  bash

  sudo kadmin -p hadoop/admin

  kadmin:  addprinc -randkey host/worker.cluster.loc
  No policy specified for host/worker.cluster.loc@CLUSTER.LOC; defaulting to no policy
  Principal "host/worker.cluster.loc@CLUSTER.LOC" created.
  kadmin:  ktadd host/worker.cluster.loc
  Entry for principal host/worker.cluster.loc with kvno 2, encryption type aes256-cts-hmac-sha1-96 added to keytab FILE:/etc/krb5.keytab.
  Entry for principal host/worker.cluster.loc with kvno 2, encryption type aes128-cts-hmac-sha1-96 added to keytab FILE:/etc/krb5.keytab.
  kadmin:  quit
  

• Cuba SSH ke KDC (Server) dengan opsyen -v.

  bash

  ssh -v master 

  ...
  debug1: Next authentication method: gssapi-keyex
  Authenticated to master.cluster.loc ([192.168.0.101]:22) using "gssapi-keyex". 
  ...
  

• Semak maklumat tiket di kedua-dua VM dengan arahan klist.

  VM1 (KDC):

  Ticket cache: KCM:1000:71016
  Default principal: hadoop@CLUSTER.LOC
  
  Valid starting       Expires              Service principal
  02/10/2025 10:47:54  02/10/2025 20:47:29  krbtgt/CLUSTER.LOC@CLUSTER.LOC
          renew until 02/17/2025 10:47:27
  

  VM2 (Klien):

  Ticket cache: KCM:1000
  Default principal: hadoop@CLUSTER.LOC
  
  Valid starting       Expires              Service principal
  02/10/2025 10:47:29  02/10/2025 20:47:29  krbtgt/CLUSTER.LOC@CLUSTER.LOC
          renew until 02/17/2025 10:47:27
  02/10/2025 10:47:54  02/10/2025 20:47:29  host/master.cluster.loc@CLUSTER.LOC
          renew until 02/17/2025 10:47:27
  

• Saya kira, selesai sudah bahagian Kerberos ini. Cache tiket boleh dihapuskan dengan perintah kdestroy.

  Untuk menyemak kunci:

  bash

  sudo klist -kte /etc/krb5.keytab

  Keytab name: FILE:/etc/krb5.keytab
  KVNO Principal
  ---- --------------------------------------------------------------------------
     2 host/worker.cluster.loc@CLUSTER.LOC (aes256-cts-hmac-sha1-96)
     2 host/worker.cluster.loc@CLUSTER.LOC (aes128-cts-hmac-sha1-96)
  

  Untuk memadam kunci:

  bash

  sudo kadmin.local

  Authenticating as principal root/admin@CLUSTER.LOC with password.
  kadmin.local:  ktrem -q host/worker.cluster.loc 
  kadmin.local:    
  

Penyediaan dua VM Fedora (QEMU/KVM)

• Sila rujuk di bahagian nota: “Penyediaan dua VM Fedora (QEMU/KVM)”
  

Penyelesaian Masalah

After rebooting the VMs, there was an issue with the sssd-kcm service in VM2, where the kinit command threw the following error:

kinit: Connection refused while getting default ccache

Checking the service status using:

systemctl status sssd-kcm

returned the following output:

Failed to init Kerberos context [Permission denied]
Failed to start sssd-kcm.service - SSSD Kerberos Cache Manager.

The issue can be temporarily fixed using the command below, but ChatGPT and DeepSeek do not recommend this as a long-term solution for a production system:

sudo semanage permissive -d sssd_t

The recommended approach is to create or modify an SELinux policy to properly allow sssd-kcm to function without disabling security mechanisms.

Bolehkah Dua Realm Kerberos Berbeza Dipautkan?

Ya, boleh! Untuk membolehkan dua KDC saling mempercayai dan menyokong cross-realm authentication, anda perlu menetapkan tiga seksyen utama dalam fail konfigurasi /etc/krb5.conf pada kedua-dua pelayan KDC:

1. [realms]
2. [domain_realm]
3. [capaths]

Sebagai contoh, KDC 1 menggunakan realm ARCHEY.LOC, manakala KDC 2 menggunakan realm CLUSTER.VM.

• KDC 1
• KDC 2

...

[realms]
 ARCHEY.LOC = {
   kdc = kdc.archey.loc
   admin_server = kdc.archey.loc
 }
 CLUSTER.VM = {
   kdc = single.cluster.vm
   admin_server = single.cluster.vm
 }

[domain_realm]
 .archey.loc = ARCHEY.LOC
 .cluster.vm = CLUSTER.VM

# Cross-realm authentication
[capaths]
 ARCHEY.LOC = {
   CLUSTER.VM = .
 }
 CLUSTER.VM = {
   ARCHEY.LOC = .
 }

...

[realms]
 CLUSTER.VM = {
   kdc = single.cluster.vm
   admin_server = single.cluster.vm
 }
 ARCHEY.LOC = {
   kdc = kdc.archey.loc
   admin_server = kdc.archey.loc
 }

[domain_realm]
 .cluster.vm = CLUSTER.VM
 .archey.loc = ARCHEY.LOC

# Cross-realm authentication
[capaths]
 CLUSTER.VM = {
   ARCHEY.LOC = .
 }
 ARCHEY.LOC = {
   CLUSTER.VM = .
 }

Langkah Tambahan yang Diperlukan

• Tambahkan prinsipal cross-realm trust pada kedua-dua pangkalan data KDC seperti yang diterangkan dalam dokumentasi rasmi MIT Kerberos di bahagian Cross-realm authentication:

  • krbtgt/ARCHEY.LOC@CLUSTER.VM
  • krbtgt/CLUSTER.VM@ARCHEY.LOC
    

• Pastikan prinsipal hos KDC turut disilangkan ke keytab utama di pelayan lawan:

  • Dari KDC1: host/kdc.archey.loc@ARCHEY.LOC mesti dimasukkan ke /etc/krb5.keytab di KDC2.
  • Dari KDC2: host/single.cluster.vm@CLUSTER.VM mesti dimasukkan ke /etc/krb5.keytab di KDC1.
    

• Jangan lupa juga menambah entri pengguna lintas-realm (<user>@REALM) dalam fail ~/.k5login pada setiap hos supaya pengguna dari realm berlawanan dapat disahkan masuk.