Prevent rssh users from leaving their jail directories

Question

I'm attempting to use rssh to jail users strictly to their /home/user/public_html dirctories. I got it to work where an account can SFTP into the system successfully on a test server, but once I login as that account, I noticed that I can change directories to anywhere I wish and view the contents of files. I may not be able to edit or transfer to those directories, but I thought the whole purpose of being able to jail them was to prevent such a thing?

SSHD is set up with Subsystem sftp internal-sftp RSSH has the user designated as only able to use scp and sftp The user's account is using /usr/bin/rssh for the shell and /home/user/public_html User's home directory is root:user owner:group

I have noticed though that the only files that they can view the contents of and directories that they can cd into are all world readable, which makes sense, but why are they allowed to leave they're directory at all? And please don't say that I just answered my own question. The purpose is to find the best-practice solution for preventing this.

The desired outcome is that they are restricted any ability to cd to any directory not owned by them.

Am I missing something here?

---

Here's the contents of the rssh.conf file;

logfacility = LOG_USER

allowscp
allowsftp
#allowcvs
#allowrdist
#allowrsync
#allowsvnserve

# set the default umask
umask = 022

user=wwwtest1:077:110000:/home/wwwtest1/public_html

---

And here's the contents of the sshd_config file;

# Package generated configuration file
# See the sshd_config(5) manpage for details

# What ports, IPs and protocols we listen for
Port 22
# Use these options to restrict which interfaces/protocols sshd will bind to
#ListenAddress ::
#ListenAddress 0.0.0.0
Protocol 2
# HostKeys for protocol version 2
HostKey /etc/ssh/ssh_host_rsa_key
HostKey /etc/ssh/ssh_host_dsa_key
HostKey /etc/ssh/ssh_host_ecdsa_key
#Privilege Separation is turned on for security
UsePrivilegeSeparation yes

# Lifetime and size of ephemeral version 1 server key
KeyRegenerationInterval 3600
ServerKeyBits 768

# Logging
SyslogFacility AUTH
LogLevel INFO

# Authentication:
LoginGraceTime 120
PermitRootLogin yes
StrictModes yes

RSAAuthentication yes
PubkeyAuthentication yes
#AuthorizedKeysFile     %h/.ssh/authorized_keys

# Don't read the user's ~/.rhosts and ~/.shosts files
IgnoreRhosts yes
# For this to work you will also need host keys in /etc/ssh_known_hosts
RhostsRSAAuthentication no
# similar for protocol version 2
HostbasedAuthentication no
# Uncomment if you don't trust ~/.ssh/known_hosts for RhostsRSAAuthentication
#IgnoreUserKnownHosts yes

# To enable empty passwords, change to yes (NOT RECOMMENDED)
PermitEmptyPasswords no

# Change to yes to enable challenge-response passwords (beware issues with
# some PAM modules and threads)
ChallengeResponseAuthentication no

# Change to no to disable tunnelled clear text passwords
#PasswordAuthentication yes

# Kerberos options
#KerberosAuthentication no
#KerberosGetAFSToken no
#KerberosOrLocalPasswd yes
#KerberosTicketCleanup yes

# GSSAPI options
#GSSAPIAuthentication no
#GSSAPICleanupCredentials yes

X11Forwarding yes
X11DisplayOffset 10
PrintMotd no
PrintLastLog yes
TCPKeepAlive yes
#UseLogin no

#MaxStartups 10:30:60
#Banner /etc/issue.net

# Allow client to pass locale environment variables
AcceptEnv LANG LC_*

#Subsystem sftp /usr/lib/openssh/sftp-server
Subsystem sftp internal-sftp

# Set this to 'yes' to enable PAM authentication, account processing,
# and session processing. If this is enabled, PAM authentication will
# be allowed through the ChallengeResponseAuthentication and
# PasswordAuthentication.  Depending on your PAM configuration,
# PAM authentication via ChallengeResponseAuthentication may bypass
# the setting of "PermitRootLogin without-password".
# If you just want the PAM account and session checks to run without
# PAM authentication, then enable this but set PasswordAuthentication
# and ChallengeResponseAuthentication to 'no'.
UsePAM yes

---

Solution

Don't bother with rssh and creating jails if all you need is sftp. Recent versions of openssh-server can chroot sftp users for you if you are using the internel sftp server. If, for instance, you want to chroot all users of a certain group to their home directories, you can add this to sshd_config:

Match Group sftp-only
    ChrootDirectory %h
    ForceCommand internal-sftp
    AllowTcpForwarding no

Comments

[Zoredache]

What documentation were you following related to rssh? Can you post your rssh.conf? What command did you use to create your jail? Can you post the your sshd_config?

[Skittles]

Okay...there's the file contents as you requested. As for the question about what command I used to jail them, could you please elaborate on that?

[Zoredache]

You have to build a jail environment, you cannot just add something to a the rssh.conf file and be done. How you build your jail depends on what *nix/distro you are using. Some provide you with tools to do this, others you have to work at it quite a bit. On a Debian system you might use a tool like makejail.

[user606723]

rssh doesn't just jail by nature. You need to use chroot in order to create the jail. I think you may need to do a bit more research. =) Search on 'chroot jail'.

[Skittles]

I am on a Ubuntu server, so yeah, that Debian side of things is applicable. It would seem that the use of makejail sounds like they make a point of knowing what you are doing to use it. And my post today obviously is an indicator of my experience with this part of server admin stuff. Any working examples you can think of that I could perhaps use as a guide maybe?

[stew]

what version of openssh-server do you have installed? do the users need services besides sftp? or do they just need sftp?

[Skittles]

No, my users will not be given shell access. Just SFTP is all I wish to permit. I found a script in this article, brudvik.org/2011/02/chrootjail-sftpscpssh-on-ubuntu Do you think this is acceptable? I tried it and it seemed to work great. The only remaining issue I'm having is that I can leave the home directory and see anything that's world readable still via WinSCP.

[Zoredache]

If you only want sftp, then you shouldn't be using a chroot/rssh. You are making things far to complicated and using outdated docs. Use the ForceCommand examples. All you need to do is do a few tweaks your sshd configuration.

[Skittles]

I appreciate where you're going with this, but again I have to state that the real issue I cannot seem to get solved at this point is that I login to the server now with WinSCP, but can leave the home directory and can peruse the entire system at my leisure viewing the contents of any file that has world readable permissions. If I can get that aspect of this resolved, I will be extremely grateful.

[Skittles]

The logged in user must not be able to leave their directory under any circumstances.

[Zoredache]

Which tells me that you missed a step setting up the ssh see Stew's answer.

[Skittles]

I actually did perform Stew's suggestion. I modified it to instead be using Match User rather than Match Group as I wish to restrict on a per user basis. But when I have that in there, it won't let me login at all. I have to be missing something really simple here.

[Skittles]

I changed the definition as you said and you were right, it was incorrect according to the man page. I'm beginning to fear that I have missed something critical in all this though. No matter what I change, when I log into this account via WinSCP, I can still cd to anywhere in the server and view file contents as long as they're world readable. Fixing this has GOT to be much easier than it's turning into.

[Skittles]

Well...I'm not sure what I have done that fixed it because of the slew of things I've attempted, but I'm going to accept this answer and try restarting from scratch to see if I can better trace my steps. Thanks.

[Alex G]

This solution requires ChrootDirectory to be owned by root, this is not practical in my case