Frage, sftp und Schreibrechte im Homedir

D

Domi

Member
Hallo Leute, ich habe mal eine kleine Frage. Auf meinem Linux Server ist ein SSH eingerichtet, damit ich via Putty darauf zugreifen kann. Nun haben wir mit einem Versicherer gesprochen, ob DIE uns Datensätze als CSV (oder was auch immer) zusenden würden.

Ja, machen sie und könnte auch automatisiert erfolgen. Soweit so gut, in der sshd_confif habe ich auch alles eingetragen damit die Verbindung funktioniert. Wenn ich mich via FTP Client (FlashFXP) am sFTP Server verbinde bin ich auch im Homedir eingesperrt, kann aber darin nicht schreiben. Ich hatte für den Versicherer ein Unterverzeichnis "upload" erstellt worin man schreiben kann (klappte auch alles) aber das Skript des Versicherers kann nicht in Unterverzeichnisse schreiben / gehen.

Ich habe nun vor meinem Urlaub im Internet gesucht wie doof und nur die Informationen gefunden das man ein Unterverzeichnis für einen Upload einrichten solle, aber keine Option gefunden wie man im Homedir direkt schreiben kann. Wenn ich dem User (Owner oder auch Group) write Rechte verpasse, kann ich mich allerdings nicht mehr mit dem sFTP verbinden, da wird dann gemeckert weil die Rechte falsch sind.

Gibt es dafür einen Trick, eine Lösung oder Ansatz den Ihr mir empfehlen könnt? :)

Gruß, Domi
 
Hallo Domi,

ich würde an deiner Stelle den user deines Versicherers einfach ein anderes Standardverzeichnis verpassen/chrooten.
Wenn er sich connected ist er dann direkt in deinem upload-verzeichnis und muss nicht selbstständig wechseln.
Ist meiner Meinung nach eine einfache Lösung wenn ich dich richtig verstanden habe.
Ich glaube hier wird das ganze für Debian beschrieben.
 
Zeig bitte die vollständige sshd_config (ohne Kommentare) und ein `ls -l` des Home des betroffenen Users.
 
Moin moin, ich habe habe die Kommentare mal aus meiner sshd_config entfernt, und hier ist schon mal die Config...
Code: 
Port 22

Protocol 2

HostKey /etc/ssh/ssh_host_rsa_key
HostKey /etc/ssh/ssh_host_dsa_key
HostKey /etc/ssh/ssh_host_ecdsa_key
HostKey /etc/ssh/ssh_host_ed25519_key

UsePrivilegeSeparation yes

KeyRegenerationInterval 3600
ServerKeyBits 1024

SyslogFacility AUTH
LogLevel INFO

LoginGraceTime 120
PermitRootLogin no
StrictModes yes

RSAAuthentication yes
PubkeyAuthentication yes

IgnoreRhosts yes

RhostsRSAAuthentication no

HostbasedAuthentication no

PermitEmptyPasswords no

ChallengeResponseAuthentication no

X11Forwarding yes
X11DisplayOffset 10
PrintMotd no
PrintLastLog yes
TCPKeepAlive yes

AcceptEnv LANG LC_*

Subsystem sftp internal-sftp

UsePAM yes

Match address 10.30.0.0/24
 PermitRootLogin yes

Match address 10.5.0.0/24
 PermitRootLogin yes

Match Group sftponly
 ChrootDirectory %h
 ForceCommand internal-sftp
 AllowTcpForwarding no
 PermitTunnel no
 X11Forwarding no

Und hier ist die Übersicht der Home Verzeichnisse,
Code: 
root@ubuntu:~# ls -l /home/
insgesamt 8
drwxr-x--- 4 root    sftponly 4096 Sep  2 12:27 versicherung

root@ubuntu:~# ls -l /home/versicherung/
insgesamt 4
drwxr-xr-x 2 versicherung root 4096 Sep  2 12:29 incoming
ich hoffe, dass man damit etwas anfangen kann und bedanke mich schon mal für die Hilfe.

Gruß, Domi
 
Domi said:
Code: 
d[COLOR="red"]rwx[/COLOR][COLOR="blue"]r-x[/COLOR]--- 4 [COLOR="Red"]root[/COLOR]    [COLOR="Blue"]sftponly[/COLOR] 4096 Sep  2 12:27 versicherung
Click to expand...
Preisfrage: Wieso kann der user Versicherung nicht in sein Home schreiben?
Protipp: Weil es root gehört und sonst niemand Schreibrechte dort hat.
 
Gegen Preisfrage.. Wie soll man es dann sonst machen? Der sFTP Server verlangt nun mal, dass das chroot Verzeichnis root gehört und 750 oder 755 als Rechte hat :rolleyes:
 
RSAAuthentication, X11Forwarding und UsePAM willst Du deativieren.
Die SFTP-Zeile solltest Du noch um eine sinnvolle umask erweitern:
Code: 
Subsystem sftp internal-sftp -u 0027

Hier mal eine komplette sshd_config
Code: 
Port 22
AddressFamily any
ListenAddress 0.0.0.0
ListenAddress ::
Protocol 2
HostKey /etc/ssh/ssh_host_rsa_key
HostKey /etc/ssh/ssh_host_ecdsa_key
HostKey /etc/ssh/ssh_host_ed25519_key
RekeyLimit 500M 1h
Ciphers [email protected],[email protected],aes256-ctr,aes256-cbc
Macs [email protected],[email protected],hmac-sha2-512,hmac-sha2-256
KexAlgorithms [email protected],ecdh-sha2-nistp521,ecdh-sha2-nistp384,diffie-hellman-group-exchange-sha256,diffie-hellman-group-exchange-sha1
LoginGraceTime 2m
PermitRootLogin no
StrictModes yes
MaxAuthTries 3
MaxSessions 10
RSAAuthentication no
PubkeyAuthentication yes
IgnoreRhosts yes
PasswordAuthentication no
PermitEmptyPasswords no
ChallengeResponseAuthentication no
UsePAM no
AllowAgentForwarding no
AllowTcpForwarding no
GatewayPorts no
X11Forwarding no
PermitTTY yes
PrintMotd yes
PrintLastLog yes
TCPKeepAlive yes
UseLogin no
UsePrivilegeSeparation sandbox
PermitUserEnvironment no
Compression delayed
ClientAliveInterval 10
ClientAliveCountMax 6
UseDNS yes
MaxStartups 10:30:100
PermitTunnel no
ChrootDirectory %h
AcceptEnv LANG LC_*
Subsystem sftp internal-sftp -u 0027

AllowGroups root sftponly users

Match address 10.30.0.0/24
    PermitRootLogin yes

Match address 10.5.0.0/24
    PermitRootLogin yes

Match Group sftponly
    ForceCommand internal-sftp

Match User root
    ChrootDirectory none


Das HOME müsste eigentlich so richtig sein:
Code: 
chmod 0755 /home
chmod 0755 /home/versicherung
chown versicherung:users /home/versicherung
 
Es geht nicht um chroot sondern um diesen Müll:
Code: 
# chown root.root /home/user
# usermod -d / user
Erste Zeile: $HOME hat grundsätzlich immer $USER:$GROUP zu gehören, zudem enthält sie einen Syntaxfehler
Zweite Zeile: Ganz böses Sicherheitsleck geöffnet, Rechtemanagement und Filesystemhierarchy unterlaufen
Man könnte "user" auch gleich root-Rechte geben, würde nicht mehr viel ändern.

Grundlagenwissen hätte diesen Fail verhindert...
 
Schon mal jemand auf das Datum des Tutorials geschaut?
Posted by niol on Tue 1 Apr 2008 at 10:49
Click to expand...
Wenn ich mich recht entsinne war damals das noch so, daß die Rechte für chrooted-Homes so gesetzt sein mussten.

(immerhin baut er keine komplette chroot-Umgebung mehr - die Tutorials findet man auch immer noch)
 
Moin moin... Ich habe mich vorhin erst einmal mit der Konfig befasst und diese in meine Konfiguration übernommen. Also via Putty kann ich noch auf meinen Server drauf zugreifen und wenn das nicht geklappt hätte, könnte ich noch physisch an das System gehe da das System hier im Büro steht :D

Code: 
root@ubuntu:/home# ls -l
insgesamt 8
drwxr-xr-x 4 versicherung users   4096 Sep  2 12:27 versicherung
So sieht es nun aus, wenn ich mich nun versuche zu verbinden, kommt folgende Meldung...
Code: 
2015 Sep  8 09:20:22 ubuntu fatal: bad ownership or modes for chroot directory "/home/versicherung"
Und blöderweise steht ich jetzt vor dem gleichen Problem wie zu Anfang :o

Gruß, Domi
 
schon längers her, daß ich ein chrooted-home gebastelt hab - aber gut möglich, daß die Rechte immer noch bei root:root liegen müssen für $home - ggf. sagt das Logfile vom sshd noch ein wenig mehr oder der Verbose-Mode der Verbindung.
 
Lege bitte mal einen neuen User mit Username=joeuser und Group=joeuser an und weise diesem zusätzlich die Group=sftponly zu. Alles Andere lässt Du von Deinem OS automatisch setzen und änderst auch nichts daran. Nur ein Passwort vergibst Du bitte.

Dann schickst mir per PN oder Mail bitte die IP des Servers und das Passwort für joeuser und ich schau mal, was da eventuell noch schief läuft.
 
OK, habe es nun verifiziert:
Das Chroot-Directory und alle Parent-Directories müssen als User root und als Chmod maximal 0755 haben.

Damit ist dann auch definitv ein schreibender Zugriff direkt im Chroot-Directory ausgeschlossen.



Du musst also entweder auf ein Chroot für den User versicherung verzichten (schlechte Idee), oder den Client dazu bringen, nach dem Connect direkt in ein beschreibbares Unterverzeichnis zu wechseln (optimale Lösung).
 
Ist als Alternative FTP over SSL denkbar? Ok, man müsste auf PW zurück statt PublicKeyAuth aber im Gegenzug wäre der gewünschte direkte Verzeichniszugriff problemlos möglich.
 
Moin moin,

@Joe User, danke für das Feedback... dann ist es wirklich so das man via SFTP nicht im Homeverzeichnis schreiben kann. Die Empfohlene Variante finde ich schon mal gut, kann man denn in der sshd_config irgendwie mitteilen, dass er den User sofort in das "incoming" Verzeichnis schieben soll beim Login? :D

@TerraX, der Versicherer akzeptiert nur SFTP Verbindungen. Habe mit den IT'lern ein paar mal telefoniert. Ganz zu Anfang durfte ich denen auch erklären das vielleicht deren ausgehenden Ports in der Firewall geblockt sind da mein SSH zuerst auf einem Port über 10.000 lief (was ich denen sogar mitteilte), die sich nicht verbinden konnten und behaupteten, dass mein Server nicht funktioniert :D
 
Die ITler von $versicherung sollen einfach ein "cd incoming" in ihr sftp-Script packen und fertig.


Ob Du es auf Deiner Seite lösen kannst, ohne gleich ein Wrapperscript für OpenSSH basteln zu müssen, weiss ich gerade nicht, da müsste ich erst selbst nachforschen.
 
ChrootDirectory
Specifies the pathname of a directory to chroot(2) to after authentication. At session startup sshd(8) checks that all components of the pathname are root-owned directories which are not writable by any other user or group. After the chroot, sshd(8) changes the working directory to the user's home directory.
Click to expand...
Quelle: http://www.openbsd.org/cgi-bin/man.cgi/OpenBSD-current/man5/sshd_config.5?query=sshd_config&sec=5

Demnach müsste in der sshd-config als ChrootDirectory /home (mit root:root) stehen aber bei User versicherung /home/versicherung (als Homeverzeichnis).

Wenn das nicht von allein funktioniert, müssen wir eben zusätzlich noch mit etwas Gewalt nachhelfen:

Code: 
ForceCommand internal-sftp -d %u
in einem passenden "Match User versicherung" verpackt.
 
Das funktioniert, allerdings können die sftponly-User sich dann gegenseitig in die HOMEs schauen und auch die Inhalte abgreifen :(

Also leider auch keine brauchbare Lösung.
 
You must log in or register to reply here.
Back
Top