SSH: bad ownership or modes…

Für einen Kunden haben wir auf einem Shared-Hosting-Server eine SSH-Anmeldung per Private/Public Key einrichten wollen. Im Log (/var/log/auth.log) erschien jedoch beim Anmeldeversuch nur die folgende Fehlermeldung:

Authentication refused: bad ownership or modes for directory /[…]

Der Grund dafür: die Webspacebenutzer-Verzeichnisse gehören bei uns nicht den Benutzern selbst, sondern einem speziellen Systembenutzer. Über die Verzeichnisrechte ist so sichergestellt, dass der Apache-Prozess lesend in alle Verzeichnisse schauen darf, während Benutzer nicht in die jeweils fremden Verzeichnisse blicken können.

Die Lösung in diesem Fall: in /etc/ssh/sshd_config die Option “StrictModes” auf “no” setzen. Damit wird der SSH-Daemon angewiesen, die Verzeichnisrechte nicht zu prüfen (konkret: er beschwert sich nicht mehr, wenn jemand anderes als der Benutzer selbst Schreibrechte auf sein eigenes Home-Verzeichnis hat).

Das setzt natürlich voraus, dass das Rechtesystem auf dem Server entsprechend ausgeklügelt ist, und man somit keine anderen Sicherheitslücken öffnet.

Außerdem haben wir bei SharedHosting-Servern die Option “AllowTcpForwarding” auf “No” gesetzt; schließlich soll niemand über diese Server irgendwelche TCP-Tunnel aufbauen (egal in welche Richtung).

3 Bemerkungen zu “SSH: bad ownership or modes…”

  1. Morty

    Aber das bezieht sich doch nur auf das ~/.ssh -Verzeichnis, oder?

  2. Klaus Keppler

    Nein, ~/.ssh gehört natürlich dem “echten” Benutzer.
    Aber “~” gehört einem anderen Benutzer, was sshd aus Sicherheitsgründen anmahnt. Andererseits ist nur so sichergestellt, dass (ohne komplexe ACLs einführen zu müssen) der Webserver in alle Verzeichnisse gucken darf, andere Benutzer aber nicht.
    Und ja - PHP/CGIs etc. werden mit den Rechten der “echten” Benutzer ausgeführt. :)

  3. Philipp Klaus

    > konkret: er beschwert sich nicht mehr, wenn jemand anderes als der Benutzer selbst
    > Schreibrechte auf sein eigenes Home-Verzeichnis hat

    Ja, aber leider ist dann nicht nur die Rechte-Kontrolle von ~ sondern auch die von von .ssh (und .ssh/authorized_keys) ausgeschaltet. Das wiederum halte ich für nicht optimal.

Einen Kommentar schreiben