3 ms·

I implemented an FTPS service once! AMA? My needs were: 1) Client login [edit: should have been more clear—I mean randos who signed up on our website, basicall

I implemented an FTPS service once! AMA? My needs were: 1) Client login [edit: should have been more clear—I mean randos who signed up on our website, basically], 2) username and password login, no key stuff, 3) obviously plain FTP was not an option. Nice to have: 1) Same username and password as the website, not managed separately. My personal hang-up: 1) I really didn't want to create actual system users for any of this. I settled on ftps, which could satisfy all the needs plus my hang-up, and then chose PureFTPd which made implementing the nice-to-have very easy: https://download.pureftpd.org/pub/pure-ftpd/doc/README.Authentication-Modules https://download.pureftpd.org/pub/pure-ftpd/doc/README.Authe... I'd already factored out our auth into what you'd call a microservice (I think the term was just starting to enter wide use then?) because we needed to serve multiple barely-related services with the same auth, so writing a little script to handle that auth was downright trivial. The only reason it took more than an hour, once I settled on a solution, was that I had to make it play nice with haproxy, and I wanted to thoroughly test my auth script's failure modes. This basically never broke. It was great. A++++ would ftps again.

yjftsjthsd-h 5y ago
I've done approximately that and just used https://github.com/atmoz/sftp https://github.com/atmoz/sftp bound to port 2222 or whatever. SFTP supports password auth just fine if you like, and AFAIK is at least as accessible and probably moreso (clients like filezilla will support both, and sftp shhould be preinstalled on most unix-likes).
- handrous 5y ago
  Right, of course you can use password auth with sftp, but 1) there was no docker at the time (as in the linked repo), 2) lxc itself was very new at the time, in fact, and 3) that project appears to create system users (in the container) which was one thing I was trying to avoid doing, without adding undue complexity (LDAP or whatever). My solution was mature at the time, relied entirely on our existing auth system so there was no need to keep accounts in sync or manage them separately, and didn't cause any complications with permissions for which directories an account could access (if our normal auth system said a user could access ftps for a given project, then they could, and that was it—no messing with Unix permissions and groups or, more likely, Linux ACL-based permissions, and keeping those in sync with the settings on the site)
  - yjftsjthsd-h 5y ago
    Oh sure; certainly not dissing your solution, just pointing out that SFTP is also workable now.
cookiengineer 5y ago
I remember that BSDs original ftpd had a login password limitation with a wrong bytes allocation and a resulting RCE attack surface, which ultimately is still a threat to outdated ProFTPd instances running on Windows. (see exploitdb, it's full of PoCs) I always asked myself: Why not simply use sshd and no login shell for the created user? Gives you legit transport encryption, blocking of keys/certs you wanna ban, and is the definition of battleproven software. I never understood plaintext auth via encrypted transportation layers. They simply don't make sense to me from a security standpoint, and the risks of a broken transport layer is just too damn high as you must have control of every OSI level to really be able to verify it and that's never the case.

yjftsjthsd-h 5y ago

I've done approximately that and just used https://github.com/atmoz/sftp https://github.com/atmoz/sftp bound to port 2222 or whatever. SFTP supports password auth just fine if you like, and AFAIK is at least as accessible and probably moreso (clients like filezilla will support both, and sftp shhould be preinstalled on most unix-likes).

handrous 5y ago
Right, of course you can use password auth with sftp, but 1) there was no docker at the time (as in the linked repo), 2) lxc itself was very new at the time, in fact, and 3) that project appears to create system users (in the container) which was one thing I was trying to avoid doing, without adding undue complexity (LDAP or whatever). My solution was mature at the time, relied entirely on our existing auth system so there was no need to keep accounts in sync or manage them separately, and didn't cause any complications with permissions for which directories an account could access (if our normal auth system said a user could access ftps for a given project, then they could, and that was it—no messing with Unix permissions and groups or, more likely, Linux ACL-based permissions, and keeping those in sync with the settings on the site)
- yjftsjthsd-h 5y ago
  Oh sure; certainly not dissing your solution, just pointing out that SFTP is also workable now.

cookiengineer 5y ago

I remember that BSDs original ftpd had a login password limitation with a wrong bytes allocation and a resulting RCE attack surface, which ultimately is still a threat to outdated ProFTPd instances running on Windows. (see exploitdb, it's full of PoCs) I always asked myself: Why not simply use sshd and no login shell for the created user? Gives you legit transport encryption, blocking of keys/certs you wanna ban, and is the definition of battleproven software. I never understood plaintext auth via encrypted transportation layers. They simply don't make sense to me from a security standpoint, and the risks of a broken transport layer is just too damn high as you must have control of every OSI level to really be able to verify it and that's never the case.