sftp Server unter /mnt

iWaver · 4. Juni 2020

Hallo zusammen,

versuche gerade ziemlich verzweifelt einen sftp Server zum laufen zu bringen. Das ganze läuft auf einem ROCKPro64 mit Armbian Buster.
Als Anleitung benutze ich diesen Guide, der auch super funktioniert, solange der Zielordner unter /home liegt.
Allerdings möchte ich Dateien auf meinem raid1 ablegen, welches unter /mnt gemountet ist.

Also mache ich folgendes

Code:

useradd -m -s /bin/bash test
mkdir /mnt/test
chown root:test /mnt/test
chmod 755 /mnt/test
usermod -s /bin/false test
mkdir /mnt/test/server
chown test:test /mnt/test/server
chmod 755 /mnt/test/server

und ändere meine /etc/ssh/sshd_config

Code:

Subsystem sftp internal-sftp
#Subsystem sftp /usr/lib/openssh/sftp-server
PasswordAuthentication yes
Match User test
ChrootDirectory /mnt/test
ForceCommand internal-sftp

kann aber trotzdem keine Verbindung herstellen.
Meine Vermutung ist, dass ich bei useradd etwas falsch mache, aber selbst dann weiß ich nicht, was.
Würde mich sehr über irgendeinen Hinweis freuen!

Sandorkan · 4. Juni 2020

Ich denke, du musst am Ende des ersten Teils (anlegen User, etc.) noch folgendes ausführen:

Bash:

usermod -d <neues home verzeichnis> <username>, also hier
usermod -d /mnt/test/server test

Kannst du aber auch direkt beim anlegen des User mitgeben:

Bash:

usermod -m -s /bin/bash -d /mnt/ test # Homeverzeichnis ist dann /mnt/test

Uridium · 4. Juni 2020

Poste mal ein verbose Log des Clients. Da steht genau drin, warum es hakt.

iWaver · 4. Juni 2020

Sandorkan schrieb:
Bash:

usermod -d /mnt/test/server test

Hab das mal so versucht

Bash:

user@rockpro64:/$ sudo useradd -m -s /bin/bash test
user@rockpro64:/$ sudo mkdir /mnt/test
user@rockpro64:/$ sudo chown root:test /mnt/test
user@rockpro64:/$ sudo chmod 755 /mnt/test
user@rockpro64:/$ sudo usermod -s /bin/false test
user@rockpro64:/$ sudo mkdir /mnt/test/server
user@rockpro64:/$ sudo chown test:test /mnt/test/server
user@rockpro64:/$ sudo chmod 755 /mnt/test/server
user@rockpro64:/$ sudo usermod -d /mnt/test/server test
user@rockpro64:/$ sudo passwd test
New password:
Retype new password:
passwd: password updated successfully
user@rockpro64:/$ sudo nano /etc/ssh/sshd_config
user@rockpro64:/$ sudo /etc/init.d/ssh restart
[ ok ] Restarting ssh (via systemctl): ssh.service.

Will aber immer noch nicht.

Sandorkan schrieb:
Bash:

usermod -m -s /bin/bash -d /mnt/ test # Homeverzeichnis ist dann /mnt/test

Wäre das nicht eher useradd?

Uridium schrieb:
Poste mal ein verbose Log des Clients. Da steht genau drin, warum es hakt.

Kommt gleich.

Ergänzung (4. Juni 2020)

Bash:

user@devuan:~$ sudo sftp -v -oPort=42540 test@192.168.188.43
OpenSSH_7.4p1 Debian-10+deb9u7, OpenSSL 1.0.2u  20 Dec 2019
debug1: Reading configuration data /etc/ssh/ssh_config
debug1: /etc/ssh/ssh_config line 19: Applying options for *
debug1: Connecting to 192.168.188.43 [192.168.188.43] port 42540.
debug1: Connection established.
debug1: permanently_set_uid: 0/0
debug1: key_load_public: No such file or directory
debug1: identity file /root/.ssh/id_rsa type -1
debug1: key_load_public: No such file or directory
debug1: identity file /root/.ssh/id_rsa-cert type -1
debug1: key_load_public: No such file or directory
debug1: identity file /root/.ssh/id_dsa type -1
debug1: key_load_public: No such file or directory
debug1: identity file /root/.ssh/id_dsa-cert type -1
debug1: key_load_public: No such file or directory
debug1: identity file /root/.ssh/id_ecdsa type -1
debug1: key_load_public: No such file or directory
debug1: identity file /root/.ssh/id_ecdsa-cert type -1
debug1: key_load_public: No such file or directory
debug1: identity file /root/.ssh/id_ed25519 type -1
debug1: key_load_public: No such file or directory
debug1: identity file /root/.ssh/id_ed25519-cert type -1
debug1: Enabling compatibility mode for protocol 2.0
debug1: Local version string SSH-2.0-OpenSSH_7.4p1 Debian-10+deb9u7
debug1: Remote protocol version 2.0, remote software version OpenSSH_7.9p1 Debian-10+deb10u2
debug1: match: OpenSSH_7.9p1 Debian-10+deb10u2 pat OpenSSH* compat 0x04000000
debug1: Authenticating to 192.168.188.43:42540 as 'test'
debug1: SSH2_MSG_KEXINIT sent
debug1: SSH2_MSG_KEXINIT received
debug1: kex: algorithm: curve25519-sha256
debug1: kex: host key algorithm: ecdsa-sha2-nistp256
debug1: kex: server->client cipher: chacha20-poly1305@openssh.com MAC: <implicit> compression: none
debug1: kex: client->server cipher: chacha20-poly1305@openssh.com MAC: <implicit> compression: none
debug1: expecting SSH2_MSG_KEX_ECDH_REPLY
debug1: Server host key: ecdsa-sha2-nistp256 SHA256:qTtgJr9O+zym+AXsBgSvqzvzwMfSE47jg3sdbPZR4ms
debug1: Host '[192.168.188.43]:42540' is known and matches the ECDSA host key.
debug1: Found key in /root/.ssh/known_hosts:1
debug1: rekey after 134217728 blocks
debug1: SSH2_MSG_NEWKEYS sent
debug1: expecting SSH2_MSG_NEWKEYS
debug1: SSH2_MSG_NEWKEYS received
debug1: rekey after 134217728 blocks
debug1: SSH2_MSG_EXT_INFO received
debug1: kex_input_ext_info: server-sig-algs=<ssh-ed25519,ssh-rsa,rsa-sha2-256,rsa-sha2-512,ssh-dss,ecdsa-sha2-nistp256,ecdsa-sha2-nistp384,ecdsa-sha2-nistp521>
debug1: SSH2_MSG_SERVICE_ACCEPT received
debug1: Authentications that can continue: publickey,password
debug1: Next authentication method: publickey
debug1: Trying private key: /root/.ssh/id_rsa
debug1: Trying private key: /root/.ssh/id_dsa
debug1: Trying private key: /root/.ssh/id_ecdsa
debug1: Trying private key: /root/.ssh/id_ed25519
debug1: Next authentication method: password
test@192.168.188.43's password:
debug1: Authentication succeeded (password).
Authenticated to 192.168.188.43 ([192.168.188.43]:42540).
debug1: channel 0: new [client-session]
debug1: Requesting no-more-sessions@openssh.com
debug1: Entering interactive session.
debug1: pledge: network
packet_write_wait: Connection to 192.168.188.43 port 42540: Broken pipe
Couldn't read packet: Connection reset by peer

lokon · 4. Juni 2020

iWaver schrieb:
Bash:

Couldn't read packet: Connection reset by peer

Der Server scheint die Verbindung zu Beenden. Also wird ein teil vom Server / ssh-daemon Log benötigt.

Uridium · 4. Juni 2020

Warum sudo?

iWaver schrieb:
$ sudo sftp

Sandorkan · 4. Juni 2020

iWaver schrieb:
Wäre das nicht eher useradd?

An der Stelle nicht, da der User "test" ja schon existiert

lokon schrieb:
Der Server scheint die Verbindung zu Beenden. Also wird ein teil vom Server / ssh-daemon Log benötigt.

So sieht es aus, denn die Verbindung wurde ja erfolgreich hergestellt (auch das Passwort stimmt, etc.):

iWaver schrieb:
test@192.168.188.43's password: debug1: Authentication succeeded (password). Authenticated to 192.168.188.43 ([192.168.188.43]:42540).

Für die Logfiles würde ich mal unter /var/log/secure, /var/log/auth oder /var/log/messages schauen (habe kein Debian zur Hand, um das genauer sagen zu können).

iWaver · 4. Juni 2020

In var/log/auth.log finde ich

Code:

Jun  4 10:09:18 localhost sshd[5671]: Accepted password for test from MEI.NE_.IP_.XXX port 57377 ssh2
Jun  4 10:09:18 localhost sshd[5671]: pam_unix(sshd:session): session opened for user test by (uid=0)
Jun  4 10:09:18 localhost systemd-logind[939]: New session 160 of user test.
Jun  4 10:09:18 localhost systemd: pam_unix(systemd-user:session): session opened for user test by (uid=0)
Jun  4 10:09:18 localhost sshd[5760]: fatal: bad ownership or modes for chroot directory component "/mnt/"
Jun  4 10:09:18 localhost sshd[5671]: pam_unix(sshd:session): session closed for user test
Jun  4 10:09:18 localhost systemd-logind[939]: Session 160 logged out. Waiting for processes to exit.
Jun  4 10:09:18 localhost systemd-logind[939]: Removed session 160.

In var/log/messages gar nichts Relevantes.

Sandorkan · 4. Juni 2020

iWaver schrieb:
Jun 4 10:09:18 localhost sshd[5760]: fatal: bad ownership or modes for chroot directory component "/mnt/"

Dazu habe ich auf die schnelle folgende Information gefunden:

ChrootDirectory
Specifies the pathname of a directory to chroot(2) to after authentication. All components of the pathname must be root-owned directories that are not writable by any other user or group. After the chroot, sshd(8) changes the working directory to the user's home directory.

Du müsstest dir also noch einmal die Rechte bzw. Ownership der Verzeichnisse /mnt und /mnt/test anschauen.

iWaver · 4. Juni 2020

Sandorkan schrieb:
An der Stelle nicht, da der User "test" ja schon existiert

Achso, dann versteh ich allerdings nicht, was "direkt beim anlegen des User mitgeben" heißt.
Denn so passiert das

Bash:

user@rockpro64:/$ sudo useradd -m -s /bin/bash test
user@rockpro64:/$ sudo usermod -m -s /bin/bash -d /mnt/ test
usermod: directory /mnt/ exists
user@rockpro64:/$ sudo mkdir /mnt/test
user@rockpro64:/$ sudo chown root:test /mnt/test
user@rockpro64:/$ sudo chmod 755 /mnt/test
user@rockpro64:/$ sudo usermod -s /bin/false test
user@rockpro64:/$ sudo mkdir /mnt/test/server
user@rockpro64:/$ sudo chown test:test /mnt/test/server
user@rockpro64:/$ sudo chmod 755 /mnt/test/server
user@rockpro64:/$ sudo nano /etc/ssh/sshd_config
user@rockpro64:/$ sudo passwd test
New password:
Retype new password:
passwd: password updated successfully
user@rockpro64:/$ sudo /etc/init.d/ssh restart
[ ok ] Restarting ssh (via systemctl): ssh.service.

wobei ich nicht weiß, ob "usermod: directory /mnt/ exists" jetzt tatsächlich ein Problem ist oder nicht

Ergänzung (4. Juni 2020)

Sandorkan schrieb:
Du müsstest dir also noch einmal die Rechte bzw. Ownership der Verzeichnisse /mnt und /mnt/test anschauen.

Dazu mit stat

Bash:

user@rockpro64:/$ stat /
  File: /
  Size: 4096          Blocks: 8          IO Block: 4096   directory
Device: b301h/45825d    Inode: 2           Links: 22
Access: (0755/drwxr-xr-x)  Uid: (    0/    root)   Gid: (    0/    root)
Access: 2020-01-26 01:28:35.884847468 +0000
Modify: 2020-05-27 18:43:52.508769537 +0000
Change: 2020-05-27 18:43:52.508769537 +0000
 Birth: -
user@rockpro64:/$ stat /mnt
  File: /mnt
  Size: 66            Blocks: 32         IO Block: 4096   directory
Device: 33h/51d    Inode: 256         Links: 1
Access: (0777/drwxrwxrwx)  Uid: (    0/    root)   Gid: (    0/    root)
Access: 2020-06-04 14:08:08.928291125 +0000
Modify: 2020-06-04 14:03:38.257606685 +0000
Change: 2020-06-04 14:03:38.257606685 +0000
 Birth: -
user@rockpro64:/$ stat /mnt/test
  File: /mnt/test
  Size: 12            Blocks: 0          IO Block: 4096   directory
Device: 33h/51d    Inode: 1480237     Links: 1
Access: (0755/drwxr-xr-x)  Uid: (    0/    root)   Gid: ( 1001/    test)
Access: 2020-06-04 14:09:31.863888028 +0000
Modify: 2020-06-04 14:01:24.782255425 +0000
Change: 2020-06-04 14:01:24.782255425 +0000
 Birth: -
user@rockpro64:/$ stat /mnt/test/server
  File: /mnt/test/server
  Size: 0             Blocks: 0          IO Block: 4096   directory
Device: 33h/51d    Inode: 1480238     Links: 1
Access: (0755/drwxr-xr-x)  Uid: ( 1001/    test)   Gid: ( 1001/    test)
Access: 2020-06-04 14:09:46.279817961 +0000
Modify: 2020-06-04 14:01:24.782255425 +0000
Change: 2020-06-04 14:01:50.410130864 +0000
 Birth: -

und ls

Bash:

user@rockpro64:/$ ls -l
total 88
[entfernt]
drwxrwxrwx   1 root root    66 Jun  4 14:03 mnt
user@rockpro64:/mnt$ ls -l
total 0
drwxrwxrwx 1 user user  266 Jun  3 14:54 XXX
drwxr-xr-x 1 root test   12 Jun  4 14:01 test
drwxrwxrwx 1 user user 3354 Jun  2 14:26 YYY
drwxrwxrwx 1 user user  126 Feb  4 16:46 ZZZ
user@rockpro64:/mnt/test$ ls -l
total 0
drwxr-xr-x 1 test test 0 Jun  4 14:01 server
user@rockpro64:/mnt/test/server$ ls -l
total 0

wobei user mein normaler Login ist.

Ergänzung (4. Juni 2020)

Sandorkan schrieb:
Dazu habe ich auf die schnelle folgende Information gefunden:

Aber guter Tipp, wie auch auf der Seite erwähnt, wenn ich folgende Änderung mache

Bash:

Match User test
#       ChrootDirectory /mnt/test
        ForceCommand internal-sftp

funktioniert sftp prinzipiell, nur eben ohne jegliche Beschränkungen.

Sandorkan · 4. Juni 2020

iWaver schrieb:
user@rockpro64:/$ stat /mnt File: /mnt Size: 66 Blocks: 32 IO Block: 4096 directory Device: 33h/51d Inode: 256 Links: 1 Access: (0777/drwxrwxrwx) Uid: ( 0/ root) Gid: ( 0/ root)

Und da liegt das Problem, die manpage sagt

All components of the pathname must be root-owned directories that are not writable by any other user or group.

Damit das klappt müssen die Rechte auf /mnt angepasst werden, in unserem Fall also auf 755, sonst kommen die anderen User ja nicht mehr an ihr Homeverzeichnis:

Bash:

$ chmod 755 /mnt

Das sollte es dann gewesen sein

iWaver · 4. Juni 2020

Sandorkan schrieb:
Bash:

$ chmod 755 /mnt

Das sollte es dann gewesen sein

JA war es! Und ich setz noch alles auf 0777, damit Rechte ja keine Probleme machen

Vielen Dank @Sandorkan und alle anderen, endlich funktioniert dieses Geraffel.

Sandorkan · 4. Juni 2020

Kein Thema, schön das es klappt

Gibt so einige Dinge im Linuxumfeld, wo zuviel Rechte das Problem sind (zum Beispiel auch alles, was sich unter ~/.ssh abspielt).

Piktogramm · 6. Juni 2020

Kann es sein, dass die Anleitung vergleichsweise kompliziert ist?

Prinzipiell reicht auf dem Server ja der Open SSH Server und auf dem Client "sshfs" und wer es dauerhaft mag nutzt:
https://wiki.archlinux.org/index.php/SSHFS#On_demand

iWaver · 7. Juni 2020

Piktogramm schrieb:
Prinzipiell reicht auf dem Server ja der Open SSH Server und auf dem Client "sshfs" und wer es dauerhaft mag nutzt:
https://wiki.archlinux.org/index.php/SSHFS#On_demand

Aber wie sieht es da mit Rechten aus? Also kann man die Zugangsdaten auch einfach weitergeben, weil Zugriff auf einen Ordner beschränkt ist.

Sandorkan · 7. Juni 2020

Aus meiner Sicht ist sshfs ein nur dann sinnvoll einsetzbar, wenn ich beide Seiten (also Server und Client) unter Kontrolle habe; wenn nicht, würde ich bei Chroot bleiben.

lokon · 7. Juni 2020

SSHFS nutzt SFTP lt wikipedia .

Das Rechtemanagement , Chroot / Namespace usw. sollte eigentlich immer so restriktiv wie möglich gesetzt werden.
Der "Aufwand" ist dann überall je nach Zielsystem HTTP(S), WEBDAV, FTP(S), SFTP ähnlich. - Anwendungsfall "Mehrere Nutzer möchten Dateien hoch bzw. herunterladen"
SFTP ist im eh schon aktiven SSH Server drin, währen die anderen neue Ports/Dienste benötigen.

sftp Server unter /mnt

Lt. Junior Grade

Cadet 3rd Year

Lt. Commander

Lt. Junior Grade

Lt. Commander

Lt. Commander

Cadet 3rd Year

Lt. Junior Grade

Cadet 3rd Year

Lt. Junior Grade

Cadet 3rd Year

Lt. Junior Grade

Cadet 3rd Year

Admiral

Lt. Junior Grade

Cadet 3rd Year

Lt. Commander

Ähnliche Themen

Passend zum Thema