Date: Thu, 05 Jan 2012 23:06:11 +0100 From: Miroslav Lachman <000.fbsd@quip.cz> To: Jeremy Chadwick <freebsd@jdc.parodius.com> Cc: freebsd-stable@freebsd.org, Rainer Duffner <rainer@ultra-secure.de> Subject: Re: FTPS Server? Message-ID: <4F061ED3.3060506@quip.cz> In-Reply-To: <20120105192634.GA69685@icarus.home.lan> References: <4F059BEA.3000508@denninger.net> <4F05A7D5.8000403@infracaninophile.co.uk> <20120105153724.GA91242@lyxys.ka.sub.org> <8B259221-6A70-4D3C-ABA7-D74B2C9F9F14@ultra-secure.de> <20120105192634.GA69685@icarus.home.lan>
next in thread | previous in thread | raw e-mail | index | archive | help
Jeremy Chadwick wrote: > On Thu, Jan 05, 2012 at 05:16:43PM +0100, Rainer Duffner wrote: >> >> Am 05.01.2012 um 16:37 schrieb Wolfgang Zenker: >> >>> Hi everyone, >>> >>> * Matthew Seaman<m.seaman@infracaninophile.co.uk> [120105 14:38]: >>>> On 05/01/2012 12:47, Karl Denninger wrote: >>>>> Not SFTP (which is supported by the sshd) but FTPS.... is it supported >>>>> by FreeBSD? >>> >>>> No, not supported in the base system. >>> >>>>> [..] >>>> However, personally, I'd avoid FTPS. It suffers from most of the design >>>> flaws of standard FTP[*], particularly as regards passing through >>>> firewalls. Worse, because the traffic is encrypted, you can't even use >>>> tools like ftp-proxy (in ports as ftp/ftp-proxy) to extract transient >>>> port numbers by deep packet inspection. As far as your users are >>>> concerned, just use SFTP. It behaves exactly like an ordinary FTP >>>> client, but the underlying SSH protocol over the network is way, way >>>> better designed. >>> >>> Well, the problem I have here is at the server side: ftp users can be >>> locked in a particular subtree of the file system by simply assigning >>> them a chrooted login class. No need to setup any infrastructure in >>> that subtree itself. Did not find out how to do this with sftp (we only >>> allow publickey authentication with ssh at our servers) >>> >>> Wolfgang >> >> >> It is possible. >> >> See the chroot configuration in the man-page for sshd_config >> >> If you have a sufficiently complete chroot-environment, you can even do chroot'ed ssh login sessions. > > It is possible, but some of the limitations of it are infuriating and > unrealistic for certain environments. I just went through working with > a friend of mine (on a Linux system) setting this up so that one of his > clients had SFTP access chroot'd but *without* all the "copy /dev and > random libraries and other crap" nonsense that is often required. It > worked, but the one limitation that we kept having to "find workarounds > for" was this: > > All components of the pathname must be root-owned directories that > are not writable by any other user or group. > > The general procedures we followed, but diverted from a bit (for a lot > of reasons), was: > > http://www.debian-administration.org/articles/590 > http://www.howtoforge.com/chrooted-ssh-sftp-tutorial-debian-lenny > > For a third time, I will repeat: this method works, but has some serious > nuances/complexities given the group limitation ("requirement"). People > setting this up will need to be adamant about watching syslog for > errors, and will be quite surprised when they find that "sftponly" group > they set up doesn't quite work the way they hoped given the security > "requirements" of the daemon. > > People who say "hey man, sshd has this ChrootDirectory thing, it solves > the problem" choose to bury their head in the sand. When recommending > things of this nature, people should be made aware up front of the > complexities. > > Oh, and if your system doesn't have remote serial console or way to get > in if sshd doesn't like some of your sshd_config adjustments, I > recommend running a separate instance on a separate port (if firewalls > are involved deal with that too) so you have a way to get in, in the > case standard port 22 stops working. (This did happen during the > aforementioned story, and my friend was quite happy that I had told him > to set that up prior. ;-) ) > > And before someone mentions it: let's not bring setfacl into this, nor > rssh (god forbid anyone have to use that thing). Great post (as usual)! The "root owned" dir hierarchy is a big problem if someone wants to allow remote access to part of the tree not owned by root but some regular user or a daemon. This (and other mentioned configuration problems with file transfers over SSH) makes me stay with FTPeS for webhosting clients for many years. We are using ProFTPd with user accounts stored in MySQL. It is easy and flexible. ProFTPd also supports SFTP configuration, but I didn't test it yet (ENOTIME). http://www.proftpd.org/docs/contrib/mod_sftp.html Miroslav Lachman
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?4F061ED3.3060506>