From owner-freebsd-stable@FreeBSD.ORG Thu Jan 5 19:26:37 2012 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 7F483106566C for ; Thu, 5 Jan 2012 19:26:37 +0000 (UTC) (envelope-from jdc@koitsu.dyndns.org) Received: from QMTA11.westchester.pa.mail.comcast.net (qmta11.westchester.pa.mail.comcast.net [76.96.59.211]) by mx1.freebsd.org (Postfix) with ESMTP id 3E77D8FC0A for ; Thu, 5 Jan 2012 19:26:37 +0000 (UTC) Received: from omta23.westchester.pa.mail.comcast.net ([76.96.62.74]) by QMTA11.westchester.pa.mail.comcast.net with comcast id HoLM1i0061c6gX85BvSdzG; Thu, 05 Jan 2012 19:26:37 +0000 Received: from koitsu.dyndns.org ([67.180.84.87]) by omta23.westchester.pa.mail.comcast.net with comcast id HvSb1i02H1t3BNj3jvSc0Y; Thu, 05 Jan 2012 19:26:37 +0000 Received: by icarus.home.lan (Postfix, from userid 1000) id 58772102C19; Thu, 5 Jan 2012 11:26:34 -0800 (PST) Date: Thu, 5 Jan 2012 11:26:34 -0800 From: Jeremy Chadwick To: Rainer Duffner Message-ID: <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> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <8B259221-6A70-4D3C-ABA7-D74B2C9F9F14@ultra-secure.de> User-Agent: Mutt/1.5.21 (2010-09-15) Cc: freebsd-stable@freebsd.org Subject: Re: FTPS Server? X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 05 Jan 2012 19:26:37 -0000 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 [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). -- | Jeremy Chadwick jdc at parodius.com | | Parodius Networking http://www.parodius.com/ | | UNIX Systems Administrator Mountain View, CA, US | | Making life hard for others since 1977. PGP 4BD6C0CB |