SSH-authenticatie met gssapi-keyex of gssapi-with-mic (publickey niet toegestaan)

Misschien.

• Kunt u een ticket voor uw opdrachtgever op uw cliëntsysteem, hetzij als onderdeel van het standaard aanmeldingsproces, hetzij handmatig (kinit, MIT Kerberos voor Windows)?
• Heeft de server een Kerberos-principal of kunt u deze er een geven? Het moet de vorm hebben host/[email protected].
• Is GSSAPI authenticatie ingeschakeld op uw client?
• Weet uw klant tot welk domein de server behoort, hetzij door DNS TXT-bronrecord of door lokale mapping?

Als u “ja” zei tegen alle van het bovenstaande, dan gefeliciteerd, je kunt GSSAPIAuthentication gebruiken.

• Je mag moet ook het delegeren van inloggegevens inschakelen, afhankelijk van uw instellingen.

Teststappen:
(Aannemende: domein = example.com; realm = EXAMPLE.COM)

1. kinit [email protected]
   • Idealiter wordt dit afgehandeld door uw standaard inlogproces door pam_krb5 of pam_sss (met auth_provider = krb5) in de juiste pam stack.
2. kvno host/[email protected]
   • Dit is een foutopsporingsstap. ssh doet dit automatisch als je een geldige cache hebt en je praat met een sshd die gssapi-with-mic of gssapi-keyex.
3. dig _kerberos.example.com txt moet "EXAMPLE.COM"
   • Als alternatief kan de mapping worden opgeslagen in het [domain_realm] -gedeelte van /etc/krb5.conf als .example.com = EXAMPLE.COM, maar de dns methode schaalt veel beter.
4. ssh -o GSSAPIAuthentication=yes [email protected]
   • Om in te loggen op een andere gebruikersnaam dan die van uw opdrachtgever op de server, moet u de details in kaart brengen waar ik hier niet op inga.

Reacties

• Hallo. Ik heb je een tijdje geleden +1 gegeven, maar in feite doe ik dat niet weet hoe u uw vier punten moet controleren. (ik ben geen beheerder, maar een ontwikkelaar). Kunt u een opdrachtregel opgeven om de SSH-verbinding te controleren met g gssapiauthentication? Misschien kan ik ook gssapiauthentication op mijn Linux-machine gebruiken. (moet ik daarvoor kinit gebruiken?) Cheers;)

De 4-stappenmethode is correct (er zijn ook Kerberos SRV-records in DNS die nog eleganter zijn en in elke Active Directory aanwezig zijn). Ik gebruik dit de hele tijd, en heb deze bovenstaande pubkey-methoden bepleit, voornamelijk vanwege veiligheids- en controlegerelateerde redenen.

Dat gezegd hebbende, geeft dit alleen interactieve login, hoewel het quasi-interactief kan zijn als je eenmaal een ticket op je werkstation hebt gekregen.Het Kerberos-ticket werkt net als de SSH-agent; als je het eenmaal hebt, zijn nieuwe verbindingen onmiddellijk en zonder wachtwoorden; zij het met een tijdslimiet.

Om interactieve batch-login te krijgen, heb je een keytab-bestand nodig, een bestand dat in wezen het wachtwoord voor een Kerberos-account bevat, net zoals de privé-helft van een SSH-sleutel. De desbetreffende veiligheidsmaatregelen zijn van toepassing; vooral omdat de keytab niet is gecodeerd of beveiligd met een wachtwoord.

Ik ben nogal terughoudend om mijn gebruikers hun keytabs voor hun persoonlijke accounts te geven, maar gebruik agressief serviceaccounts met minimale machtigingen voor verschillende batchtaken, vooral wanneer het van cruciaal belang is dat inloggegevens worden gedelegeerd naar de externe systeem, iets dat pubkey eenvoudigweg niet kan bereiken.

Keytabs kunnen worden gemaakt met ktutil op Unix of KTPASS.EXE op Windows (de laatste van AD Kerberos-services). Houd er rekening mee dat ktutil in twee smaken bestaat, Heimdal en MIT, en dat hun syntaxis verschilt. Het helpt om de manpage op een relevant systeem te lezen.