Exclude a single group user from chroot jail?

English Network/Internet
#1

I have successfully set up an sftponly group whose users are put into chroot jail upon sftp connection to an opensuse 13.2 system. The opensuse “cookbook” for doing this can be viewed here: https://en.opensuse.org/SDB:SFTP_server_with_Chroot

These are the modifications to /etc/ssh/sshd_config

# override default of no subsystems
# Original commented out and internal-sftp added
#Subsystem      sftp    /usr/lib/ssh/sftp-server
Subsystem       sftp    internal-sftp
Subsystem internal-sftp -l INFO

and then added at bottom of the file:

Match group sftponly
   ForceCommand internal-sftp
   ChrootDirectory /sftproot/%u
   X11Forwarding no
   AllowTcpForwarding no

This works really well for a user that is set up when the only group to which the restricted usert is a member only of the sftponly group. The user logs in via their sftp client and cannot go higher than their chroot home. Yay!

Now I have a new requirement that a “typical” user of the system (pre-defined long ago before the sftponly environment for sftp users was added) needs to be able to read some of the files uploaded by the sftp users to a directory beneath their chroot jail home. I think to myself, "No problem. I’ll just add olduserid to the sftponly group, and as long as group-read permission is set for the uploaded file from the sftpuser and group owner is sftoponly, olduserid should be able to read the file. I issue

usermod -a -G sftponly olduserid

so that “olduserid” is now also a member of the sftponly group in addition to its other groups.

I try to ssh login to “olduserid” like I normally do and the login fails because ssh matched the Group sftponly and there has been no chroot home directory set up for olduserid. Syslog shows

 Accepted keyboard-interactive/pam for olduserid from ::1 port 35093 ssh2
 pam_unix(sshd:session): session opened for user olduserid by (uid=0)
 pam_unix(systemd-user:session): session opened for user olduserid by (uid=0)
 fatal: chroot into directory without nodev and either noexec or nosuid
 pam_unix(sshd:session): session closed for user olduserid
 pam_unix(systemd-user:session): session closed for user olduserid

This was interesting as the default group for olduserid was the same as it was before. Nevertheless, some quick googling and I found the suggestion to change the “Match” statement from what I posted above to this:

Match group sftponly, User !olduserid

I make the change and systemctl reload sshd to pick up the change.

This fixes the inability to ssh login olduserid to the expected results and the olduserid can login as before. But the unexpected side effect seems to be that the change breaks the chroot jail for the other sftponly group members who should stay in their chroot jail. WIth an sftp client from a different Linux server, I was able “cd” all the way up into the system root directory. If I remove the “, User !olduserid” from the “Match” line, then the sftp chroot jail for an sftp user whose group is sftponly returns to the desired jail.

Not sure if I have misunderstood or incorrectly implemented the suggested solution. This was the site where I read the suggestion. http://serverfault.com/questions/641470/exclude-a-single-user-from-chroot

Any help is appreciated.

#2

Further reading found a solution, but it is referred to as a bug in Match pattern matching on the page where I found the solution. I don’t know if it is a bug or a user error by me. The thread was from 2011.

Source of solution for me was on this page: https://bbs.archlinux.org/viewtopic.php?id=121945

This worked correctly to not break the chroot jail for the members of the sftponly group while excluding olduserid from the match when olduserid logged in via ssh.

Match group sftponly, User *,!olduserid
#3

Not answering your question directly, but you might note

  • The “History” of the article reveals that most of the article was created and largely modified 2010/2011
  • Has a note on the page created Jan 2015 requesting that the page be reviewed and possibly updated.
  • The SDB largely describes setting up SSHD and an ftp directory in the chroot, it does not describe securing the chroot (which requires much more than a simple, basic chroot). So, just wondering if you’ve done everything necessary to secure your chroot… else see what I describe next.

Since 2010, there are other technologies you may want to consider instead of a chroot.

The following are similar to a chroot, but automatically secure in various ways:
systemd-nspawn. Of the various chroot alternatives, this most closely resembles a chroot, particularly in that you have an isolated file tree and you can copy files directly from the Host to the isolated OS if you wish. Improved security is implemented by applying its own unique namespace to running processes.

docker. Uses Linux containers instead of a chroot-style file isolation. Greater isolation which means greater security if you don’t often copy files in and out of the Guest.

LXC. Also uses Linux containers but differently than docker.

The above choices set up an isolated GuestOS like a chroot with little to no overhead unlike paravirtualization like VirtualBox (and others).

TSU

#4

Thanks for taking a moment to reply with good suggestions. I will investigate the suggestions as time allows. For now, sftp will have to suffice for the owner of the system.

I realize the article that I cited is out of date, but felt it might be appreciated if it was openSUSE in origin more than a different site’s. In reality, I used http://en.wikibooks.org/wiki/OpenSSH/Cookbook/SFTP primarily as a reference when implementing the sftp chroot environment. It was more complete and up to date, including info on logging to a syslog file for a chroot environment even though the internal-sftp program is run for the sftp clients. I implemented the logging by having a /dev/log in each users chroot jail with permissions that prevent alteration as discussed in “Logging chrooted sftp” on http://en.wikibooks.org/wiki/OpenSSH/Logging. The sftp users have /bin/false specified as their login shell, so they are restricted from the flexibility that a shell (e.g. bash) would normally offer via ssh or scp. The Match block matching the group name in sshd_config is the first line of defense from getting other than an sftp connection.

$ ssh sftpuser@remotesys
Password: 
Could not chdir to home directory /sftproot/sftpuser: No such file or directory
This service allows sftp connections only.
Connection to remotesys closed.
$ scp junk sftpuser@remotesys:.
Password: 
This service allows sftp connections only.
Connection to remotesys closed.

So far, everything seems locked down sufficiently (I know. Famous last words).