scp/sftp user chrooten

Z

zulakis

New Member
[gelöst]scp/sftp user chrooten

Hi,
ich würde gerne einen zusätzlichen scp/sftp user anlegen und ihn in einem bestimmten Verzeichnis chrooten. Ich habe schon mehrere howtos durchgelesen und immer wurde einem folgende Konfiguration empfohlen:

/etc/ssh/ssh_config
Code: 
Subsystem       sftp    internal-sftp

Match user user
        ChrootDirectory /home/user
        ForceCommand internal-sftp
        X11Forwarding no
        AllowTcpForwarding no

Der user ist natürlich angelegt & kann auch auf den Server connecten - allerdings auf alle Verzeichnisse zugreifen. Beim ssh neustarten bekomme ich folgende Fehler:
Code: 
/etc/ssh/ssh_config: line 53: Bad configuration option: Subsystem
/etc/ssh/ssh_config: line 55: Bad configuration option: Match
/etc/ssh/ssh_config: line 56: Bad configuration option: ChrootDirectory
/etc/ssh/ssh_config: line 57: Bad configuration option: X11Forwarding
/etc/ssh/ssh_config: line 58: Bad configuration option: AllowTcpForwarding
/etc/ssh/ssh_config: line 59: Bad configuration option: ForceCommand
/etc/ssh/ssh_config: terminating, 6 bad configuration options

Was ist mein Problem? - Verwende ich die falsche config Datei?
 
Last edited by a moderator:
Danke :-) Das war das Problem.

Jetzt lässt er mich leider auf dem Account garnicht mehr einloggen. Wo dran kann das denn liegen? Muss der gechrootete user owner von dem Verzeichnis sein? Als homedir hat er es schon.
 
Vergiss das bitte so.

SFTP Chroots sind z.T. sehr nerven aufreibend.

Wenn du eine saubere Lösung willst, empfehle ich dir einen ProFTP Dämon mit ftpes und da gleich nen Chroot in die Homedir.

Grüße,

Joseph
 
Das Home-Verzeichnis muss root und der Inhalt dem User gehören. ;)
Hier ist es auch insgesamt noch mal kurz beschrieben: http://www.online-tutorials.net/int...h-mit-sftp-und-chroot/tutorials-t-29-324.html

@virtual2
Solche Aussagen sollten wesentlich besser begründet werden. Sofern im Einzelfall nichts technisches dagegen spricht, ist wohl eine Lösung mit bereits vorhandenen Daemons einer Lösung mit weiteren Daemons vorzuziehen.
Wenn du für dich technische Nachteile gefunden hast und es nicht einsetzen magst, bleibt das dir überlassen. Dennoch müssen "deine" Nachteile nicht unbedingt für andere eine Rolle spielen. ;)
 
Ich habe folgende Schritte durchgeführt:

Code: 
adduser --home /home/sftpuser --shell /bin/bash --ingroup users sftpuser
vi /etc/ssh/sshd_config
chown root /home/sftpuser
chmod 750 /home/sftpuser
mkdir /home/sftpuser/public_dir
chown sftpuser: /home/sftpuser/public_dir
Die sshd_config sieht jetzt so aus: http://pastebin.com/pMLheD5a (ich hoffe die quotes stören nicht, ich finde sie machen das ganze noch etwas übersichtlicher..)

Klappt soweit, dass der user nur Dateien in /home/sftpuser/public_dir modifizieren kann, er kann aber immer noch auf alle anderen, nicht explizit auf 0600 gesetzte Dateien zugreifen. Ist das nicht der Sinn des chrooten's, user nicht auf den ganzen Server zugreifen zu lassen :o
 
Und wie kann ich das ändern?

Edit: Ich bin grad wohl etwas geistig umnachtet, ich meinte natürlich wodran es liegen könnte.
 
Last edited by a moderator:
SSHd neugestartet? Config sieht auf den ersten Blick gut aus.
Poste vorsorglich mal die Ausgabe des SFTP Clients oder mach ein Screenshot von diesem. Nicht das wir aneinander vorbei reden.
 
"ls -alh" des Homeverzeichnisses des sftpuser bitte. Läuft irgendeine Form von "Firewall" beziehungsweise Paketfilter?
 
Nach dem einstellen von UsePam = no komme ich garnicht mehr rein, putty sagt mir "no supported auth mothod available" über sftp auch nicht - Klasse!
 
Noch etwas: IMO kontrolliert der sshd die Zugriffsrechte der Homeverzeichnisse! Die müssen seinen Vorstellungen entsprechend gesetzt sein, sonst geht's auch nicht.

z.B. so:
usermod -G sftp joe
usermod -s /bin/false joe
chown root:root /home/joe
chmod 0755 /home/joe

EDIT: Ach, das stand schon in Firewire's Anleitung.
 
Last edited by a moderator:
Wirf einen Blick in die originale sshd_config und Du weisst, warum Du UsePAM grundsätzlich auf no setzen willst.
Desweiteren kannst Du Dich noch immer mit Deinem Key einloggen, daran ändert UsePAM=no nämlich absolut Nichts. Wenn Du Deinen Key verbummelt haben solltest, musst Du halt von der Remote-Console oder dem Rescuesystem aus einen neuen Key hinterlegen.
 
Die falschen Zugriffsrechte hättest Du auch schon vor Deiner Aussperrung korrigiert bekommen, wenn Du wie von mir erbeten die Ausgabe von "ls -alh" gepostet hättest.
Naja, immerhin hast Du nun dank UsePAM=yes Deinen SSHd wieder unsicherer gemacht...
 
You must log in or register to reply here.
Back
Top