Autenticazione SSH utilizzando gssapi-keyex o gssapi-with-mic (chiave pubblica non consentita)

Forse.

• Puoi ottenere un ticket per il tuo principale sul tuo sistema client come parte del processo di accesso standard o manualmente (kinit, MIT Kerberos per Windows)?
• Il server ha un principal Kerberos o puoi dargliene uno? Deve essere nel formato host/[email protected].
• Lautenticazione GSSAPI è abilitata sul tuo client?
• Il tuo client sa a quale ambito appartiene il server tramite il record di risorse DNS TXT o la mappatura locale?

Se hai detto “sì” a tutto di cui sopra, quindi congratulazioni, puoi utilizzare GSSAPIAuthentication.

• Puoi è inoltre necessario abilitare la delega delle credenziali, a seconda della configurazione.

Passaggi del test:
(supponendo: domain = example.com; realm = EXAMPLE.COM)

1. kinit [email protected]
   • Idealmente questo viene gestito dal processo di accesso standard includendo pam_krb5 o pam_sss (con auth_provider = krb5) nellapposito pam stack.
2. kvno host/[email protected]
   • Questo è un passaggio di debug. ssh lo fa automaticamente se disponi di una cache valida e stai parlando con un sshd che supporta gssapi-with-mic o gssapi-keyex.
3. dig _kerberos.example.com txt dovrebbe restituire "EXAMPLE.COM"
   • In alternativa, la mappatura può essere archiviata nella [domain_realm] sezione di /etc/krb5.conf come .example.com = EXAMPLE.COM, ma il metodo dns scala molto meglio.
4. ssh -o GSSAPIAuthentication=yes [email protected]
   • Per accedere a un nome utente diverso da quello del tuo principale sul server dovrai sapere per mapparlo i dettagli di cui non sto entrando qui.

Commenti

• Ciao. Ti ho dato +1 qualche tempo fa, ma in realtà non lo faccio sapere come controllare i tuoi quattro punti. (Non sono un amministratore, solo uno sviluppatore). Per favore, potresti fornire una riga di comando per controllare la connessione SSH usando g gssapiauthentication? Forse posso anche usare gssapiauthentication sulla mia macchina Linux. (dovrei usare kinit per questo?) Cheers;)

Il metodo in 4 passaggi è corretto (ci sono anche record Kerberos SRV nel DNS che sono ancora più eleganti e sono presenti in ogni Active Directory). Lo uso sempre e ho sostenuto questi metodi sopra pubkey per, principalmente, motivi di sicurezza e controllo.

Detto questo, questo fornisce solo un login interattivo, sebbene possa essere quasi interattivo una volta che hai ottenuto un ticket sulla tua workstation.Il ticket Kerberos si comporta in modo molto simile allagente SSH; una volta installato, le nuove connessioni sono istantanee e prive di password; anche se con un limite di tempo.

Per ottenere un accesso batch interattivo, è necessario ottenere un file keytab, un file che essenzialmente contiene la password per un account Kerberos, molto simile alla metà privata di una chiave SSH. Secondo le precauzioni di sicurezza si applicano; soprattutto perché la keytab non è crittografata o protetta con una password.

Sono piuttosto riluttante a fornire ai miei utenti le schede delle chiavi per i loro account personali, ma utilizzo in modo aggressivo account di servizio con autorizzazioni minime per vari lavori batch, soprattutto dove è fondamentale che le credenziali siano delegate al telecomando sistema, qualcosa che pubkey semplicemente non può ottenere.

I keytab possono essere creati usando ktutil su Unix o KTPASS.EXE su Windows (questultimo dai servizi AD Kerberos). Nota che ktutil esiste in due versioni, Heimdal e MIT, e la loro sintassi è diversa. La lettura della manpage su un sistema pertinente aiuta.