create standard user sftpusr

allow ssh remote login for sftpusr

sudo vim /etc/ssh/sshd_config

# override default of no subsystems
# Subsystem sftp /usr/libexec/sftp-server

#Subsystem sftp internal-sftp -l VERBOSE -f LOCAL3
Subsystem sftp internal-sftp
Match User sftpusr
X11Forwarding no
AllowTcpForwarding no
ForceCommand internal-sftp
ChrootDirectory /chroot/%u

run command
sudo mkdir /chroot
sudo mkdir /chroot/bin
sudo cp /bin/bash /chroot/bin
sudo cp /bin/sh /chroot/bin
sudo mkdir /chroot/sftpusr
sudo mkdir /chroot/sftpusr/media

sudo chroot -u sftpusr /chroot

 

Download https://www.bresink.com/osx/NFSManager.html

 

Wenn ich die Bildschirmfotos richtig deute, möchten Sie den Automount innerhalb
einer chroot-Umgebung verwenden? Das hatten Sie ursprünglich nicht erwähnt.

Unix-Systeme sind so konstruiert, dass sie jegliche Form von Automounting
mit Absicht blockieren, wenn es innerhalb von chroot verwendet wird. Dies
wäre nämlich eine Sicherheitslücke.

Ein potenzieller Angreifer könnte einen Automount z.B. so manipulieren, dass
der Computer einen Ordner “von sich selbst” in die chroot-Umgebung
hinein-mountet, obwohl sich dieser Ordner außerhalb der chroot-Zone befindet.
Auf diese Weise könnte das chroot beliebig umgangen werden. Das wäre nicht
Sinn der Sache.

Es handelt sich hier also um einen exotischen Sonderfall, bei dem das
Betriebssystem einen Automount aus Sicherheitsgründen tatsächlich anders
behandelt, als einen festen Mount.

Wenn Sie den Zugriff auf einen SFTP-Server absichern möchten, sollten Sie
überlegen, ob Sie dies nicht alternativ über einen symbolischen Link
auf den freizugebenden Ordner und Zugriffsrechte regeln können.

Ich hoffe dies hilft Ihnen weiter, auch wenn sich das ursprüngliche Problem
nicht lösen lässt. Bei Rückfragen stehe ich gerne zur Verfügung.

 

 

sudo vim /etc/exports
/Users/bhr/Music/iTunes/iTunes\ Media -network 10.0.29.0 -mask 255.255.255.0

manual mount
sudo mount -o ro -t nfs 10.0.29.150:/Users/bhr/Music/iTunes/iTunes\ Media /chroot/sftpusr/media/

 

auto mount
mkdir /Users/bhr/Library/LaunchAgents/

vim /Users/bhr/Library/LaunchAgents/org.mount.nfs.plist
<?xml version=”1.0″ encoding=”UTF-8″?>
<!DOCTYPE plist PUBLIC “-//Apple//DTD PLIST 1.0//EN” “http://www.apple.com/DTDs/PropertyList-1.0.dtd”>
<plist version=”1.0″>
<dict>
<key>KeepAlive</key>
<true/>
<key>Label</key>
<string>org.mount.nfs</string>
<key>Program</key>
<string>/Users/bhr/Library/LaunchAgents/mountnfs.sh</string>
<key>RunAtLoad</key>
<true/>
<key>StandardErrorPath</key>
<string>/tmp/com.mmac.startup.stderr</string>
<key>StandardOutPath</key>
<string>/tmp/com.mmac.startup.stdout</string>
</dict>
</plist>

 

vim /Users/bhr/Library/LaunchAgents/mountnfs.sh
#!/bin/bash
mount -o ro -t nfs 10.0.29.150:/Volumes/DATACUBE/Media /chroot/sftpusr/media/
mount -o rw -t nfs 10.0.29.150:/Volumes/DATACUBE/Upload /chroot/sftpusr/upload

showmount
df -H

Comments

  1. Alex

    I have a more relevant question to my own situation. If you please, I have a group named sftpgroup and user inside that group. How do I prevent those users from gaining shell access? If give them a null shell they lose sftp access. Do your step resolve this? I looked at man chroot(8) in high Sierra and it would appear to do what I need. Could you Kindly clarify?

    1. admin Article Author

      No need for a special shell, just create a standard macOS user. The chroot command should do the rest.

Leave a Reply

Your email address will not be published. Required fields are marked *

This site uses Akismet to reduce spam. Learn how your comment data is processed.