ComputerBase Menü
Aktuelles

sftp Server unter /mnt

iWaver

iWaver

Lt. Junior Grade
Registriert
Aug. 2013
Beiträge
296
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!
 
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
 
Poste mal ein verbose Log des Clients. Da steht genau drin, warum es hakt.
 
Sandorkan schrieb:
Bash: 
usermod -d /mnt/test/server test
Zum Vergrößern anklicken....
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
Zum Vergrößern anklicken....
Wäre das nicht eher useradd?

Uridium schrieb:
Poste mal ein verbose Log des Clients. Da steht genau drin, warum es hakt.
Zum Vergrößern anklicken....
Kommt gleich.
Ergänzung ()

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
 
Zuletzt bearbeitet:
iWaver schrieb:
Bash: 
Couldn't read packet: Connection reset by peer
Zum Vergrößern anklicken....
Der Server scheint die Verbindung zu Beenden. Also wird ein teil vom Server / ssh-daemon Log benötigt.
 
  • Gefällt mir
Reaktionen: Uridium
iWaver schrieb:
Wäre das nicht eher useradd?
Zum Vergrößern anklicken....

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.
Zum Vergrößern anklicken....

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).
Zum Vergrößern anklicken....

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).
 
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.
 
iWaver schrieb:
Jun 4 10:09:18 localhost sshd[5760]: fatal: bad ownership or modes for chroot directory component "/mnt/"
Zum Vergrößern anklicken....

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.
Zum Vergrößern anklicken....

Du müsstest dir also noch einmal die Rechte bzw. Ownership der Verzeichnisse /mnt und /mnt/test anschauen.
 
Sandorkan schrieb:
An der Stelle nicht, da der User "test" ja schon existiert ;)
Zum Vergrößern anklicken....
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 :confused_alt:
Ergänzung ()

Sandorkan schrieb:
Du müsstest dir also noch einmal die Rechte bzw. Ownership der Verzeichnisse /mnt und /mnt/test anschauen.
Zum Vergrößern anklicken....
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 ()

Sandorkan schrieb:
Dazu habe ich auf die schnelle folgende Information gefunden:
Zum Vergrößern anklicken....
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.
 
Zuletzt bearbeitet:
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)
Zum Vergrößern anklicken....

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.
Zum Vergrößern anklicken....

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 :)
 
  • Gefällt mir
Reaktionen: iWaver
Sandorkan schrieb:
Bash: 
$ chmod 755 /mnt

Das sollte es dann gewesen sein :)
Zum Vergrößern anklicken....
JA war es! Und ich setz noch alles auf 0777, damit Rechte ja keine Probleme machen :freak:
Vielen Dank @Sandorkan und alle anderen, endlich funktioniert dieses Geraffel.
 
Kein Thema, schön das es klappt :daumen:

Gibt so einige Dinge im Linuxumfeld, wo zuviel Rechte das Problem sind (zum Beispiel auch alles, was sich unter ~/.ssh abspielt).
 
  • Gefällt mir
Reaktionen: BachUhr und iWaver
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.
 
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.
 
Du musst dich einloggen oder registrieren, um hier zu antworten.

Ähnliche Themen

qlubtempo
SFTP Server für mehrer User
2
Antworten
23
Aufrufe
1.188
worldoak
W
A
Anbieter für SFTP Server
Antworten
15
Aufrufe
1.149
metlix93
M
M
mini-sftp-server Ersatz
Antworten
17
Aufrufe
2.273
h00bi
h00bi
X
Dokumente von SFTP Server automatisch herunterladen
Antworten
13
Aufrufe
7.857
XCow
X
F
SFTP Server auf Mac einrichten
Antworten
3
Aufrufe
3.682
aLca
aLca

Passend zum Thema

Zurück
Oben

Willkommen auf ComputerBase!

Mit Werbung weiterlesen

Besuche ComputerBase wie gewohnt mit Werbung und Tracking. Die Zustimmung ist jederzeit widerrufbar.

Details im Privacy Center und in der Liste unserer Partner. Ein Widerruf ist möglich in der Datenschutzerklärung.

… oder ComputerBase Pro bestellen

Nutze ComputerBase ohne Werbebanner, Video-Ads und Werbetracking schon für 4 €/Monat oder 36 €/Jahr.

Mehr zu ComputerBase Pro

Bereits Pro-Nutzer? Hier anmelden.

Tracking: Wir und unsere 160 Partner verarbeiten personenbezogene Daten, indem wir mit auf Ihrem Gerät gespeicherten Informationen (z. B. eindeutige Kennungen in Cookies) ein Nutzungsprofil erstellen, um z. B. Anzeigen zu personalisieren. Verarbeitungszwecke: Genaue Standortdaten und Abfrage von Geräteeigenschaften zur Identifikation, Informationen auf einem Gerät speichern und/oder abrufen, Personalisierte Anzeigen und Inhalte, Anzeigen- und Inhaltsmessungen, Erkenntnisse über Zielgruppen und Produktentwicklungen.

Impressum Kontakt Datenschutz