Kerberos SSH ile nasıl çalışır?


22

Diyelim ki dört bilgisayarım var, Dizüstü Bilgisayar, Sunucu1, Sunucu2, Kerberos sunucusu:

  • Kullanıcı adımı / şifremi vererek L'den S1'e PuTTY veya SSH kullanarak giriş yapıyorum
  • S1'den sonra SSH'ye S2'ye. Kerberos'un kimliğini doğruladığından şifre gerekmez

Tüm önemli SSH ve KRB5 protokol değişimlerini tanımlayın: "L, S1'e kullanıcı adı gönderir", "K, S1'e gönderir" vb.

(Bu sorunun topluluk tarafından düzenlenmesi amaçlanmıştır; lütfen uzman olmayan okuyucular için geliştirin .)

Yanıtlar:


27

İlk giriş:

  • L kullanıcı adı ve SSH kimlik doğrulama talebini S1'e gönderir
  • S1, mevcut SSH kimlik doğrulama mekanizmalarını ve bunlardan biri "parola" ile döndürür
  • L "password" alır ve düz şifreyi S1'e gönderir.
  • S1, PAM yığına kullanıcı adı ve şifre verir.
  • S1’de, PAM (genellikle pam_krb5veya pam_sss) Kerberos KDC’den bir TGT (bilet veren bilet) talep eder.
    1. S1 bir TGT alır.
      • Eski stil (ön hazırlıksız): S1, bir AS-REQ gönderir ve TGT'yi içeren bir AS-REP alır.
      • Yeni stil (önceden bildirilmiş): S1 mevcut zaman damgasını şifrelemek için şifrenizi kullanır ve AS-REQ'e ekler. Sunucu, zaman damgasının şifresini çözer ve izin verilen zaman kayması dahilinde olduğunu doğrular; şifre çözme başarısız olursa, şifre derhal reddedilir. Aksi takdirde, AS-REP'de bir TGT iade edilir.
    2. S1, şifrenizden oluşturulan bir anahtar kullanarak TGT'nin şifresini çözme girişiminde bulunur. Şifre çözme başarılı olursa, şifre doğru olarak kabul edilir.
    3. TGT, yeni oluşturulan bir kimlik bilgisi önbelleğine kaydedilir. ( $KRB5CCNAMEÖnbelleği bulmak için ortam değişkenini inceleyebilir veya klistiçeriğini listelemek için kullanabilirsiniz .)
  • S1 yetkilendirme kontrollerini yapmak (konfigürasyona bağlı) ve oturumu açmak için PAM kullanır.
    • Eğer pam_krb5yetkilendirme aşamasında denir, bu olmadığını kontrol eder ~/.k5loginbulunmaktadır. Varsa, müşteri Kerberos sorumlusunu listelemelidir. Aksi takdirde, izin verilen tek müdür .username@DEFAULT-REALM

İkinci giriş:

  • S1, S2'ye kullanıcı adı ve SSH authn isteği gönderir.
  • S2 bunlardan biri "gssapi-with-mic" olan kullanılabilir authmechs döndürür 1
  • S1 , KDT'ye TGT ile birlikte bir TGS-REQ göndermek ve KDC'ye REP'yi almak için bir bilet talep eder.host/s2.example.com@EXAMPLE.COM
  • S1 bir "AP-REQ" oluşturur (doğrulama talebi) ve S2'ye gönderir.
  • S2 isteğin şifresini çözmeye çalışır. Başarılı olursa, kimlik doğrulama yapılır. (PAM, kimlik doğrulama için kullanılmaz.)
    • LDAP gibi diğer protokoller daha fazla veri iletimini, istekle birlikte verilen bir "oturum anahtarı" ile şifrelemeyi seçebilir; ancak, SSH zaten kendi şifreleme katmanını pazarlık etti.
  • Kimlik doğrulama başarılı olursa, S2 yetkilendirme kontrolleri yapmak ve S1 ile aynı oturumu açmak için PAM kullanır.
  • Kimlik bilgisi iletme etkinleştirildiyse ve TGT'de "çekilebilir" bayrağı varsa, S1 kullanıcının TGT'sinin ("iletilen" bayrak kümesiyle) bir kopyasını ister ve S2'ye göndererek yeni bir önbelleğe depolanır. Bu özyinelemeli Kerberos kimlik doğrulamalı girişleri sağlar.

Yerel olarak da TGT’leri edinebileceğinizi unutmayın. Linux'ta bunu kullanarak yapabilir kinit, sonra bağlanabilirsiniz ssh -K. Windows için, bir Windows AD etki alanına giriş yaptıysanız, Windows bunu sizin için yapar; Aksi takdirde, MIT Kerberos kullanılabilir. PuTTY 0.61, hem Windows (SSPI) hem de MIT (GSSAPI) kullanımını desteklemektedir;


1 gssapi-keyex de mümkündür ancak resmi OpenSSH'ye kabul edilmedi.


Şifre, TGT ve KDC'den gelen cevap arasındaki ilişkiyi açıklayabilir misiniz? PAM'ın şifrenin doğru olup olmadığına nasıl karar verdiği açık değildir .
Phil

NOT: Bu cümle yanlıştır: "S1 bir TGS-REQ gönderir ve TGT'yi içeren bir TGS-REP alır." Yanlış çünkü TGT'ler AS_REP'in bir parçası olarak geliyor. Bir Servis Bileti TGS_REPn ile geri dönecek
14:02

1
OpenSSH'nin son sürümlerinde anahtar değişimi var. Bence 4.2p1 yamaları olan ilk versiyondu. ( sxw.org.uk/computing/patches/openssh.html )
20'de

Hayır yapmazlar. Bunlar üçüncü parti yamalar. "Resmi OpenSSH'ye kabul edilmedi" derken bunu kastediyorum
grawity

0

Uzun lafın kısası: İdeal olarak, Kerberos biletleri terminalinizde (L), kinit"tekli oturum açma" kurulumunda komutla veya yerel oturum açma sırasının bir parçası olarak alınmalıdır . Uzak sistemlere (S1, S2) şifre sorulmadan erişilebilir. Zincirleme erişim (L → S1 → S2), "bilet iletme" olarak bilinen bir teknik kullanılarak mümkün olabilir. Böyle bir kurulum, özellikle, KDC'nin, terminalden (L) doğrudan erişilebilir olmasını gerektirir.

Yerçekimi tarafından verilen diğer cevap , bu yaklaşımı ayrıntılarıyla açıklar.


-2

Buradaki açık olmayan tek adım, S1 üzerinde kimlik bilgilerinizi kullanarak a kullanan kinitve size K (müşteri kimlik doğrulaması) bileti veren bir bilet veren bir PAM modülü olmasıdır . Ardından, Kerberos kimlik doğrulamasını kullanarak SSH'den S2'ye, bir istemci hizmeti kimlik doğrulaması gerçekleşir. Tüm sıkıcı borsalar mesajını ileterek geçirmenin faydasını görmüyorum.

Bir atın -vvvher mesajı görmek ve okumak isterseniz SSH komuta Vikipedi açıklama Kerberos.


2
"Ayrıntıları ayrıntılandırmanın yararını görmüyorum" ile ayrıntılar isteyen bir soruyu yanıtlamak bana çok kaba görünüyor.
Massimo
Sitemizi kullandığınızda şunları okuyup anladığınızı kabul etmiş olursunuz: Çerez Politikası ve Gizlilik Politikası.
Licensed under cc by-sa 3.0 with attribution required.