openssh unix dev - May 2014 - using OpenSSH/SFTP to replace an FTP server securely

Hello Folks,

I'm trying to replace an FTP with several hundred users with something
secure.

My requirements:
    - transfers must be logged
    - users should not have any access to other users' directories
    - users should land in a writable directory
    - users should be chrooted

I've been trying to get this working with OpenSSH and the internal SFTP
server,
but it does not seem possible....

If I chroot each user using "ChrootDirectory /home/%u", there are two
problems:

    1) the user lands in a directory to which he cannot write
    2) I would need hundreds of syslog logging sockets, one in each user's
chrooted environment

if I chroot all users to the same top directory, for example "/home",
which would solve the problem of avoiding hundreds of syslog logging sockets, I
have found no method of having OpenSSH chdir into a user-specific subdirectory
(I would be willing to rely on the standard UNIX security model to restrict
users' access to their own directories).

Have I missed something, or is what I'm trying to achieve simply not
possible
using OpenSSH?

I do not really want to get into bind-mounting all sorts of crap from outside
the chroot envonment to get stuff to work, particularly not for hundreds of
users. If "sftp-server" solve the problem in conjunction with a single
chroot
top directory, I would be willing to bind-mount (or copy) what it needs, but I
have not found any way of getting sftp-server to satisfy the above requirements.

The platform is CentOS 6.5 (x86_64).

"ssh -V" reports:

    OpenSSH_5.3p1, OpenSSL 1.0.1e-fips 11 Feb 2013

cheers,

Rob

On Sun, May 18, 2014 at 9:31 PM, IMAP List Administration <lists at
y42.org> wrote:
> Hello Folks,
>
> I'm trying to replace an FTP with several hundred users with something
secure.
>
> My requirements:
>     - transfers must be logged
>     - users should not have any access to other users' directories
>     - users should land in a writable directory
>     - users should be chrooted
>
> I've been trying to get this working with OpenSSH and the internal SFTP
server,
> but it does not seem possible....
In general, don't bother. SFTP does not handle symlinks well, and the
setups for chroot caged access via SFTP do not scale wall. They
require certain non-user components in every chroot cage, which
confuses some users.

vsftpd, built into RHEL 5 and RHEL 6, works quite well in CentOS. It
also scales well, and gives easily configured, legible configurations
to an FTPS service without necessarily enabling FTP at all.
> If I chroot each user using "ChrootDirectory /home/%u", there are
two problems:
>
>     1) the user lands in a directory to which he cannot write
>     2) I would need hundreds of syslog logging sockets, one in each
user's
> chrooted environment
>
> if I chroot all users to the same top directory, for example
"/home",
> which would solve the problem of avoiding hundreds of syslog logging
sockets, I
> have found no method of having OpenSSH chdir into a user-specific
subdirectory
> (I would be willing to rely on the standard UNIX security model to restrict
> users' access to their own directories).
>
> Have I missed something, or is what I'm trying to achieve simply not
possible
> using OpenSSH?
You've missed the setup directions at
http://www.howtoforge.com/restricting-users-to-sftp-plus-setting-up-chrooted-ssh-sftp-debian-squeeze,
which are pretty good.
> I do not really want to get into bind-mounting all sorts of crap from
outside
> the chroot envonment to get stuff to work, particularly not for hundreds of
> users. If "sftp-server" solve the problem in conjunction with a
single chroot
> top directory, I would be willing to bind-mount (or copy) what it needs,
but I
> have not found any way of getting sftp-server to satisfy the above
requirements.
>
> The platform is CentOS 6.5 (x86_64).
>
> "ssh -V" reports:
>
>     OpenSSH_5.3p1, OpenSSL 1.0.1e-fips 11 Feb 2013
I've recently done something like on CentOS 6.x, so it's feasible. But
the base of each chroot cage needs to be owned by root, so it can't be
"/home/[username]" and have that directory owned by [username]. The
chroot directory is the *base* of the chroot cage. There's an old
sript at
http://www.fuschlberger.net/programs/ssh-scp-sftp-chroot-jail/make_chroot_jail.sh
which is pretty useful for setting this up.

Basically, you should not be treating ordinary user home directories
as this kind of chroot target with SFTP based cages. It doesn't work
well. If you want ordinary user directories, say the internally used
ones, to be accessible with a chrooted access and no other work, use
vsftpd for FTPS based access.

On 19/05/14 03:31, IMAP List Administration wrote:
> Hello Folks,
>
> (...)
> if I chroot all users to the same top directory, for example
"/home",
> which would solve the problem of avoiding hundreds of syslog logging
sockets, I
> have found no method of having OpenSSH chdir into a user-specific
subdirectory
> (I would be willing to rely on the standard UNIX security model to restrict
> users' access to their own directories).
>
> Have I missed something, or is what I'm trying to achieve simply not
possible
> using OpenSSH?
Suppose the user home is /home/foo, then if that path exists inside your 
chroot
(eg. /chrooted-users/home/foo) then the user will be landed inside that 
folder
(writable for him).


If you want something different, like chrooting them at 
/chrooted-users/foo, you
can use -d parameter in the ForceCommand, ie.
  ForceCommand internal-sftp -d /%u


Regards

On Mon, 19 May 2014, IMAP List Administration wrote:
> Hello Folks,
> 
> I'm trying to replace an FTP with several hundred users with something
secure.
> 
> My requirements:
>     - transfers must be logged
>     - users should not have any access to other users' directories
>     - users should land in a writable directory
>     - users should be chrooted
> 
> I've been trying to get this working with OpenSSH and the internal SFTP
server,
> but it does not seem possible....
> 
> If I chroot each user using "ChrootDirectory /home/%u", there are
two problems:
>     1) the user lands in a directory to which he cannot write
>     2) I would need hundreds of syslog logging sockets, one in each
user's
> chrooted environment
The first problem is easily solved. You can specify a different starting
directory on the sftp-server commandline using the '-d' option.

E.g.

Subsystem sftp internal-sftp -d sftp

(and create 'sftp' directory under /home/$user)

The syslog problem doesn't have a good solution right now. Maybe someone
could write a patch to implement logging via the monitor, like what happens
for the pre-auth process.

-d