OpenSSH is very much tied to system users, but sometimes you might want to give access to external users that don’t need to exist as actual unix users.

because SSH and SFTP are so closely tied together, a configuration via PAM is pretty hard and inconvenient because creating fake users via PAM for SFTP will also create them for SSH and because there’s no easy way to map all such virtual users to the same user-id. Also, because OpenSSH has zero support for virtual users, aside of a PAM configuration, you also need an NSS configuration and now all your virtual users in some database have suddenly become system users on your box.

SFTP as a protocol on the other hand is very convenient over, say FTP over TLS because it’s using a single TCP port and it has been created this century.

So having this self-contained project is useful when you need to allow third parties access to files but you also don’t want to create system users for them or risk f’ing something up with PAM

I'd second this, I've longed struggled to come up with a easy-to-deploy sshd/sftp/chroot configuration that permitted easy database-driven configuration w/o extra shell access. You have to fight a lot of defaults to get this just right.

Would the OpenSSH upstream accept patches for an unprivileged sshd/sftp-subsystem to make this easier to use their battle tested code?

If you just want to share files and not giving the option to upload files, you could try graft...

https://github.com/sandreas/graft

graft serve ./*.txt

will serve every txt file in the current dir...

For that use case, I just use `python3 -m http.server` (or the Python 2 equivalent), especially since Python is almost always already installed.

Cool... is SSL support for secure file transfer?

If you don't mind, I have a question about graft.

> graft will prompt for a password, run an sftp server and promote it via zeroconf.

Is that a one time password that will be used by the "receiver" to download the file?

No, it is a static unchangeable password. Graft can't "manage" user accounts, it just has one user with password. It does not support keyfiles or other authentication mechanisms.

I wrote graft to have a simple portable tool for transfering files in a network without shares - the main idea behind it was to run:

graft serve myfiles/*.txt

on the server side and then

graft receive

on the client side without having to remember the ip or hostname - because zeroconf / mdns is used, it will find the server automatically, if the network is not too big. If there is more than one server, it will prompt you to choose the right one.

I only used SFTP, because it is a secure way to transfer files over the network.

Proftpd can do sftp-only out of the box.

on the other hand, its SQL backend modules insist on fetching a password and comparing them using their own functionality and there's no way to get to the the user's typed password into a custom query.

That means that there's no way to authenticate users if you use a password encryption scheme not supported by the bundled modules (like bcrypt for example)

I am not sure why I didn't realize that sooner, but that's awesome, thank you for pointing that out.

Seems like a use-case for just wrapping regular SFTP in a virtualized userland with definable hooks for things like PAM’s user data lookups. I believe that gVisor does this?

Thanks for the explanation! The OP's question was the first one that popped into my mind too...

To be fair, it is written in Go - a language where a lot of projects built can just be single, portable binaries with no dependencies (as this project appears to be).

With this solution you can easily create fake account just for sftp, and the installation is very simple. In other words, it solves the biggest security problem with sftp accounts - what you usually want is only to give people access to a few files, and not to give them full system accounts.

I actually had to implement something very similar. The use case was an SFTP upload interface for clients that they would use the same login credentials they use for the web portal to upload to unique subfolders in Azure Storage.

What do you recommend?

Proftpd?

A lot of more advanced servers are either (1) proprietary (2) unmaintained (3) hard to use (4) require a Linux VM or all of the above.

I agree, unless some robust solution is needed - I prefer just the daemon and using the CLI to push/pull content