Problem mit SSH!!

[Gast]

Hi!
Ich betreibe Debian auf einem kleinen Homeserver (Linksys NSLU2). Dieser besitzt keinerlei Ausgabegeräte und somit ist die Konsole per SSH der einzige Zugang. Dies hat bisher auch immer einwandfrei funktioniert, d.h. ich konnte mich als root, aber auch als normaler User anmelden. Seit heut kann ich mich jedoch nur noch als root anmelden, wenn ich es als User versuche, schließt sich das Fenster nach der Paßworteinagabe, d.h. die Session wird beendet. Im Logfile /var/log/auth.log finden sich die Einträge:

sshd[2385]: session opened for user xxx by (uid=0)
PAM-env[2385]: Unable to open config file: Permission denied

Daraufhin habe ich mir der Zugriffsrechte der Datei /etc/security/pam_env.conf angesehen, diese stehen auf 644. Also alles in Ordung. Auch eine Änderung der Rechte auf 777 und ein Neustart des Systems brachten keine Besserung. Es ist auch anzmerken das ich nichts verändert habe! Woher kann das Problem kommen?

Mfg,
imk82

[Gast]

Hm.Probelm gelöst, auch wenn ich es nicht so richtig verstehe. Ich habe mir das Rootverzeichnis mit Samba freigegeben, damit ich leichter Konfigurationsdateien ansehen kann etc. Habe also das root in nen Verzeichnis mit bind reingemountet und dann das Verzeichnis freigegeben. Die Rechte des Verzeichnisses halt möglichst restrikitv. Das hat ihm nicht geschmeckt. Aber eigentlich verändert das doch am Root Verzeichnis nichts, oder täusche ich mich da? Es muss jeder mindestens Lese- und Ausführrechte für das genannte Verzeichnis haben, sonst geht das einloggen nicht..

Mfg,
imk82

[Sephiroth]

6 Jahre alt und das gleiche Resultat

http://www.linuxarkivet.se/mlists/debian-security/0206/msg00499.html
It seems that this is related to the PAM breakage noted in the recent
versions with priv sep enabled. My guess would be that since that part
of the code now runs as the sshd user instead of as root, it's denied
permission to read your pam_env config file
(/etc/security/pam_env.conf). This is only a guess; some more testing
may be in order (it's 644 on my system, so it should be readable by
anyone...).

This is just a fairly random guess; I don't really know much about the
way the new ssh auth section works, or how and how much pam is broken --
just been hearing it from a lot of people that it is.

Du warst vermutlich wirklich zu restriktiv mit der Rechtevergabe. Es gibt nunmal Dateien, die von allen gelesen werden können müssen (z.B. /etc/passwd und /etc/security/). Wenn in einem übergeordneten Verzeichnis die Leserechte fehlten, dann spielt es auch keine Rolle, dass sie im Unterverzeichnis vorhanden sind.

[noid]

Afaik ist mount-bind ein hardlink auf die gleiche Datei, damit hättest du die Rechte für das Verz geändert, weil es ja in wirklichkeit die gleiche "Datei" ist.

[Gast]

Hm, da habt ihr ja sicher Recht, aber so richtig klar ist es mir trotzdem nicht. Das Root-Verzeichnis als solches ist ja nach wie vor normal gemountet, oder? Warum sollte denn ein Programm dann den Umweg zum Root über das Verzeichnis in welches ich es mit bind eingebunden habe nehmen? Das ist doch irgendwie unlogisch!

Mfg,
imk82

[noid]

Hm, da habt ihr ja sicher Recht, aber so richtig klar ist es mir trotzdem nicht. Das Root-Verzeichnis als solches ist ja nach wie vor normal gemountet, oder? Warum sollte denn ein Programm dann den Umweg zum Root über das Verzeichnis in welches ich es mit bind eingebunden habe nehmen? Das ist doch irgendwie unlogisch!

Mfg,
imk82

tut es nicht, sondern du hast einfach die Rechte für ein und die gleiche Datei verändert ohne es zu wollen. Außerdem ist / für samba freigeben nicht so pralle.

[Gast]

Hi,

ok, also root per Samba freizugeben is vielleicht wirklich nicht so die beste Idee.Aber zumindest meine logs wollte ich mir dann doch freigeben. Diesmal habe ich es allerding mit symbolischen Links versucht. Hat auch einwandfrei geklappt..bis zum nächsten Neustart. Danach traten zwei Probleme auf.

Zum einen startet mein Web-Server (lighttpd) nicht mehr bzw. meckert das "Permission denied" auf /var/log/lighttpd/access.log wäre. Nach den im Einganspost geschilderten Erfahrungen war ich aber sehr vorsichtig mit den Rechten und habe diesmal definitiv keinerlei Rechte verändert und, wie bereits erwähnt, auch nur symbolische Links verwendet.

Das zweite Problem betrifft die Konsole. Im Normalfall stand da in der Eingabezeile bspw. immer "UserX@Debian:", jetz steht da "UserX@none:". Hängt das eventuell auch mit dem Webserver zusammen? Ich bin mir aber eigentlich sicher, dass @debian da schon stand bevor ich den WebServer überhaupt aufgesetzt hatte, weswegen ich von einem eigenständigen Problem ausgehe.

Probiert habe ich bisher die betroffenen Dateien und übergeordneten Verzeichnisse auf 777 zu setzen. Weiterhin habe ich alle symbolischen Links wieder entfernt. Zu erwähnen ist vielleich noch, dass ich zwischen meinen USB-Stick(hier ist das root Dateisystem drauf) und die NSLU2 einen USB-Hub gesteckt habe um einen zusätzlichen Drucker anzuschließen. Dies habe ich testweise aber auch schon wieder rückgängig gemacht, brachte keine Besserung.

Ich hoffe jemand weiß Rat!

Mfg,
imk82

[Gast]

Hallo!
Nur um diesen Thread mal abzurunden:
Das letztgenannte Problem war mit hoher Wahrscheinlichkeit darauf zurückzuführen, dass das Betriebssystem auf einem USB-Stick installiert war. Das ext3 Dateisystem darauf war regelmäßig Datensalat. Mir einer Notebookplatte im USB-Gehäuse ist das Probelm verschwunden.

Danke für die Hilfe!

MfG,
imk82