Bagaimana cara Kerberos bekerja dengan SSH?

Misalkan saya punya empat komputer, Laptop, Server1, Server2, server Kerberos:

• Saya masuk menggunakan Putty atau SSH dari L ke S1, memberikan nama pengguna / kata sandi saya
• Dari S1 I lalu SSH ke S2. Tidak diperlukan kata sandi karena Kerberos mengotentikasi saya

Jelaskan semua pertukaran protokol SSH dan KRB5 yang penting: "L mengirimkan nama pengguna ke S1", "K mengirim ... ke S1" dll.

(Pertanyaan ini dimaksudkan untuk diedit oleh masyarakat; perbaiki untuk pembaca yang bukan pakar .)

Login pertama:

• L mengirimkan permintaan nama pengguna dan permintaan otentikasi SSH ke S1
• S1 mengembalikan mekanisme otentikasi SSH yang tersedia, dengan "kata sandi" sebagai salah satunya
• L mengambil "kata sandi" dan mengirimkan kata sandi polos ke S1
• S1 memberikan nama pengguna dan kata sandi ke tumpukan PAM.
• Pada S1, PAM (biasanya pam_krb5atau pam_sss) meminta TGT (tiket pemberian tiket) dari Kerberos KDC.
  1. S1 memperoleh TGT.
     • Gaya lama (tanpa preauth): S1 mengirimkan AS-REQ dan menerima AS-REP yang berisi TGT.
     • Gaya baru (dengan preauth): S1 menggunakan kata sandi Anda untuk mengenkripsi cap waktu saat ini, dan melampirkannya ke AS-REQ. Server mendekripsi stempel waktu dan memverifikasi bahwa itu berada dalam kemiringan waktu yang diizinkan; jika dekripsi gagal, kata sandi langsung ditolak. Jika tidak, TGT dikembalikan dalam AS-REP.
  2. S1 mencoba mendekripsi TGT menggunakan kunci yang dihasilkan dari kata sandi Anda. Jika dekripsi berhasil, kata sandi diterima sebagai benar.
  3. TGT disimpan ke cache kredensial yang baru dibuat. (Anda dapat memeriksa $KRB5CCNAMEvariabel lingkungan untuk menemukan ccache, atau gunakan klistuntuk membuat daftar isinya.)
• S1 menggunakan PAM untuk melakukan pemeriksaan otorisasi (tergantung konfigurasi) dan membuka sesi.
  • Jika pam_krb5dipanggil dalam tahap otorisasi, ia memeriksa apakah ~/.k5loginada. Jika ya, harus mencantumkan prinsip klien Kerberos. Kalau tidak, satu-satunya kepala sekolah yang diizinkan adalah .username@DEFAULT-REALM

Info masuk kedua:

• S1 mengirimkan nama pengguna dan permintaan SSH authn ke S2
• S2 mengembalikan mekanisme autor yang tersedia, salah satunya adalah "gssapi-with-mic" ¹
• S1 meminta tiket untuk , dengan mengirim TGS-REQ dengan TGT ke KDC, dan menerima TGS-REP dengan tiket layanan darinya.host/s2.example.com@EXAMPLE.COM
• S1 menghasilkan "AP-REQ" (permintaan otentikasi) dan mengirimkannya ke S2.
• S2 mencoba mendekripsi permintaan. Jika berhasil, otentikasi dilakukan. (PAM tidak digunakan untuk otentikasi.)
  • Protokol lain seperti LDAP dapat memilih untuk mengenkripsi transmisi data lebih lanjut dengan "kunci sesi" yang disertakan dengan permintaan; Namun, SSH telah menegosiasikan lapisan enkripsi sendiri.
• Jika otentikasi berhasil, S2 menggunakan PAM untuk melakukan pemeriksaan otorisasi dan membuka sesi, sama seperti S1.
• Jika penerusan kredensial diaktifkan dan TGT memiliki bendera "penerusan", maka S1 meminta salinan TGT pengguna (dengan set bendera "penerusan") dan mengirimkannya ke S2, di mana ia disimpan ke ccache baru. Ini memungkinkan login terautentikasi Kerberos yang diautentikasi.

Perhatikan bahwa Anda juga bisa mendapatkan TGT secara lokal. Di Linux, Anda dapat melakukan ini menggunakan kinit, lalu terhubung menggunakan ssh -K. Untuk Windows, jika Anda masuk ke domain Windows AD, Windows melakukannya untuk Anda; jika tidak, MIT Kerberos dapat digunakan. Putty 0,61 mendukung penggunaan Windows (SSPI) dan MIT (GSSAPI), meskipun Anda harus mengaktifkan penerusan (delegasi) secara manual.

¹ gssapi-keyex juga dimungkinkan tetapi tidak diterima ke dalam OpenSSH resmi.

Singkatnya: idealnya, tiket Kerberos harus diperoleh di terminal Anda (L), baik dengan kinitperintah atau sebagai bagian dari urutan masuk lokal dalam pengaturan yang disebut "akses masuk". Sistem jarak jauh (S1, S2) kemudian dapat diakses tanpa diminta kata sandi. Akses berantai (L → S1 → S2) dimungkinkan dengan menggunakan teknik yang dikenal sebagai "penerusan tiket". Pengaturan seperti itu membutuhkan, khususnya, KDC untuk dapat langsung diakses dari terminal (L).

Jawaban lain oleh grawity menjelaskan pendekatan ini secara rinci.

Satu-satunya langkah yang tidak jelas di sini adalah bahwa ada modul PAM pada S1 yang menggunakan kredensial Anda untuk melakukan kinitdan memberi Anda tiket pemberian tiket dari K (otentikasi klien). Kemudian, ketika Anda SSH ke S2 ​​menggunakan otentikasi Kerberos, otentikasi layanan klien terjadi. Saya tidak melihat manfaat dari melalui semua pertukaran pesan yang membosankan dengan pesan.

Lemparkan -vvvpada perintah ssh Anda jika Anda ingin melihat setiap pesan dan membaca deskripsi Wikipedia tentang Kerberos.