Live data from Hacker News

SFTPGo: A Full Featured SFTP Server in Go

github.com

1–10 of 59 posts

Re: SFTPGo: A Full Featured SFTP Server in Go

#4
post #2

Go seems like a really good fit for this kind of project

Yeah, I'm hoping to see use of Go routines in useful rewrites of projects like rsync with parallel file uploads. It can lead to clean, extensible, and maintainable code with still low overhead and high throughput.

Re: SFTPGo: A Full Featured SFTP Server in Go

#6

Part of the utility of SFTP to clients and admins is the fact there are no additional requirements other than SSHD to function. This seems to fly in the face of that. If you are willing to install more software, why not use a more feature filled file server?

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

Re: SFTPGo: A Full Featured SFTP Server in Go

#7

Part of the utility of SFTP to clients and admins is the fact there are no additional requirements other than SSHD to function. This seems to fly in the face of that. If you are willing to install more software, why not use a more feature filled file server?

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.

Re: SFTPGo: A Full Featured SFTP Server in Go

#8

Part of the utility of SFTP to clients and admins is the fact there are no additional requirements other than SSHD to function. This seems to fly in the face of that. If you are willing to install more software, why not use a more feature filled file server?

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).

Re: SFTPGo: A Full Featured SFTP Server in Go

#9
post #4
post #2

Go seems like a really good fit for this kind of project

Yeah, I'm hoping to see use of Go routines in useful rewrites of projects like rsync with parallel file uploads. It can lead to clean, extensible, and maintainable code with still low overhead and high throughput.

It's in C again, but since you mentioned rewrites and rsync: https://github.com/kristapsdz/openrsync

Re: SFTPGo: A Full Featured SFTP Server in Go

#10
post #6

Part of the utility of SFTP to clients and admins is the fact there are no additional requirements other than SSHD to function. This seems to fly in the face of that. If you are willing to install more software, why not use a more feature filled file server?

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. Als…

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?

Post reply on HN