SFTP supports anonymous access. I actually just shut down my sftp server to move it or I would be able to show you, but it's super easy on CentOS. Just set up chroot and set a null pw for the usernames of your choice. You can use posix permissions to hide subdirs or files if you wish. You can use chattr or mount permissions to make it read-only or write-only. The only thing missing is browser support. I might have time to put it back online later today and will update this thread.

Ideally, an FTP emulation of any password for FTP/anonymous, recorded to /var/log/secure, would be within SFTP (maybe checking for an "@" character followed by some dots, hoping for an email).

Forcing the null password up the stack to /etc/shadow (or other credential sources) potentially compromises PAM and other applications that may depend upon it.

It sounds like you've implemented a separate SSH server within a chroot for this to protect the base OS; I've done the same for tinyssh with nspawn for an internal project. This is not easy.

Anonymous access for SFTP doesn't scale to the extent used in FTP, even omitting browser access.

FTP is certainly more flexible and virtual users are far more secure than adding folks to /etc/passwd. PureFTPd [1] was my favorite for that very reason. There have been a few FTP daemons that supported the SFTP protocol and had virtual users, but they had too many bugs for me. I believe ProFTPd was one of them.

Regarding SFTP and null passwords, I do not use a separate sshd. I just use the "Match" stanza in OpenSSH. Any SFTP users I add are in the sftpusers group and don't have a shell. SELinux will block some nonsense. For a few years, I had a cron job that was dynamically adding any account that bots would try. I think I was up to about 23k SFTP accounts. I will fire it back up either today or tomorrow and you are welcome to do a pen-test on it. I will also post the sshd_config.

[1] - https://www.pureftpd.org/project/pure-ftpd/

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.

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.

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.

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.

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

>SFTP lacks two key features (amidst jump host and other scope creep frenzy), anonymous mode and URL support in a browser.

You forgot the abysmal performance compared to FTPS due to the SSH flow control conflicting with the underlying TCP flow control.