Best SFTP (w/chroot): vsftpd vs mysecureshell vs other ??

[Bob Goldberg]

trying to determine best solution for an SFTP server.

   vsftpd appears to be my current best choice, mostly because it's supported by the distribution; but i'm not sure it meets my needs.

   I know mysecureshell meets my needs; but it's a sourceforge project, and not directly supported by the deb dist.

Here's where my needs cause problems - especially with chroot/openssh:

i have 2 classes of users accessing this sftp server.

"users" and "managers". The problem is that managers need group "rw" rights, and normal chroot does not allow for ANY group "w" rights.

users must be chroot'ed to /home/chroot/home/<username>.

   users belong to the chroot group.

   their home dir down, need all be group owned by chmgr.

   home dir down; should all be chmod 770(dir)/660(files). so <user> and managers (chmgr group) all have rw access to files, and rwx /dirs; with other having no rights at all.

managers ideally chroot'ed to /home/chroot/home.

   they can access all <username> folders, and transfer files in/out of each.

   they belong to the chmgr group.

so - yes, i know i can chmod 750 the <username> dir, and then use sub-dir's under that are chmod 770; but this is messy, and forces another layer of dir's i'd prefer not to have.

so i guess my main question, simply is - can i do what i want with:

- vsftpd ?  (preferred as is dist. supported)

- other ?

- mysecureshell - i KNOW this will do what i want; but not dist. supported.

what do demanding admin's choose as their preferred sftp server ?

TIA - Bob

[Bob Goldberg]

ADDENDUM:

forget about vsftp - this package has NOTHING WHAT-SO-EVER to do with SFTP.

WTH were they thinking when they named that package!?

so my question now very simply becomes:

what do demanding admin's choose as a preferred SFTP server, that allows chrooting WITH group "w" access ????

[PaulNM]

On 01/03/2014 05:14 PM, Bob Goldberg wrote:
> ADDENDUM:
> forget about vsftp - this package has NOTHING WHAT-SO-EVER to do with SFTP.
> WTH were they thinking when they named that package!?
>

Well, Very Secure FTP (vsftp) was initially released back in Feb of
2001. The sftp protocal does technically predate that, but apparently
was just a little-used proprietary protocol for awhile. Wikipedia shows
some IETF Internet Drafts from 2001, but I doubt it was well known at
the time.

> so my question now very simply becomes:
> what do demanding admin's choose as a preferred SFTP server, that allows
> chrooting WITH group "w" access ????
>

Wish I could help with that, but I've only ever used openssh's
implementation, and without chrooting for that matter.

- PaulNM


--
To UNSUBSCRIBE, email to debian-us...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listm...@lists.debian.org
Archive: http://lists.debian.org/52C741E7...@paulscrap.com

[Sven Hoexter]

On Fri, Jan 03, 2014 at 04:14:42PM -0600, Bob Goldberg wrote:

> so my question now very simply becomes:
> what do demanding admin's choose as a preferred SFTP server, that allows
> chrooting WITH group "w" access ????

I'm not sure how the OpenSSH implementation handles ACLs, maybe that's
an option but I did not test it.

Then there is Proftpd which has a mod_sftp extension.

And there are still the solutions which predate the chroot() and sftp-internal
implementation possible with OpenSSH like
- scponly
- rssh
- rush

All of them have a somewhat mixed security record and have some cost in
terms of chroot setup and mainting them properly.

Sven
--
There we were, the three of us, the thief the king and I.
Finally, we were forced to see, we were equals in the night.
[Streetlight Manifesto - The three of us]

--
To UNSUBSCRIBE, email to debian-us...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listm...@lists.debian.org

Archive: http://lists.debian.org/2014010413...@garkbit.lan

[Balint Szigeti]

On 04/01/14 13:26, Sven Hoexter wrote:
> On Fri, Jan 03, 2014 at 04:14:42PM -0600, Bob Goldberg wrote:
>
>> so my question now very simply becomes:
>> what do demanding admin's choose as a preferred SFTP server, that allows
>> chrooting WITH group "w" access ????
> I'm not sure how the OpenSSH implementation handles ACLs, maybe that's
> an option but I did not test it.
>
> Then there is Proftpd which has a mod_sftp extension.
>
> And there are still the solutions which predate the chroot() and sftp-internal
> implementation possible with OpenSSH like
> - scponly
> - rssh
> - rush
>
> All of them have a somewhat mixed security record and have some cost in
> terms of chroot setup and mainting them properly.
>
> Sven

Hello

I think it's implementable on Debian as well.
https://sites.google.com/site/jupiter2005ster/redhat-centos/sftp-server

--
To UNSUBSCRIBE, email to debian-us...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listm...@lists.debian.org

Archive: http://lists.debian.org/52C80D...@gmail.com

[Chris Davies]

Bob Goldberg <bobg...@gmail.com> wrote:
> trying to determine best solution for an SFTP server.

> vsftpd appears to be my current best choice

vsftpd is "Very Secure FTP Daemon". It does FTP well (cleartext passwords
notwithstanding). It doesn't do SFTP (file transfer over ssh).

> users must be chroot'ed to /home/chroot/home/<username>.
> users belong to the chroot group.
> their home dir down, need all be group owned by chmgr.
> home dir down; should all be chmod 770(dir)/660(files). so <user> and
> managers (chmgr group) all have rw access to files, and rwx /dirs; with
> other having no rights at all.

> managers ideally chroot'ed to /home/chroot/home.
> they can access all <username> folders, and transfer files in/out of
> each.
> they belong to the chmgr group.

Sounds exactly like a job for the Match directive within a standard
sshd_config (openssh-server).

Chris

--
To UNSUBSCRIBE, email to debian-us...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listm...@lists.debian.org

Archive: http://lists.debian.org/ofhlpax...@news.roaima.co.uk

[Balint Szigeti]

Hello

I'm so sorry to cite from a website but when I tried to send the link of the site I got a bounce error from lists.debian... so here is the site:

This came up today where I needed to give secure file transfer to customers. To complicate things I had to use an out-of-the-box RHEL6 system. The obvious answer was to use SSH and limit those users to SFTP only. Locking them into a chroot was not a requirement, but it seemed like a good idea to me. I found plenty of docs that got 80% of the way, or took a shortcut, but this should be complete.

The basic steps are:

1. Create a group and the users to that group
2. Modify the SSH daemon configuration to limit a group to sftp only
3. Setup file system permissions
4. Configure SELinux
5. Test (of course)

Without further ado, lets get started. It should only take about 10 minutes, nothing here is especially complex.

Create a group that is limited to SFTP only and a user to be in that group.

1 2 3

groupadd sftponly useradd sftptest usermod -aG sftponly sftptest

Now you need to make a little change to /etc/ssh/sshd_config. There will be a Subsystem line for sftp which you need to change to read:

1	Subsystem sftp internal-sftp

Now you need to create a block at the end to limit members of a group (ie the sftponly group you created above) and chroot them. Simply add the following to the end of the file:

1 2 3 4 5

Match Group sftponly ChrootDirectory %h ForceCommand internal-sftp X11Forwarding no AllowTcpForwarding no

These changes will require a reload of the SSH daemon: service sshd reload

Now you need to make some file permission changes. For some reason which I cannot work out for now, the home directory must be owned by root and have the permissions 755. So we will also need to make a folder in the home directory to upload to and make that owned by the user.

1 2 3 4

sudo -u sftptest mkdir -pv /home/sftptest/upload chown root. /home/sftptest chmod 755 /home/sftptest chgrp -R sftponly /home/sftptest

The last thing we need to do is tell SELinux that we want to upload files via SFTP to a chroot as it is read-only by default. Of course you are running SELinux in enforcing mode aren’t you :)

1	setsebool -P ssh_chroot_rw_homedirs on

Now from another console you can sftp to your server

1	sftp sftptest@<server>

You should then be able to put a file in your upload folder. However if you try to ssh to the server as the user sftptest it should tell you to go away. Of course you should be able to ssh as your normal user with no problem. Pro tip: make sure to leave a root terminal open just in case.

I'm sure it can be used on Debian as well.

Balint


On 04/01/14 15:30, emmanuel segura wrote:

Match User user01
    ChrootDirectory /home
    ForceCommand internal-sftp
    X11Forwarding no
    AllowTcpForwarding no

Match User user02
    ChrootDirectory /home
    ForceCommand internal-sftp
    X11Forwarding no
    AllowTcpForwarding no

useradd -m user01 && useradd -m user02

chmod 300 /home/user02

restart sshd daemon

[root@nod01 ~]# sftp user02@localhost
user02@localhost's password:
Connected to localhost.
sftp> cd user02
sftp> ls
remote readdir("/user02"): Permission denied
sftp> mkdir hello

In few words, the user user02  can only write and user user01 can write and read

2014/1/4 Chris Davies <ch...@roaima.co.uk>

--
esta es mi vida e me la vivo hasta que dios quiera

[emmanuel segura]

Match User user01
    ChrootDirectory /home
    ForceCommand internal-sftp
    X11Forwarding no
    AllowTcpForwarding no

Match User user02
    ChrootDirectory /home
    ForceCommand internal-sftp
    X11Forwarding no
    AllowTcpForwarding no

useradd -m user01 && useradd -m user02

chmod 300 /home/user02

restart sshd daemon

[root@nod01 ~]# sftp user02@localhost
user02@localhost's password:
Connected to localhost.
sftp> cd user02
sftp> ls
remote readdir("/user02"): Permission denied
sftp> mkdir hello

In few words, the user user02  can only write and user user01 can write and read

2014/1/4 Chris Davies <ch...@roaima.co.uk>

Bob Goldberg <bobg...@gmail.com> wrote:

[Chris Bannister]

[Please don't top post on this mailing list.]

On Sat, Jan 04, 2014 at 03:34:58PM +0000, Balint Szigeti wrote:
> Hello
>
> I'm so sorry to cite from a website but when I tried to send the
> link of the site I got a bounce error from lists.debian.

That is weird! I suggest it wasn't just a simple copy and paste,
otherwise it wouldn't have happened.

--
"If you're not careful, the newspapers will have you hating the people
who are being oppressed, and loving the people who are doing the
oppressing." --- Malcolm X

--
To UNSUBSCRIBE, email to debian-us...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listm...@lists.debian.org

Archive: http://lists.debian.org/20140105021052.GB5090@tal

[Bob Goldberg]

On Sat, Jan 4, 2014 at 7:26 AM, Sven Hoexter <sv...@timegate.de> wrote:

I'm not sure how the OpenSSH implementation handles ACLs, maybe that's

an option but I did not test it.

my first problem is successfully logging in with sftp-only and chroot'ing in place. AFAIK - ACL's would only come into play afterward.

  

Then there is Proftpd which has a mod_sftp extension.

And there are still the solutions which predate the chroot() and sftp-internal
implementation possible with OpenSSH like
- scponly
- rssh
- rush

All of them have a somewhat mixed security record and have some cost in
terms of chroot setup and mainting them properly.

Sven, TX much for your reply...

proftpd:  

1) wheezy does not have an sftp module

2) proftpd appears to rely on openssh for sftp, so appears to add no value.

3) IF proftpd did provide working sftp - appears that it can not share port 22 w/ openssh (which i do still need for full-access users unrelated to SFTP).

scponly:  does not appear to be provided in wheezy !?!? can't find out why....

rssh/rush:

1) not sure what is: diff rssh rush  (searches come up worthless to answer this)

2) i haven't used rssh in a very long time - i guess i have to dig into it again to see if it will allow chroot'ing with group "w" perms.

3) "mixed security record" is a big concern.

 

[Sven Hoexter]

On Mon, Jan 06, 2014 at 03:47:59PM -0600, Bob Goldberg wrote:
> On Sat, Jan 4, 2014 at 7:26 AM, Sven Hoexter <sv...@timegate.de> wrote:
>
> > I'm not sure how the OpenSSH implementation handles ACLs, maybe that's
> > an option but I did not test it.
>
>
> my first problem is successfully logging in with sftp-only and chroot'ing
> in place. AFAIK - ACL's would only come into play afterward.

Yes, but that should work. I read your mail as it does not work if you
enhance to the $HOME to group writeable or something like that.
I did not verify that case at all.

So I would start with setting it up user access only and try to add ACLs
to make it group writeable or whatever is required later on.

> proftpd:
> 1) wheezy does not have an sftp module

No,
$ cat /etc/debian_version
7.3
$ dpkg -L proftpd-basic|grep sftp
/usr/lib/proftpd/mod_sftp.so
/usr/lib/proftpd/mod_sftp_sql.so
/usr/lib/proftpd/mod_sftp_pam.so

> 2) proftpd appears to rely on openssh for sftp, so appears to add no value.

No, it's a standalone implementation.

> 3) IF proftpd did provide working sftp - appears that it can not share port
> 22 w/ openssh (which i do still need for full-access users unrelated to
> SFTP).

True, you can of course do nasty quirks with iptables to NAT to different ports
depending on the source IP. But that is really nasty.

> scponly: does not appear to be provided in wheezy !?!? can't find out
> why....

[Date: Mon, 23 Jan 2012 22:09:19 +0000] [ftpmaster: Luca Falavigna]
Removed the following packages from unstable:

scponly | 4.8-4.1 | source, amd64, armel, armhf, hurd-i386, i386, ia64, kfreebsd-amd64, kfreebsd-i386, mips, mipsel, powerpc, s390, sparc
scponly-full | 4.8-4.1 | amd64, armel, armhf, hurd-i386, i386, ia64, kfreebsd-amd64, kfreebsd-i386, mips, mipsel, powerpc, s390, sparc
Closed bugs: 650590

------------------- Reason -------------------
RoQA; RC buggy, unmaintained, replacement exists
----------------------------------------------

from https://ftp-master.debian.org/removals-2012.txt

Though nothing prohibits you from building a package based on the last version
found on snapshot.debian.org or just use the source Luke. ;)

> rssh/rush:
> 1) not sure what is: diff rssh rush (searches come up worthless to answer
> this)

Different implementation/software for a similar/same task.

> 3) "mixed security record" is a big concern.

Well I can mostly speak for the scponly case: Parsing commandline arguments
in a safe way for different tools like svn, rsync etc. is hard. If you disable
most of that and only stick to the sftp support it's quite solid.

Still if I've a chance I would try to rely on the sftp-internal and chroot()
functionallity of OpenSSH.

Sven
--
we live we love we learn and breathe
each breath we take makes me believe that we can take this road forever
if we take this road together
[ AZ0 - Endless Roads ]

--
To UNSUBSCRIBE, email to debian-us...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listm...@lists.debian.org

Archive: http://lists.debian.org/2014010709...@timegate.de

[Bob Goldberg]

Sven;

tx again, for your reply...

my only interest is sftp - so maybe scponly/rssh is worth looking at....

i've ruled out proftpd on the port 22 issues alone. so failing rssh, i guess i'll just have to deal with added directory layers, and "stock" openssh; though still toying with idea of mysecureshell; have used it previously with good results, but really wanted to try to stay true to the dist. this time around....

actually just had a thought - i didn't try doing a root:root chmod 750, and then over-riding with a group-specific acl. wonder if chroot would behave well in that "cross-circuit"... :-)