Come funziona Kerberos con SSH?

Supponiamo che io abbia quattro computer, Laptop, Server1, Server2, server Kerberos:

• Accedo usando PuTTY o SSH da L a S1, fornendo il mio nome utente / password
• Da S1 I quindi SSH a S2. Non è necessaria alcuna password poiché Kerberos mi autentica

Descrivi tutti gli scambi di protocollo SSH e KRB5 importanti: "L invia il nome utente a S1", "K invia ... a S1" ecc.

(Questa domanda deve essere modificata dalla comunità; per favore, migliorala per il lettore non esperto .)

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 questi
• L seleziona "password" e invia la password semplice a S1
• S1 fornisce nome utente e password allo stack PAM.
• Su S1, PAM (di solito pam_krb5o pam_sss) richiede un TGT (ticket di concessione ticket) dal KDC Kerberos.
  1. S1 ottiene un TGT.
     • Vecchio stile (senza preauth): S1 invia un AS-REQ e riceve un AS-REP contenente il TGT.
     • Nuovo stile (con preauth): S1 usa la tua password per crittografare il timestamp corrente e lo collega all'AS-REQ. Il server decodifica il timestamp e verifica che sia entro il tempo consentito; se la decodifica non riesce, la password viene immediatamente rifiutata. Altrimenti, un ASR viene restituito nell'AS-REP.
  2. S1 tenta di decrittografare il TGT utilizzando una chiave generata dalla tua password. Se la decodifica ha esito positivo, la password viene accettata come corretta.
  3. Il TGT è archiviato in una cache delle credenziali appena creata. (È possibile controllare la $KRB5CCNAMEvariabile di ambiente per trovare ccache o utilizzare klistper elencarne il contenuto.)
• S1 utilizza PAM per eseguire controlli di autorizzazione (in base alla configurazione) e aprire la sessione.
  • Se pam_krb5viene chiamato in fase di autorizzazione, verifica se ~/.k5loginesiste. In tal caso, deve elencare l'entità Kerberos client. Altrimenti, l'unico principale consentito è .username@DEFAULT-REALM

Secondo accesso:

• S1 invia il nome utente e la richiesta SSH authn a S2
• S2 restituisce i meccanismi di autenticazione disponibili, uno dei quali è "gssapi-with-mic" ¹
• S1 richiede un ticket per , inviando un TGS-REQ con il TGT al KDC e ricevendo un TGS-REP con il ticket di servizio da esso.host/s2.example.com@EXAMPLE.COM
• S1 genera un "AP-REQ" (richiesta di autenticazione) e lo invia a S2.
• S2 tenta di decrittografare la richiesta. Se riesce, l'autenticazione viene eseguita. (PAM non viene utilizzato per l'autenticazione.)
  • Altri protocolli come LDAP possono scegliere di crittografare un'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 ha esito positivo, S2 utilizza PAM per eseguire i controlli di autorizzazione e aprire la sessione, come S1.
• Se l'inoltro delle credenziali è stato abilitato e il TGT ha il flag "inoltrabile", 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.

Nota che puoi ottenere TGT anche localmente. Su Linux, puoi farlo usando kinit, quindi connettiti usando 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 in OpenSSH ufficiale.

Per farla breve: idealmente, i biglietti Kerberos dovrebbero essere ottenuti sul terminale (L), con kinitcomando o come parte della sequenza di accesso locale in una cosiddetta configurazione "single sign-on". I sistemi remoti (S1, S2) sarebbero quindi accessibili senza richieste di password. Un accesso concatenato (L → S1 → S2) sarebbe possibile impiegando una tecnica nota come "inoltro del biglietto". Tale configurazione richiede, in particolare, che il KDC sia direttamente accessibile dal terminale (L).

L'altra risposta di Grawity spiega questo approccio in dettaglio.

L'unico passo non ovvio qui sarebbe che esiste un modulo PAM su S1 che utilizzava le tue credenziali per eseguire un kinite ti procura un ticket che ti concede un ticket da K (autenticazione client). Quindi, quando si esegue SSH su S2 utilizzando l'autenticazione Kerberos, viene eseguita un'autenticazione del servizio client. Non vedo il vantaggio di passare attraverso tutti gli noiosi scambi messaggio per messaggio.

Lanciare a -vvvsul comando ssh se si desidera visualizzare tutti i messaggi e leggere la descrizione di Kerberos su Wikipedia .