Univention Bugzilla – Bug 18776
OpenSSH ChallengeResponseAuthentication und PasswordAuthentication
Last modified: 2010-09-08 13:00:53 CEST
Damit auch die SSH-Anmeldungen durch den PAM-Stack laufen, müsste die SSH Passswort Authentifizierung abgeschaltet werden. Damit prüft OpenSSH das Passwort nicht mehr selbst, sondern gibtdie Prüfung an den PAM-Stack ab. Bei Updates sollte das alte Verhalten beibehalten werden: ChallengeResponseAuthentication no PasswordAuthentication yes Bei Neuinstallationen sollte es auf folgendes geändert werden: ChallengeResponseAuthentication yes PasswordAuthentication no +++ This bug was initially created as a clone of Bug #18750 +++ Pro UCS-System sollte konfiguriert werden können, nach wie viel erfolglosen Anmeldeversuchen der Benutzer gesperrt wird.
fixed
Update: alte Einstellungen +PW, -CR bleiben erhalten Neuinstallation: Einstellung ist -PW, +CR PasswordAuthentication funktioniert in beiden Varianten. ChallengeResponseAuthentication funktioniert zusätzlich nur bei der Neuinstallation. Beide Installationen benutzen PAM aus /etc/pam.d/sshd: (Siehe Bug #18884) 'account require pam_deny.so' führt zu einer Verweigerung der Logins. 'session require pam_deny.so' führt zu einer Verweigerung der Logins, zeigt aber die Banner-Meldung von sshd noch an. 'auth' ist ohne Wirkung (das ist und soll so ein) univention-ssh funktioniert auch in beiden Varianten. # ucr set sshd/passwordauthentication=no sshd/challengeresponse=no ; /etc/init.d/ssh restart $ ssh -S none -o PubkeyAuthentication=no -o GSSAPIAuthentication=no HOST < Permission denied (publickey,gssapi-keyex,gssapi-with-mic). # ucr set sshd/passwordauthentication=yes sshd/challengeresponse=no ; /etc/init.d/ssh restart < root@HOST's password: # ucr set sshd/passwordauthentication=no sshd/challengeresponse=yes ; /etc/init.d/ssh restart < Password: # ucr set sshd/passwordauthentication=yes sshd/challengeresponse=yes ; /etc/init.d/ssh restart < Password: < root@HOST's password: Die Beschreibung der UCR-Variablen enthält noch Rechtschreibfehler: # LANG=de ucr search sshd/ | grep -B 1 --color albe sshd/challengeresponse: yes Enalbe/Disable challenge response authentication -- sshd/passwordauthentication: yes Enalbe/Disable password authentication via sshd directly Fehler im ChangeLog: Das Skript heißt nur /etc/init.d/ssh (ohne 'd')
(In reply to comment #2) > Die Beschreibung der UCR-Variablen enthält noch Rechtschreibfehler: > # LANG=de ucr search sshd/ | grep -B 1 --color albe > sshd/challengeresponse: yes > Enalbe/Disable challenge response authentication > -- > sshd/passwordauthentication: yes > Enalbe/Disable password authentication via sshd directly fixed > Fehler im ChangeLog: Das Skript heißt nur /etc/init.d/ssh (ohne 'd') fixed
Die angemerkten Rechtschreibfehler wurden behoben. Getestet auf 2.3->2.4_i386, 2.3->2.4_amd64, 2.4_i386.
hmh, bei mir war sshd/passwordauthentication nach einem Update 2.3 -> 2.4 nicht gesetzt, dann startet der ssh-Daemon nicht mehr
Das oder ein ähnliches Problem ist heute auch beim Updaten von xen1 aufgetreten, allerdings kommen hier noch mehrere andere Faktoren mit in Spiel: - /root gehörte nicht mehr 0:0 - das Update war nicht durchgelaufen und musste per 'dpkg --configure --pending' wieder angestoßen werden. Danach tat das Login wieder. Interessant waren allerdings folgende Zeilen in /var/log/auth.log: Jul 16 09:54:34 xen1 sshd[6442]: pam_securetty(sshd:auth): access denied: tty 'ssh' is not secure ! Das Problem war zunächst nicht aufgefallen, da normalerweise mein PublicKey verwendet wird. Temporär kann man das mit 'ssh -o PubkeyAuthentication=no xen1' umgehen.
(In reply to comment #5) > hmh, bei mir war sshd/passwordauthentication nach einem Update 2.3 -> 2.4 nicht > gesetzt, dann startet der ssh-Daemon nicht mehr Das war ein Update einer 2.4er Vorab-Version.
Im Thin Client ssh-init-Skript habe ich die Variable jetzt auch gesetzt.
Neuinstallation und Upgardes von 2.3-2 auf 2.4-0 funktionieren auf i386 und amd64; In der Thin-Client-Umgebung wird immer CR=yes und PA=no gesetzt, sofern nicht vorher was anderes bereits gesetzt war. Bei einem erneuten Test mit CR=no, PA=yes wurden auch die Einträge für "auth" in /etc/pam.d/sshd genutzt; ein 'auth required pam_deny.so' am Anfang hat jeden Loginversuch verhindert; von daher ist mir hier jetzt nicht ganz klar, warum das bei meinen vorherigen Tests nicht funktioniert hat. ChangeLog-Eintrag ist vorhanden und beschriebenes Verfahren funktioniert. Es fehlt noch einiges an Dokumentation, vorallem die Querabhängigkeiten zwischen den verschiedenen Authentifizierungs- und Account-Verifizierungsverfahren; das passiert aber in Bug #18836.
UCS 2.4 wurde veröffentlicht. Sollte der hier beschriebene Bug mit einer neueren Version von UCS erneut auftreten, so sollte der Bug dupliziert werden: "Clone This Bug".