Come funziona Kerberos con SSH?

Primo accesso:

• L invia il nome utente e la richiesta di autenticazione SSH a S1
• S1 restituisce i meccanismi di autenticazione SSH disponibili, con "password" come uno di essi
• L sceglie "password" e invia la semplice password a S1
• S1 fornisce nome utente e password allo stack PAM.
• Su S1, PAM (solitamente pam_krb5 o pam_sss ) richiede un TGT (ticket granting ticket) dal Kerberos KDC.
  1. S1 ottiene un TGT.
     • Vecchio stile (senza preautenticazione):S1 invia un AS-REQ e riceve un AS-REP contenente il TGT.
     • Nuovo stile (con preauth):S1 utilizza la tua password per crittografare il timestamp corrente e lo allega all'AS-REQ. Il server decrittografa il timestamp e verifica che rientri nell'intervallo di tempo consentito; se la decrittazione fallisce, la password viene immediatamente rifiutata. In caso contrario, viene restituito un TGT nell'AS-REP.
  2. S1 tenta di decrittografare il TGT utilizzando una chiave generata dalla tua password. Se la decrittazione riesce, la password viene accettata come corretta.
  3. Il TGT viene memorizzato in una cache delle credenziali appena creata. (Puoi ispezionare il file $KRB5CCNAME variabile d'ambiente per trovare la ccache, o usa klist per elencarne il contenuto.)
• S1 utilizza PAM per eseguire controlli di autorizzazione (dipendenti dalla configurazione) e aprire la sessione.
  • Se pam_krb5 viene chiamato in fase di autorizzazione, controlla se ~/.k5login esiste. In caso affermativo, deve elencare l'entità client Kerberos. Altrimenti, l'unico principal consentito è username@DEFAULT-REALM .

Secondo accesso:

• S1 invia il nome utente e la richiesta di autenticazione SSH a S2
• S2 restituisce i mech di autenticazione disponibili, uno dei quali è "gssapi-with-mic"
• S1 richiede un ticket per host/s2.example.com@EXAMPLE.COM , inviando un TGS-REQ con il TGT al KDC, e ricevendo da esso un TGS-REP con il ticket di servizio.
• S1 genera una "AP-REQ" (richiesta di autenticazione) e la invia a S2.
• S2 tenta di decifrare la richiesta. Se ha esito positivo, l'autenticazione viene eseguita. (PAM non è utilizzato per l'autenticazione.)
  • Altri protocolli come LDAP possono scegliere di crittografare l'ulteriore trasmissione di dati con una "chiave di sessione" inclusa nella richiesta; tuttavia, SSH ha già negoziato il proprio livello di crittografia.
• Se l'autenticazione riesce, S2 utilizza PAM per eseguire controlli di autorizzazione e aprire la sessione, come S1.
• Se l'inoltro delle credenziali è stato abilitato e il TGT ha il flag "inoltrabile", allora S1 richiede una copia del TGT dell'utente (con il flag "inoltrato" impostato) e lo invia a S2, dove viene memorizzato in un nuovo ccache . Ciò consente accessi ricorsivi con autenticazione Kerberos.

Tieni presente che puoi ottenere i TGT anche a livello locale. Su Linux, puoi farlo usando kinit , quindi connettiti utilizzando ssh -K . Per Windows, se hai effettuato l'accesso a un dominio Windows AD, Windows lo fa per te; in caso contrario, è possibile utilizzare MIT Kerberos. PuTTY 0.61 supporta l'utilizzo di Windows (SSPI) e MIT (GSSAPI), sebbene sia necessario abilitare l'inoltro (delega) manualmente.

gssapi-keyex è anche possibile ma non è stato accettato nell'OpenSSH ufficiale.