I think SFTP is an excellent alternative to FTP (as well as FTP over SSL/TLS). It's a whole lot safer than FTP and it solves the archaic annoyance of data ports. Sadly the OpenSSH solution is over the top awkward when it comes to setting up chrooted access, but it works. Introducing something entirely new at this point makes no sense - the situation isn't really as serious as some people want to make it out to be.
> Sadly the OpenSSH solution is over the top awkward when it comes to setting up chrooted access, but it works.
With OpenSSH it's pretty easy to setup users in a chroot, with no shell access. The hard part is if you want logging (to audit what they do), then you need to create a log device in their chroot, which adds complication, and you need OpenSSH 5.2+.
sshd_config:
Subsystem sftp internal-sftp -l VERBOSE
Match Group sftponly
ChrootDirectory %h
ForceCommand internal-sftp -f AUTH -l VERBOSE
Since then, it is easy to setup a chroot'ed account which easily acts like an ftp server. Have a look at ChrootDirectory and the internal-sftp subsystem.
No, in fact I update every 6 months ever since I started using OpenBSD back in 1999. The problem isn't setting up OpenSSH to offer chrooted sftp access. My gripe is that the sftp subsystem for no solid reason requires that a user directory is root-owned in order to chroot even when the user account experiences a forced sftp response (that is, denying shell access, making it an sftp-only account).
the reason the directory must be root owned, is that the chroot directive is also used for normal ssh sessions, where a user owned chroot directory can mean that a user can break out.
Yeah I'm aware of that part. I submitted a number of design suggestions, as well as a patch, to the OBSD devs which disregarded the root ownership check if the SFTP subsystem was called by a connecting client, but no one bothered even discussing the topic. The whole /home/user/user/ directory nesting just rubs me the wrong way.
Comments
I think SFTP is an excellent alternative to FTP (as well as FTP over SSL/TLS). It's a whole lot safer than FTP and it solves the archaic annoyance of data ports. Sadly the OpenSSH solution is over the top awkward when it comes to setting up chrooted access, but it works. Introducing something entirely new at this point makes no sense - the situation isn't really as serious as some people want to make it out to be.
> Sadly the OpenSSH solution is over the top awkward when it comes to setting up chrooted access, but it works.
With OpenSSH it's pretty easy to setup users in a chroot, with no shell access. The hard part is if you want logging (to audit what they do), then you need to create a log device in their chroot, which adds complication, and you need OpenSSH 5.2+.
sshd_config:
Make user1 only be able to use SFTP: If you actually want the "-l VERBOSE" logging to work you need to create ~user1/dev, then modify rsyslog.conf with:Maybe you missed the OpenSSH 4.9 release? http://www.openssh.com/txt/release-4.9
Since then, it is easy to setup a chroot'ed account which easily acts like an ftp server. Have a look at ChrootDirectory and the internal-sftp subsystem.
No, in fact I update every 6 months ever since I started using OpenBSD back in 1999. The problem isn't setting up OpenSSH to offer chrooted sftp access. My gripe is that the sftp subsystem for no solid reason requires that a user directory is root-owned in order to chroot even when the user account experiences a forced sftp response (that is, denying shell access, making it an sftp-only account).
the reason the directory must be root owned, is that the chroot directive is also used for normal ssh sessions, where a user owned chroot directory can mean that a user can break out.
Yeah I'm aware of that part. I submitted a number of design suggestions, as well as a patch, to the OBSD devs which disregarded the root ownership check if the SFTP subsystem was called by a connecting client, but no one bothered even discussing the topic. The whole /home/user/user/ directory nesting just rubs me the wrong way.