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.sea...@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
_______________________________________________
freebsd-stable@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
