... 2 Welten treffen aufeinander? Zur Aufgabenstellung: Als Alternative zu den Win-PCs sollen in unserer Firma Linux-PCs angeboten werden. Sie sollen ähnlichen Komfort bieten wie die Win-PCs, insbesondere sollen beim Anmelden einige SMB-Shares gemounted werden. Wir haben das mit dem Modul pam_mount.so gelöst - zumindest für den lokalen Zugang. Versucht sich ein User aber über ssh oder Remote-X anzumelden, passiert gar nix. Es sei denn, es ist root, der erhält immerhin die Fehlermeldung pam_mount: error trying to retrieve authtok from auth code so dass ich davon ausgehe, dass pam_mount hier zumindest startet. Aber gerade root braucht gar nichts zu mounten ;-) Die Authentifizierung läuft gegen einen LDAP-Server, pam_mkhomedir.so erfüllt auch beim remote-login brav seine Pflicht. hier mal die Konfiguration aus /etc/pam.d/sshd: ---schnipp--- #%PAM-1.0 auth required pam_unix2.so # set_secrpc auth required pam_nologin.so auth required pam_env.so #auth optional pam_mkhomedir.so use_first_pass auth required pam_mount.so try_first_pass use_authtok account required pam_unix2.so account required pam_nologin.so password required pam_pwcheck.so password required pam_unix2.so use_first_pass use_authtok session required pam_unix2.so none # trace or debug session required pam_limits.so # Enable the following line to get resmgr support for # ssh sessions (see /usr/share/doc/packages/resmgr/README.SuSE) #session optional pam_resmgr.so fake_ttyname session optional pam_mkhomedir.so use_first_pass session optional pam_mount.so try_first_pass use_authtok ---schnipp--- und hier die /etc/pam.d/login, mit der pam_mount stets funktioniert: ---schnipp--- #%PAM-1.0 auth requisite pam_unix2.so nullok #set_secrpc auth required pam_securetty.so auth required pam_nologin.so #auth required pam_homecheck.so auth required pam_env.so auth required pam_mail.so #auth optional pam_mkhomedir.so use_first_pass auth optional pam_mount.so use_first_pass use_authtok account required pam_unix2.so password required pam_pwcheck.so nullok password required pam_unix2.so nullok use_first_pass use_authtok session required pam_unix2.so none # debug or trace session required pam_limits.so session optional pam_mkhomedir.so use_first_pass session optional pam_mount.so use_first_pass use_authtok ---schnipp--- Wie gesagt, bei lokaler Anmeldung wird korrekt gemounted - was fehlt bei ssh? pam_mount bietet den Vorteil, dass mit dem Passwort aus dem LDAP gearbeitet wird - und das wird auch für die Authentifizierung an den Fileservern benötigt. Ernstgemeinte Hinweise sind willkommen ;-) Freundlicher Gruß \/\/erner Flamme -- Werner Flamme, Abt. WKDV UFZ Umweltforschungszentrum Leipzig-Halle GmbH, Permoserstr. 15, 04318 Leipzig eMail: werner.flamme@ufz.de, Tel.: (0341) 235-2500
Ergänzung: eingesetzt wird SuSE 9.1 mit dem mitgelieferten pam_mount (0.9.9-48) pam_mount funktioniert an der Konsole bzw. bei der lokalen Anmeldung über kdm einwandfrei. Bei der Anmeldung über ssh nicht. Gibt es spezifische Parameter für die /etc/ssh/sshd_config? Ich habe mal einen Hinweis gesehen, "UsePrivilegeSeparation no" zu setzen, das hat aber nichts bewirkt. -- Werner Flamme, Abt. WKDV UFZ Umweltforschungszentrum Leipzig-Halle GmbH, Permoserstr. 15, 04318 Leipzig eMail: werner.flamme@ufz.de, Tel.: (0341) 235-2500
weitere Ergänzung: Auch das Remote-Login via X (X :2 -query testhost) funktioniert. Also hat wohl nur ssh/sshd die Probleme... -- Werner Flamme, Abt. WKDV UFZ Umweltforschungszentrum Leipzig-Halle GmbH, Permoserstr. 15, 04318 Leipzig eMail: werner.flamme@ufz.de, Tel.: (0341) 235-2500
Hallo Werner, hallo Leute, Am Montag, 12. Juli 2004 10:13 schrieb Werner Flamme:
Zur Aufgabenstellung: Als Alternative zu den Win-PCs sollen in unserer Firma Linux-PCs angeboten werden. Sie sollen ähnlichen Komfort bieten wie die Win-PCs, insbesondere sollen beim Anmelden einige SMB-Shares gemounted werden.
Wir haben das mit dem Modul pam_mount.so gelöst - zumindest für den lokalen Zugang. Versucht sich ein User aber über ssh oder Remote-X anzumelden, passiert gar nix. Es sei denn, es ist root, der erhält immerhin die Fehlermeldung pam_mount: error trying to retrieve authtok from auth code
Ich nehme mal an, dass Du bereits nach dieser Fehlermeldung gegoogelt hast ;-) Als Alternative könnte ich mir vorstellen, die Homeverzeichnisse per /etc/profile.local zu mounten. Gruß Christian Boltz -- Und das, was das Administrator-Handbuch (SuSE 9.0) dafür hergibt, liest sich wie ein Backrezept nach folgendem Muster: nehmem sie Mehl, Zucker und Milch und stellen Sie es in den Ofen ;-) [Enrico Kunz in suse-linux]
Christian Boltz schrieb am 14.07.2004 00:02:
Wir haben das mit dem Modul pam_mount.so gelöst - zumindest für den lokalen Zugang. Versucht sich ein User aber über ssh oder Remote-X anzumelden, passiert gar nix. Es sei denn, es ist root, der erhält immerhin die Fehlermeldung pam_mount: error trying to retrieve authtok from auth code
Ich nehme mal an, dass Du bereits nach dieser Fehlermeldung gegoogelt hast ;-)
Als Alternative könnte ich mir vorstellen, die Homeverzeichnisse per /etc/profile.local zu mounten.
Gruß
Christian Boltz
Hallo Christian, ja, gekugelt habe ich ;-). Aber was ich lesen konnte (deutsch, englisch, ein bißchen Französisch) war nicht speziell auf ssh(d) bezogen, es waren allgemeine pam_mount-Probleme. Der einzige, der das gleiche Problem hatte wie ich, hat nie eine Antwort erhalten... /etc/profile.local ist insofern nicht möglich, als dass dann für jedes Share (je nach User 6 oder 7) wieder das Passwort eingegeben (oder irgendwo vorgehalten) werden muss. pam_mount ist die einzige mir bekannte Lösung, die das Login-Passwort auch gleich zum mounten benutzt. Es scheint aber am sshd von SuSE 9.1 zu liegen, der zieht dem pam_mount die session weg, so dass pam_mount bei der Suchen nach dem Token ins Leere greift... Immerhin erhält nach Eintrag von "debug" als Parameter in die session-Zeile von pam_mount auch ein normaler User inzwischen obige Fehlermeldung... SuSE möchte den Support bezahlt haben. Ich darf nur Support für den SLES8 in Anspruch nehmen - und da besteht das Problem nicht 8-/ *Kopfschüttel* \/\/erner -- Werner Flamme, Abt. WKDV UFZ Umweltforschungszentrum Leipzig-Halle GmbH, Permoserstr. 15, 04318 Leipzig eMail: werner.flamme@ufz.de, Tel.: (0341) 235-2500
participants (2)
-
Christian Boltz
-
Werner Flamme