[chasil]

I was forced to implement chroot() for SFTP users under Oracle/RedHat Linux 5. We are, alas, still running it.

The OpenSSH 4.3 release on this platform does not support the "match" keyword, but I was able to coerce it to run a separate SFTP-only on port 24, where I constrained the SFTP-specific accounts. I find that I prefer this approach.

My wily users then discovered that the working passwd entry also let them login with FTP on port 21, so careful control of allowed groups for both protocols was eventually required. Afterwards there is always the nagging suspicion that something was missed.

OpenSSH would also be much better with localized SFTP accounts that were not defined in /etc/passwd. Add that to the wishlist.

[LinuxBender]

Makes sense. I also had to implement a work around "scponly" for CentOS 5. Not fun.

I put a sftp server back up. Feel free to play around with it. This is a single sshd instance and a copy of the config is in the /pub directory of the anonymous user. I did not change anything in pam. The sftp users are selinux confined as user_u.

    server:  45.79.100.12
      port:  22
  username:  anonymous, anon, pub, public
  pw: (null) just hit enter

This message probably won't age well if I remove that node.

[LinuxBender]

Updated this system. It should create accounts if you try to sftp to it. Just wait 2 mins and try the same name again. Any non system account 2 to 16 chars starting with alpha should work.

[tinus_hn]

It uses pam so you can configure it however you want or even write your own module.

It’s dangerous though, be sure to check these users don’t get shell access or the ability to create network pipes.

[LinuxBender]

also symlinks and hardlinks. You can restrict this in the internal-sftp subsystem assuming you force sftp.