LinuxQuestions.org - Trying to use jail users to home directories

- Linux - Security (https://www.linuxquestions.org/questions/linux-security-4/)

- - Trying to use jail users to home directories (https://www.linuxquestions.org/questions/linux-security-4/trying-to-use-jail-users-to-home-directories-913610/)

Trying to use jail users to home directories

Ubuntu Server 10.04LTS
OpenSSH 5.3

I am trying to restrict users of a file share server to their own home directories when they access it over SSH. I have several several HOWTOs and so on. I am trying to keep things simple, so I am sticking to the security which comes with OpenSSH and chroot.

I have created a test user called johndoe.
Following a HOWTO, I changed the ownership of /home/johndoe to root, but gave the permissions as 775 - so that johndoe can create folders and write as well.

So far, I could access johndoes account from another PC and read/write/edit files and directories.

But the user can browse upwards to /home, / and everywhere else, such as others home directories.

Because I also have a common shared directory, /public, I have created the group "public" so that all users in that group can access that folder as well - but that's another issue.

I then added chroot details to sshd_config:

Code:

Port 22

Protocol 2

HostKey /etc/ssh/ssh_host_rsa_key

HostKey /etc/ssh/ssh_host_dsa_key

UsePrivilegeSeparation yes



KeyRegenerationInterval 3600

ServerKeyBits 768



SyslogFacility AUTH

LogLevel INFO



LoginGraceTime 120

PermitRootLogin yes

StrictModes yes



RSAAuthentication yes

PubkeyAuthentication yes



IgnoreRhosts yes

RhostsRSAAuthentication no

HostbasedAuthentication no



PermitEmptyPasswords no



ChallengeResponseAuthentication no



X11Forwarding no

PrintMotd no

PrintLastLog yes

TCPKeepAlive yes



AcceptEnv LANG LC_*



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



UsePAM yes



Match group public

        ChrootDirectory /home/%u

        X11Forwarding no

        AllowTcpForwarding no

        ForceCommand internal-sftp

But, after restarting the server, I cannot log in as user johndoe. I get the error message:

Quote:

Could not display "sftp://
johndoe@192.168.1.100/home/johndoe"
Error: ssh program unexpectedly exited
Please select another viewer and try again

.

If I remove the Match... bit and all that follows from sshd_config, then I get access back.

So far, all problems I have had setting up this file share have had real simple, obvious fixes - i have been thinking "too deep" and trying to find complicated answers! I hope this is also the case... ;)

Monitor /var/log/messages or /var/log/secure on the server while trying to log in remotely. E.G. "tail -f /var/log/messages".

I created a jdoe user on my netbook. Trying to sftp with your sshd_config options "sftp -i id_rsa.jdoe jdoe@netcow"

I read this in /var/log/messages:

Code:

Nov 15 04:16:08 netcow sshd[9094]: Accepted publickey for jdoe from 192.168.1.100 port 41196 ssh2

Nov 15 04:16:08 netcow sshd[9103]: fatal: chroot into directory without nodev or nosuid

This howto might help.
https://calomel.org/sftp_chroot.html

You may need to change from /home/ to another directory, mounted with the proper restrictions. If there are regular users who can log into this server, you can change the home directories of the sftp users to this new directory in the /etc/passwd file. Another howto said to have the home directories like /ftp/./username/. I also don't know about the patch the howto mentions. It may depend on which version of openssh you are using.

I hope this gets you started anyway.

Someone on IRC mentioned that they have sftp-server as the persons login shell instead of a chroot setup.

However, this doesn't restrict the users to a jail. So it wouldn't be good for public access. (I.E. one client, the only user, who needs broader access)

Thanks for the tips.
I looked at /var/log/messages, but there was no references to sshd or the attempts. I ls'ed /var/log but could not find any log named "secure".

I have seen that particular HOWTO, and it seems similar to the others. I have been folowing this one: Chroot in OpenSSH

Many of th eother HOWTOs talk about creating new directories and copying libraries and what-not over to them, so that shells can be used.

My users will only need to access there home directory with a file manager type application, such as Nautilus and FileZilla. So, from what I gather, I shouldn't need anything too complicated...

I simiplified the "Match" bit of sshd_config to read:

Code:

Match user johndoe

        ChrootDirectory /home

        ForceCommand internal-sftp

Since /home is owned by root, in theory it ought to work. But is doesn't.

Firstly, could you post the version of openSSL you have. I believe the chroot support by sshd is for later versions.

The howtos that mention creating some system directories, files and device nodes in the chroot directory are for chrooting ssh itself. From the manpage for sshd_config:

Code:

In the special case when only sftp is used, not ssh nor scp, it is possible to use

ChrootDirectory %h or ChrootDirectory /some/path/%u. The ﬁle system containing this

directory must be mounted with options nodev and either nosuid or noexec. The owner of the direc-

tory should be the user. The ownership of the other components of the path must fulﬁll the usual

conditions. No additional ﬁles are required to be present in the directory.

There is also a manpage for sftp-server that might be useful. More is required if you want to enable logging according to the sshd_config manpage.

I'm using OpenSSH 5.3, which should support the ChrootDirectory options.
Every HOWTO I read seems to have something different...

Quote:

The owner of the directory should be the user.

All the HOWTOs I have reas say that the directory to be chrooted should be own by root.

Quote:

The ownership of the other components of the path must fulﬁll the usual conditions.

Does this mean the usual perssions and such as when you installed the OS, or "usual conditions" for chrooting?

The one I have been looking at this morning also says that the user's shell be disabled with usermod -s /bin/false - when I did that, I could not login either. I set the shell back to bash and it works.

We will only be using sftp - the clients to be used are FileZilla for Windows & Linux and Nautilus for Linux.

I "just" want to restrict the users to their own home directories, and allow access to a public directory:
/home/user1 -> accessible by user1 only
/home/user2 -> accessible by user2 only
/home/usern -> accessible by usern only
/home/public -> accessible by all users

Quote:

The ﬁle system containing this directory must be mounted with options nodev and either nosuid or noexec.

I'll look into this now...

OK, following this HOWTO: Setup of a chroot'd SFTP only server

Note: adminuser and user1 are just covers for the real account names as real names are used.
I have replaced the group ftp with public and the directory /jail_ftp with /public.

1. Added to sshd_config:

Code:

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



AllowUsers root adminuser user1



Match Group public

        ForceCommand internal-sftp

        ChrootDirectory /public

#        X11Forwarding no

#        AllowTcpForwarding no

Restarted SSH server with restart ssh.

2. Made sure ownership of /public directory was root:
chown root:root /public
chmod 750 /public

Also create additional directory /public/user1
ls -l / returns:

Code:

drwxr-x--- 5 root root 4096 2011-11-16 12:46 public

Compared to the HOWTO's example of:

Code:

drwxr-x--- root ftp 1000 Jan 1 10:10 /ftp_jail

It looks OK.

I also checked that the user user1 was in the public group:
cat /etc/group returns:

Code:

user1:x:1001

public:x:1002:root,adminuser,user1

But still, I cannot log in to the server.

If I remove Match and all after from sshd_config, restart the server, I can then log in.

The only reference in any logs I can find is:
/var/log/auth.log

Code:

Nov 16 15:20:26 server01 sshd[4622]: pam_sm_authenticate: Called

Nov 16 15:20:26 server01 sshd[4622]: pam_sm_authenticate: username = [user1]

Nov 16 15:20:26 server01 sshd[4622]: Accepted password for user1 from 192.168.1.34 port 44190 ssh2

Nov 16 15:20:26 server01 sshd[4622]: pam_unix(sshd:session): session opened for user user1 by (uid=0)

Nov 16 15:20:26 server01 sshd[4697]: subsystem request for sftp

Nov 16 15:20:26 server01 sshd[4622]: pam_unix(sshd:session): session closed for user user1

Maybe this howto will work better for you:
http://www.techrepublic.com/blog/ope...irectories/229

However it does sound, from the sshd_config man page, that you need to have chroot directory on it's own partition, so you can mount with the noexec, nosuid & nodev options.

Test it with a user who can only use sftp, not one who can log in.

You can mount a directory over a mount point, and the remount the new mount point with new options:
mount --bind /home /srv/ftp
mount -o nodev,nosuid /srv/ftp

In the first command, using --rbind instead will also move filesystems mounted inside the first directory. --bind will not.

Code:

sudo mount --rbind /home /home2

sudo mount -o nodev,remount /home2



mount | grep /home

/dev/sda7 on /home type ext4 (rw,relatime,user_xattr,acl,barrier=1,data=ordered)

gvfs-fuse-daemon on /home/jschiwal/.gvfs type fuse.gvfs-fuse-daemon (rw,nosuid,nodev,relatime,user_id=1000,group_id=1000)

/dev/sda7 on /home2 type ext4 (rw,nodev,relatime,user_xattr,acl,barrier=1,data=ordered)

gvfs-fuse-daemon on /home2/jschiwal/.gvfs type fuse.gvfs-fuse-daemon (rw,nosuid,nodev,relatime,user_id=1000,group_id=1000)

If for your case /home isn't on it's own partition, that could be what you need. Satisfy the mount option requirements, even if your sftp chroot directory isn't on it's own partition.

Thanks for the help, gents. However, it has become a mute point - the company I worked has gone bust... However, I'm still sort of playing with problem at home, as I would like to find the fix. The Tech Republic link looks good.

chroot jail for ssh users

aes canis,
Here's a thread on your topic that was published on LQ a while back.
http://www.linuxquestions.org/questi...3/#post4285554