SSH-Authentifizierung mit gssapi-keyex oder gssapi-with-mic (Veröffentlichung nicht gestattet)

Mein Unternehmen hat die SSH-Authentifizierung mit öffentlichem Schlüssel deaktiviert, daher muss ich jedes Mal mein Passwort manuell eingeben (ich darf es nicht ändern /etc/ssh/sshd_config).

Jedoch gssapi-keyexund gssapi-with-micAuthentifizierungen sind aktiviert (siehe unten sshDebug - Ausgabe).

Wie könnte ich in diesem Fall die automatische Anmeldung verwenden?
Kann ich ausnutzen gssapi-keyexund / oder gssapi-with-micauthentifizieren?

> ssh -v -o PreferredAuthentications=publickey hostxx.domainxx
OpenSSH_5.3p1, OpenSSL 1.0.0-fips 29 Mar 2010
debug1: Reading configuration data /etc/ssh/ssh_config
debug1: Applying options for *
debug1: Connecting to hostxx.domainxx [11.22.33.44] port 22.
debug1: Connection established.
debug1: identity file /home/me/.ssh/identity type -1
debug1: identity file /home/me/.ssh/id_rsa type -1
debug1: identity file /home/me/.ssh/id_dsa type 2
debug1: Remote protocol version 2.0, remote software version OpenSSH_5.3
debug1: match: OpenSSH_5.3 pat OpenSSH*
debug1: Enabling compatibility mode for protocol 2.0
debug1: Local version string SSH-2.0-OpenSSH_5.3
debug1: SSH2_MSG_KEXINIT sent
debug1: SSH2_MSG_KEXINIT received
debug1: kex: server->client aes128-ctr hmac-md5 none
debug1: kex: client->server aes128-ctr hmac-md5 none
debug1: SSH2_MSG_KEX_DH_GEX_REQUEST(1024<1024<8192) sent
debug1: expecting SSH2_MSG_KEX_DH_GEX_GROUP
debug1: SSH2_MSG_KEX_DH_GEX_INIT sent
debug1: expecting SSH2_MSG_KEX_DH_GEX_REPLY
debug1: Host 'hostxx.domainxx' is known and matches the RSA host key.
debug1: Found key in /home/me/.ssh/known_hosts:2
debug1: ssh_rsa_verify: signature correct
debug1: SSH2_MSG_NEWKEYS sent
debug1: expecting SSH2_MSG_NEWKEYS
debug1: SSH2_MSG_NEWKEYS received
debug1: SSH2_MSG_SERVICE_REQUEST sent
debug1: SSH2_MSG_SERVICE_ACCEPT received
debug1: Authentications that can continue: gssapi-keyex,gssapi-with-mic,password
debug1: No more authentication methods to try.
Permission denied (gssapi-keyex,gssapi-with-mic,password).

Könnte sein.

• Können Sie ein Ticket für Ihren Principal auf Ihrem Clientsystem entweder als Teil des Standardanmeldevorgangs oder manuell erhalten ( kinitMIT Kerberos für Windows)?
• Hat der Server einen Kerberos-Principal oder können Sie ihm einen geben? Es sollte von der Form sein host/[email protected].
• Ist die GSSAPIAuthentifizierung auf Ihrem Client aktiviert?
• Weiß Ihr Client anhand des DNS-TXT-Ressourceneintrags oder der lokalen Zuordnung, zu welchem ​​Bereich der Server gehört?

Wenn Sie alle oben genannten Fragen mit "Ja" beantwortet haben, können Sie diese verwenden GSSAPIAuthentication.

• Je nach Konfiguration müssen Sie möglicherweise auch die Delegierung von Anmeldeinformationen aktivieren.

Testschritte:
(Angenommen: domain = example.com; realm = EXAMPLE.COM)

1. kinit [email protected]
   • Idealerweise erledigt dies Ihr Standard-Anmeldeprozess, indem Sie entweder pam_krb5oder pam_sss(mit auth_provider = krb5) in das entsprechende Element einfügen pam stack.
2. kvno host/[email protected]
   • Dies ist ein Debugging-Schritt. sshDies geschieht automatisch, wenn Sie einen gültigen Cache haben und mit einem sprechen, sshdder gssapi-with-micoder unterstützt gssapi-keyex.
3. dig _kerberos.example.com txt sollte zurückkehren "EXAMPLE.COM"
   • Alternativ könnte das Mapping im [domain_realm]Abschnitt von /etc/krb5.confas gespeichert werden .example.com = EXAMPLE.COM, aber die dnsMethode skaliert viel besser.
4. ssh -o GSSAPIAuthentication=yes [email protected]
   • Um sich in einen anderen Benutzernamen als den Ihres Principals auf dem Server einzuloggen, müssen Sie ihn zuordnen, auf dessen Details ich hier nicht eingehen möchte.

Die 4-Schritt-Methode ist korrekt (es gibt auch Kerberos SRV-Einträge in DNS, die noch eleganter sind und in jedem Active Directory vorhanden sind). Ich benutze dies die ganze Zeit und habe mich aus Sicherheits- und Kontrollgründen für die oben genannten Pubkey-Methoden ausgesprochen.

Das heißt, dies gibt nur eine interaktive Anmeldung, obwohl es quasi-interaktiv sein kann, sobald Sie ein Ticket auf Ihrer Workstation haben. Das Kerberos-Ticket verhält sich ähnlich wie der SSH-Agent. Sobald Sie es haben, sind neue Verbindungen instantiv und passwortfrei; allerdings zeitlich begrenzt.

Um eine interaktive Batch-Anmeldung zu erhalten, benötigen Sie eine Keytab-Datei, die im Wesentlichen das Kennwort für ein Kerberos-Konto enthält, ähnlich wie die private Hälfte eines SSH-Schlüssels. Es gelten die entsprechenden Sicherheitsvorkehrungen. zumal das keytab nicht verschlüsselt oder mit einem passwort geschützt ist.

Ich bin ziemlich zurückhaltend dabei, meinen Benutzern ihre Keytabs für ihre persönlichen Konten zur Verfügung zu stellen, benutze jedoch aggressiv Service-Konten mit minimalen Berechtigungen für verschiedene Batch-Jobs, insbesondere wenn es wichtig ist, dass Anmeldeinformationen an das Remote-System delegiert werden, was pubkey einfach kann. ' nicht erreichen.

Keytabs können mit ktutil unter Unix oder KTPASS.EXE unter Windows (letzteres über AD Kerberos-Dienste) erstellt werden. Beachten Sie, dass ktutil in zwei Varianten, Heimdal und MIT, vorhanden ist und sich in der Syntax unterscheidet. Das Lesen der Manpage auf einem relevanten System hilft.