Ich befinde mich in einer Situation, in der ich versuche, die GSSAPI-Weiterleitung (Kerberos) zu nutzen, um eine Verbindung zu einem anderen Linux-Server herzustellen, der ebenfalls mit einem Windows AD verbunden ist und SSSD verwendet.
Die Linux-Rechner werden der Domäne unter einem anderen Rechnernamen als dem tatsächlichen FQDN des Servers beigetreten. Wenn ich mich mit meinen Domänenanmeldeinformationen beim ersten Rechner anmelde, ist PAM erfolgreich und ich erhalte ein gültiges Token. Es wird mit angezeigt klist. Aber selbst nachdem ich GSSAPI- und Kerberos-Anmeldungen über SSH auf einem anderen Linux-Host aktiviert habe, der ebenfalls der Domäne beigetreten ist, erhalte ich immer noch den Clientfehler „Server nicht in der Kerberos-Datenbank gefunden“ und es wird auf die Kennwortauthentifizierung zurückgegriffen. Ich werde weitermachen, -Kum die Kerberos-Token-Weiterleitung zu aktivieren.
Wenn ich mich recht erinnere, liegt dies möglicherweise an einem SPN-Problem in AD (in diesem Fall dem Kerberos-Server), bei dem die Linux-Maschine mit einem anderen Maschinennamen verbunden ist als dem FQDN der tatsächlichen Maschine, zu der ich eine Verbindung herstelle (oder von der ich mich verbinde?), aber ich bin nicht sicher und brauche Hilfe, die mich in die richtige Richtung weist.
Antwort1
Sie können den Ihrem Domänencontroller bekannten Prinzipalnamen verwenden, indem Sie die GSSAPIServerIdentityOption an Ihren sshClient übergeben:
-oGSSAPIServerIdentity=host.domain.com
Aus der ssh_configManpage:
GSSAPIServerIdentity Wenn gesetzt, gibt dies die GSSAPI-Serveridentität an, die ssh bei der Verbindung mit dem Server erwarten soll. Der Standardwert ist nicht gesetzt, was bedeutet, dass die erwartete GSSAPI-Serveridentität aus dem Zielhostnamen bestimmt wird.