PDA

Archiv verlassen und diese Seite im Standarddesign anzeigen : Probleme mit GSSAPI und OpenSSH



aeichner
06.11.07, 11:16
Hallo!

Jetzt muß ich hier auch mal um Rat fragen, vielleicht kennt ja jemand einen Trick zur Lösung meines Problems, welches denn wie folgt lautet:
Wir haben hier eine AD-Domäne mit Win-2K3 als Domänen-Controller. Hab einen Redhat Enterprise Linux 4-Rechner problemlos per "net ads join" anbinden können. Nun sollte auch eine Verbindung via SSH ohne Paßwort mittels GSS-API möglich sein. Von einer anderen Linux-Kiste funktioniert alles tadellos. Ein Kerberos-Ticket vom Windows Domänen-Controller holen und per "ssh -o PreferredAuthentications=gssapi-with-mic" auf den Server verbinden.
Nun soll das aber von Windoofz aus auch gehen und da wir hier schon PuTTY einsetzen, habe ich mich der gepatchten Versionen bedient, um mit GSSAPI arbeiten zu können - inzwischen hab ich alle Versionen von der WebSeite ausführlich getestet, aber keine funzt.
Der SSH-Server meldet entweder "No client credentials" oder bleibt nach "Received some client credentials" einfach stehen und wartet auf... keine Ahnung auf was. Die Schlüssel verwenden als enc-type arcfour-hmac-md5.

PuTTY ist schön, aber nicht Pflicht - wenn also jemand einen funktionierenden Windows-Client kennt, auch gut. Ansonsten kennt vielleicht jemand eine Lösung oder hat einen Tipp, wie ich z.B. Debug-Meldungen der GSSAPI bekomme. Hab auch keine Ahnung, wer schuld ist. Dachte es liegt vielleicht an der alten Redhat. Also hab ich die Debian-SSH-Binaries + notwendige Libs auf die Kiste geschoben, aber der Effekt ist exakt der gleiche.

aeichner
06.11.07, 14:46
Also das Problem ist gelöst und lag ganz simpel daran, daß Windoofz den Usernamen groß schreibt. Und weil Kerberos auf Groß-/Kleinschreibung Acht gibt, ist eben nobody@EXAMPLE.COM ungleich NOBODY@EXAMPLE.COM - Hat mich nach mehreren erfolglosen Versuchen heute nochmals mehrere Stunden und einen ellenlangen strace gekostet, das heraus zu finden :ugly:
Wie gesagt, die Schwierigkeit bestand darin, daß ich keine klare Aussage wie "principal NOBODY@EXAMPLE.COM not permitted" bekommen habe, sondern der SSH einfach 'stehen' blieb, während PuTTY gleichsam hängen blieb nach 'Using user name: "nobody" ' (ja - PuTTY schrieb den Usernamen klein, weswegen ich keinerlei Verdacht schöpfte).
Problem erkannt, ganz leicht gebannt: beide Schreibweisen in die .k5login und gut :D

Wenn ich schon mal dabei bin: Hab die Keytabs für die Service-Principals auf dem Domänen-Controller erzeugen lassen, dabei kam immer der Service immer in Großschreibweise, egal wie es auf der Kommandozeile angegeben wurde, also z.B. LDAP/mein-ldap-server.example.com@EXAMPLE.COM. Das war ganz ganz schlecht, weil die *nix-Programme wie in diesem Falle ldapsearch den Service klein geschrieben anfordern - schon passen die Principalnamen nicht mehr zusammen. Hab in meiner Not einfach den Keytab-Eintrag per Hex-Editor geändert und zusätzlich eingebaut...

Ich hoffe, daß diese Infos vielleicht jemandem helfen können. In jedem Fall kann ich die Verzweiflung verstehen. In den letzten Wochen war mein häufigster Satz "Das muß doch gehen..." Aber jetzt ist meine Welt (vorerst) wieder in Ordnung :cool: