ssh und Kerberos

hessijens

Well-Known Member
Ich habe ein kleines Problem. Ich habe Kerberos/Heimdal soweit auf FreeBSD 6.2 (RELENG irgendwann vom Oktober - es lauft und updates sind auf einem i686 800 MHZ recht langwierig :rolleyes:) installiert. Soweit funktioniert alles (PAM-KRB5, LDAP, Postgres, Postfix, Cyrus-imap und Samba) mit Heimdal, bis auf SSH, welche kein Ticket akzeptieren will.

Das Systemeigene SSH wird wohl nicht mit Kerberossupport installiert/übersetzt. Es werden zwar die Kerberos Optionen ind sshd_config und ssh_config akzeptiert, doch es funktioniert nicht.

Aus den Ports kann ich Openssh mit Kerberos nicht Kompilieren. Fehler "krb5.h" fehlt, und die kommt wohl vom MIT Kerberos. Da ich aber LDAP als Backend benutzen möchte sollte schon Heimdal (das "Kerberos" was laut Dokumentation der Standard sein sollte) verwenden werden.

Kann man das System (oder besser nur SSH) mit einer Option inkl. Kerberos übersetzen? Alles was ich bisher darüber weiß ist wie man die Welt neu übersetzt :mad: In den Makefiles habe ich bisher aber keine Option für Kerberos/GSSAPI etc finden können.

P.S.: Vielleicht kann mir bei dieser Gelegenheit im Bezug auf nfs und kerberos auch jemand weiterhelfen. Ist nfs v4 mitlerweile bei FreeBSD 7 (mit kerbeors) möglich?
 
Code:
% ldd `which ssh sshd`
/usr/bin/ssh:
        libssh.so.4 => /usr/lib/libssh.so.4 (0x28097000)
        libutil.so.7 => /lib/libutil.so.7 (0x280d0000)
        libz.so.4 => /lib/libz.so.4 (0x280dd000)
        libgssapi.so.8 => /usr/lib/libgssapi.so.8 (0x280ef000)
        libcrypt.so.4 => /lib/libcrypt.so.4 (0x280f6000)
        libcrypto.so.5 => /lib/libcrypto.so.5 (0x2810f000)
        libc.so.7 => /lib/libc.so.7 (0x28267000)
        libkrb5.so.8 => /usr/lib/libkrb5.so.8 (0x2835c000)
        libasn1.so.8 => /usr/lib/libasn1.so.8 (0x28396000)
        libcom_err.so.4 => /usr/lib/libcom_err.so.4 (0x283bf000)
        libmd.so.4 => /lib/libmd.so.4 (0x283c1000)
        libroken.so.9 => /usr/lib/libroken.so.9 (0x283d0000)
/usr/sbin/sshd:
        libssh.so.4 => /usr/lib/libssh.so.4 (0x280aa000)
        libutil.so.7 => /lib/libutil.so.7 (0x280e3000)
        libz.so.4 => /lib/libz.so.4 (0x280f0000)
        libwrap.so.5 => /usr/lib/libwrap.so.5 (0x28102000)
        libpam.so.4 => /usr/lib/libpam.so.4 (0x28109000)
        libbsm.so.2 => /usr/lib/libbsm.so.2 (0x28110000)
        libgssapi.so.8 => /usr/lib/libgssapi.so.8 (0x28124000)
        libkrb5.so.8 => /usr/lib/libkrb5.so.8 (0x2812b000)
        libasn1.so.8 => /usr/lib/libasn1.so.8 (0x28165000)
        libcom_err.so.4 => /usr/lib/libcom_err.so.4 (0x2818e000)
        libroken.so.9 => /usr/lib/libroken.so.9 (0x28190000)
        libcrypto.so.5 => /lib/libcrypto.so.5 (0x2819d000)
        libcrypt.so.4 => /lib/libcrypt.so.4 (0x282f5000)
        libc.so.7 => /lib/libc.so.7 (0x2830e000)
        libmd.so.4 => /lib/libmd.so.4 (0x28403000)

Ist ein 7.x aber ich denke auch ssh/sshd auf 6.x wird default mit Kerberos gelinkt. Welche Debug-Ausgaben kriegst du denn von sshd?
 
Hier noch ein paar Infos

Auch bei mir ist sshd gegen kerberos gelinkt:
Code:
ldd `which ssh sshd`
/usr/bin/ssh:
        libssh.so.3 => /usr/lib/libssh.so.3 (0x80064c000)
        libmd.so.3 => /lib/libmd.so.3 (0x800789000)
        libutil.so.5 => /lib/libutil.so.5 (0x800895000)
        libz.so.3 => /lib/libz.so.3 (0x8009a2000)
        libgssapi.so.8 => /usr/lib/libgssapi.so.8 (0x800ab6000)
        libkrb5.so.8 => /usr/lib/libkrb5.so.8 (0x800bc5000)
        libasn1.so.8 => /usr/lib/libasn1.so.8 (0x800d09000)
        libcom_err.so.3 => /usr/lib/libcom_err.so.3 (0x800e32000)
        libroken.so.8 => /usr/lib/libroken.so.8 (0x800f34000)
        libcrypt.so.3 => /lib/libcrypt.so.3 (0x801042000)
        libcrypto.so.4 => /lib/libcrypto.so.4 (0x80115b000)
        libc.so.6 => /lib/libc.so.6 (0x8013a2000)
/usr/sbin/sshd:
        libssh.so.3 => /usr/lib/libssh.so.3 (0x800660000)
        libutil.so.5 => /lib/libutil.so.5 (0x80079d000)
        libz.so.3 => /lib/libz.so.3 (0x8008aa000)
        libwrap.so.4 => /usr/lib/libwrap.so.4 (0x8009be000)
        libpam.so.3 => /usr/lib/libpam.so.3 (0x800ac7000)
        libbsm.so.1 => /usr/lib/libbsm.so.1 (0x800bcf000)
        libgssapi.so.8 => /usr/lib/libgssapi.so.8 (0x800ce0000)
        libkrb5.so.8 => /usr/lib/libkrb5.so.8 (0x800def000)
        libasn1.so.8 => /usr/lib/libasn1.so.8 (0x800f33000)
        libcom_err.so.3 => /usr/lib/libcom_err.so.3 (0x80105c000)
        libroken.so.8 => /usr/lib/libroken.so.8 (0x80115e000)
        libcrypto.so.4 => /lib/libcrypto.so.4 (0x80126c000)
        libcrypt.so.3 => /lib/libcrypt.so.3 (0x8014b3000)
        libc.so.6 => /lib/libc.so.6 (0x8015cc000)
        libmd.so.3 => /lib/libmd.so.3 (0x8017dd000)

In der sshd_config steht folgendes:

Code:
#Port 22
ListenAddress 192.168.102.3
ListenAddress 192.168.103.105
PermitRootLogin yes
ChallengeResponseAuthentication yes

# Kerberos options
KerberosAuthentication yes
KerberosOrLocalPasswd yes
KerberosTicketCleanup yes
#KerberosGetAFSToken no

# GSSAPI options
GSSAPIAuthentication yes
GSSAPICleanupCredentials yes

ssh_config zeigt auf dem Client:

Code:
Host *
GSSAPIAuthentication yes
GSSAPIDelegateCredentials yes

damit funktioniert es unter Linux, nicht jedoch unter FreeBSD:mad:. Wenn ich Login INFO aktiviere erhalte ich folgende Meldungen bei der Anmeldung:
Code:
Dec 21 08:38:05 server sshd[1635]: reverse mapping checking getaddrinfo for client.mylink-net.de [192.168.102.3] failed - POSSIBLE BREAK-IN ATTEMPT!
Dec 21 08:38:17 server sshd[1635]: Accepted keyboard-interactive/pam for root fro
m 192.168.102.3 port 64634 ssh2

Die Anmeldung schlägt fehlt, ich darf dann ein Passwort eingeben, dass funktioniert dann. Ohne wäre naturlich besser.:rolleyes:
 
Gelöst

Kerberos ist in PAM zwar aktiviert, aber ich habe es bisher nicht verwendet, da ja die Auflösung nur mit Kerberos gehens sollte. Wenn ich aber in sshd_config folgendes hinzufüge:

Code:
UsePAM yes 
PasswordAuthentication no

Dann geht's, wenn wie richtig bemerkt kerberos in /etc/pam.d/sshd aktiviert ist. Also nochmal Danke für den Tipp 0815Chaot:)
 
Du mußtest "UsePAM yes" explizit hinzufügen? Laut Manpage sollte das eigentlich der Default sein. Zusätzlich ist natürlich auch noch die Reihenfolge der Einträge in /etc/pam.d/sshd wichtig: pam_krb5.so sollte vor pam_unix.so stehen, damit zuerst ein eventuell vorhandenes Ticket verwendet wird und erst danach, falls nötig, ein Paßwort angefordert wird.
 
Noch eine Schuldige Antwort

Nachdem ich über die Feiertage etwas Zeit zum Proben hatte hier noch meine schuldige Antworten:
Du mußtest "UsePAM yes" explizit hinzufügen? Laut Manpage sollte das eigentlich der Default sein. Zusätzlich ist natürlich auch noch die Reihenfolge der Einträge in /etc/pam.d/sshd wichtig: pam_krb5.so sollte vor pam_unix.so stehen, damit zuerst ein eventuell vorhandenes Ticket verwendet wird und erst danach, falls nötig, ein Paßwort angefordert wird.

1. Ja ich muss "UsePAM=yes" hinzufügen, was aber an meiner Konfiguration des Systems liegen liegen kann. Jedenfalls ist es per default nicht auskommanidert und ich darf es auch nicht auskommandieren.

2. Habe ich mitlerweile festgestellt, dass "ssh server" nicht geht, wohl aber "ssh server.domain.org", obwohl in resolv.conf die Domaine angegeben ist.

3. Die Einträge für pam waren per "default" schon richtig eingetragen. Da musste ich nichts ändern, was nätürlich nicht so bleiben muss.
 
auskommanidert [...] auskommandieren
:confused:

2. Habe ich mitlerweile festgestellt, dass "ssh server" nicht geht, wohl aber "ssh server.domain.org", obwohl in resolv.conf die Domaine angegeben ist.
Liefert host server die IP-Adresse zurück? Liefert host $IPADRESSE dann auch wieder den FQDN zurück? Ansonsten probiere ssh -v server. Bereits innerhalb der ersten Zeilen der Debug-Ausgabe sollte der FQDN auftauchen ("debug1: Connecting to server.domain.org ...").

Ansonsten zeig mal die /etc/resolv.conf des Clients und des Servers. Funktioniert die Namensauflösung im Netzwerk generell?

3. Die Einträge für pam waren per "default" schon richtig eingetragen.
Korrekt. Ich wollte nur sichergehen, daß du dort keine Änderungen vorgenommen hast, die dir dann hinterher im Weg stehen könnten.
 
Zurück
Oben