- Most Recent |
24 hours |
7 days |
30 days |
365 days |
Posted by 
thomasg 5 months ago 
Wo die Leistung von Samba versagt, NFS mangels passabler Rechtevergabe nicht in Frage kommt und der FTP zu unflexibel ist hilft nur Eines: SSH (SCP/SFTP).
Problem:
Normalerweise sieht ein User der per SSH angemeldet ist den kompletten Verzeichnisbaum, kann also bei falschen Einstellungen Dateien einsehen die ihn nichts angehen.
In der Vergangenheit gab es einige Workarounds um das Problem ohne ein kompeltte Review aller Dateirechte zu lösen, wie z.B. eine Spezialshell wie scponlyc die den User beim Login in ein Chroot verfrachtet.
Das ist allerdings recht umständlich und verlangt eine eigene Verzeichnisstruktur inkl. aller benötigten Binaries für jeden einzelnen User
Lösung:
Die OpenSSH-Suite bringt ab Version 4.9 Chroot-Support mit.
Mit nur wenigen Zeilen in der SSHD-Config lassen sich damit Verzeichnisse für den Fileserver definieren und bequem Rechte dafür zuvergeben.
# das interne sftp-subsystem muss aktiviert werden, damit von ssh kein anderer sftp-server genutzt wird
Subsystem sftp internal-sftp
# dann werden die Freigaben und deren Rechte festgelegt, zum Beispiel so:
Match Group Testgroup1
ChrootDirectory /var/files1/
ForceCommand internal-sftp
AllowTCPForwarding no
Match User Testuser1
ChrootDirectory /var/files2/
ForceCommand internal-sftp
AllowTCPForwarding no
Die entsprechenden User und Groups müssen auf dem System vorhanden sein.
Loggt sich nun ein User per SSH ein und es kommt zu einem "Match", also der Übereinstimming des Users bzw. einer der Gruppen des Users mit einem der Einträge in der Config, wird der User automatisch in's angegebene Verzeichnis chrootet.
Wenn sich also Testuser1 anmeldet wird er nach /var/files2 chrooted und sieht dieses Verzeichnis somit als sein Rootdirectory. Alles darunter kann er nicht sehen.
Testuser2 befindet sich unter anderem in Testgroup1 - beim Login wird er daher nach /var/files1 chrooted.
Befindet sich Testuser1 hingegen in Testgroup1 kommt es schon beim ersten Match zum Treffer und er wird nach /var/files1 chrooted, kann also /var/files2 nicht sehen. Deswegen muss bei Vergabe der Gruppen Vorsicht walten.
Anwendung:
Wenn die Freigaben also eingerichtet sind darf man sich entscheiden wie man darauf zugreifen möchte.
Zum einen geht das natürlich per scp oder sftp - auch von Windowssystemen aus (z.B. WinSCP).
Weitaus praktischer ist es allerdings, dass man die Freigabe ebenso wie ein CIFS-/SMB- oder NFS-Share mounten kann.
Dazu existiert unter Linux das virtuelle Dateisystem sshfs, das per FUSE (Filesystem in USErspace) zur Verfügung steht.
Da automatisch chrooted wird braucht man beim sshfs-mount keinen vollen Pfad angeben, man kann direkt das Rootdir mounten, z.B. mit:
sshfs username1@hostname:/ /mnt/fileserver
Das funktioniert normalerweise nur als root und auch nur root kann dann auf die gemountete Freigabe zugreifen. Dieses Problem lässt sich aber auch lösen indem man beim Mount eine Option mit angibt:
sshfs username1@hostname:/ /mnt/fileserver -o allow_other
Damit können dann auch andere Benutzer am System die Freigabe einsehen.
Außerdem existiert natürlich die Möglichkeit das Mounten per /etc/fstab automatisch, oder von einem User, etc. zu erledigen. Dazu ist ein Eintrag in dieser Art erforderlich:
sshfs#username1@hostname:/ /mnt/fileserver fuse noauto,allow_other,users 0 0
Damit können nun auch normale User, zumindest sofern sie sich in den entsprechenden Gruppen befinden, die Freigabe mounten.
Für BSD-Systeme stehen teils ähnliche Implementierungen dieses virtuellen Dateisystems zur Verfügung, Windowsuser können auf kommerzielle Software zurückgreifen.
Don't forget to subscribe to our
RSS/Atom feed to get the latest tricks.
