Hallo Liste, ich habe mal meinen ssh-Server neu aufgesetzt, indem ich mir die sourcen von openssh-3.4p1 gezogen und compiliert (und das ganze installiert) habe. Nun, leider geht das ganze nicht mit pam_ldap zusammen, einloggen klappt nur mit pam_unix.so. Laut folgender bug-Meldung http://marc.theaimsgroup.com/?l=openssh-unix-dev&m=102702055609676&w=2 ( LDAP authentication via PAM is refused (and no logs are generated) when UsePrivilegeSeperation is enabled. Disabling PrivilegeSeperation fixes this,though sacrafices the benefits of PrivilegeSeperation. Normal unix authentication through PAM is unaffected - only pam_ldap experiences this problem. Can be duplicated under Debian Linux, Woody release. ) geht's nur ohne PrivilegeSeperation. Das habe ich im sshd.conf auch gemacht, es funzt aber immer noch nicht. Hier mal meine sshd.conf : ---schnipp--- Port 22 Protocol 2,1 ListenAddress 192.168.1.3 ListenAddress 127.0.0.1 HostKey /usr/local/openssh/etc/ssh_host_key HostKey /usr/local/openssh/etc/ssh_host_rsa_key HostKey /usr/local/openssh/etc/ssh_host_dsa_key KeyRegenerationInterval 3600 ServerKeyBits 768 SyslogFacility AUTH LogLevel INFO LoginGraceTime 600 PermitRootLogin no StrictModes yes RSAAuthentication yes PubkeyAuthentication yes #AuthorizedKeysFile .ssh/authorized_keys RhostsAuthentication no IgnoreRhosts yes #RhostsRSAAuthentication no HostbasedAuthentication no IgnoreUserKnownHosts no PasswordAuthentication yes PermitEmptyPasswords no ChallengeResponseAuthentication no #KerberosAuthentication no #KerberosOrLocalPasswd yes #KerberosTicketCleanup yes # Kerberos TGT Passing only works with the AFS kaserver #KerberosTgtPassing no #PAMAuthenticationViaKbdInt yes #X11Forwarding no #X11DisplayOffset 10 #X11UseLocalhost yes PrintMotd yes PrintLastLog yes KeepAlive yes useLogin yes UsePrivilegeSeparation no Compression yes MaxStartups 10 #Banner /some/path VerifyReverseMapping no #Subsystem sftp /usr/local/openssh/libexec/sftp-server ---schnipp--- Ist da irgendwas falsch oder haben die von openssh das einfach total verhunzt ? Gruß Harry
Hallo Harry, kannst Du Dich nur als Root-Benutzer einloggen oder überhaupt nicht? Stell mal in der Konfigurations- datei des SSH-Daemons folgendes ein: PermitRootLogin yes Starte das Ding neu (wie sieht hosts.allow aus?) und probier Dich mal als root einzuloggen. Wenn das geht und als normaler Benutzer nicht, dann könnte der SSH-Keygenerator eventuell SUID installiert sein? Gruß Sebastian
Hi, Sebastian Wolfgarten wrote:
Hallo Harry,
kannst Du Dich nur als Root-Benutzer einloggen oder überhaupt nicht? Stell mal in der Konfigurations- datei des SSH-Daemons folgendes ein: PermitRootLogin yes
Nee, ich logge mich als normaler user ein, root soll das nicht können, wozu gibt's denn su :o)
Starte das Ding neu (wie sieht hosts.allow aus?) und probier Dich mal als root einzuloggen. Wenn das geht und als normaler Benutzer nicht, dann könnte der SSH-Keygenerator eventuell SUID installiert sein?
Geht auch nicht, was könnte das mit dem SSH-Keygenerator-suid denn bewirken ? Ich dachte eher an irgendeine PAM-Direktive dir nicht richtig ist ...
Gruß Sebastian
Gruß Harry
Hallo Harry, root Login war ja nur zu Testzwecken. Wenn ssh-keygen SUID wäre, dann könnten für die lokalen Benutzer keine Schlüssel erzeugt werden und die könnten sich nicht einloggen. Ich hatte exakt dieses Problem auf einer Debian Kiste. Gruß Sebastian
participants (2)
-
Harry Rüter
-
Sebastian Wolfgarten