[SOLVED] how to add users with limited access: no shell, chroot, etc.

sneakyimp · 04-28-2016, 10:18 AM

I'm setting up an Ubuntu 14.04 LTS server and in the process of creating some user accounts we need. In the interest of security, I want to limit these accounts to the bare minimum they need to function. I don't have much experience setting up users and groups so I could use some help.

We have a need for 3 basic types of user:
* PartnerUser - needs to deliver files via FTP to our machine. Should be confined to only their home directory and should NOT have a shell.
* CronUser - user under which we define cron jobs for the cron jobs of our web site. No one should be able to connect via SSH as this user, but the user must be able to execute cron jobs and should be constrained to the /var/www directory.
* DevUploadUser - a single user with permission to upload source code for our web application via SFTP. This user should not have any shell access and should be constrained to /var/www folder.

Can anyone suggest a scheme to accomplish these objectives? I've been reading about chrooting and it seems really complicated and poorly explained. Also, as for granting SFTP access but no shell (or vice versa), I'm familiar with specifying /bin/false when using the adduser command to prevent users from having shell access, but I'm thinking this would also prevent SFTP access too?

suicidaleggroll · 04-28-2016, 10:43 AM

chroot can be complicated, but it doesn't have to be. I've found jailkit to work quite well, and I regularly use it for dummy accounts on my machines that will allow rssh tunnels to connect but prevent shell access. I'm sure you could allow sftp connections as well with very little effort.

My own personal notes on setting up jailkit on CentOS 6 and using it to create and configure an account with ssh access but no shell (IE: it can create ssh tunnels but not actually ssh in) is as follows:

Code:

mkdir ~/src
mv jailkit-2.17.tar.gz ~/src
cd ~/src
tar xaf jailkit-2.17.tar.gz
cd jailkit-2.17
./configure
make
su
make install
cp extra/jailkit /etc/init.d/jailkit
chmod a+x /etc/init.d/jailkit
chkconfig jailkit on
mkdir /home/jail
jk_init -j /home/jail jk_lsh
jk_init -j /home/jail ssh
jk_init -j /home/jail basicshell
groupadd -g 4006 rssh_user
useradd -m -g 4006 -u 4006 rssh_user
passwd rssh_user
jk_jailuser -j /home/jail/ rssh_user
/etc/init.d/jailkit restart

Presumably you could add a line for sftp in the jk_init part to enable sftp access, but you should refer to their documentation for more.

Turbocapitalist · 04-28-2016, 11:13 AM

Quote:

Originally Posted by sneakyimp

Also, as for granting SFTP access but no shell (or vice versa), I'm familiar with specifying /bin/false when using the adduser command to prevent users from having shell access, but I'm thinking this would also prevent SFTP access too?

If you look at the ChrootDirectory option in the manual page for sshd_config, you see that the chroot target directory has to be owned by root and not writable by anyone else. That's the major difficulty with chrooted SFTP. If you leave /var/www writable, then you're limited to something like this:

Code:

Subsystem sftp internal-sftp

Match Group sftp-only
        ChrootDirectory /var/foo
        AllowTCPForwarding no
        X11Forwarding no
        ForceCommand internal-sftp -d /www

But that would let the users up into /var where they could still rummage around in the subdirectories there.

So, you can put www into a subdirectory. Say you have /var/foo/www where /var/foo is owned by root and not writeable by anyone else:

Code:

Subsystem sftp internal-sftp

Match Group sftp-only
        ChrootDirectory /var
        AllowTCPForwarding no
        X11Forwarding no
        ForceCommand internal-sftp -d /www

That means also adjusting the web server's document root and related items in its configuration.

sneakyimp · 04-28-2016, 05:19 PM

OK things just got very serious. I learned that a user (PartnerUser in my example above) added to the production server can read all of our web source, including config files which contain database, mail, and payment gateway credentials. We've no reason to think this person will abuse their account, but this has got to be fixed.

More specifically, someone created a user for the account and thought that limiting their shell would prevent abuse. This is the entry in /etc/passwd:

Code:

$ grep partneruser /etc/passwd
partneruser:x:1234:1235::/home/partneruser:/usr/libexec/openssh/sftp-server

Unfortunately, once they login (using a password NOT a key) then they can simply

Code:

ls /var/www/html
get /var/www/html/some-sensitive-file.php

I thought I might change the permissions on the entire webroot to be 770 for dirs and 660 for files but this would prevent apache from being able to serve the files. Any suggestions for a quick fix to the production server would be welcome.

suicidaleggroll, that jailkit thing looks very promising. Am I correct in understanding this is the official source: http://olivier.sessink.nl/jailkit/

I also have some other questions:

What does this do?

Code:

chkconfig jailkit on

Doesn't that establish jailkit as some kind of startup daemon or something? Seems weird to me that we would need a startup process to jail some user/process.

Am I correct in thinking that these commands copy or link certain necessary binaries into the jail so the jailed user can actually do something?

Code:

jk_init -j /home/jail jk_lsh
jk_init -j /home/jail ssh
jk_init -j /home/jail basicshell

Why are we creating a jailed user with a specific uid?

Code:

groupadd -g 4006 rssh_user
useradd -m -g 4006 -u 4006 rssh_user
passwd rssh_user

This approach toward user addition seems really unusual. Why not just adduser?

This jails user rssh_user to /home/jail and they can never get out, right?

Code:

jk_jailuser -j /home/jail/ rssh_user

So this line looks like jailkit runs as a daemon and we have to restart it every time we jail a new user, right?

Code:

/etc/init.d/jailkit restart

Thanks for the responses, by the way!

sneakyimp · 04-28-2016, 05:33 PM

Quote:

Originally Posted by Turbocapitalist

If you look at the ChrootDirectory option in the manual page for sshd_config, you see that the chroot target directory has to be owned by root and not writable by anyone else. That's the major difficulty with chrooted SFTP.

I do in fact see this in the man pages. Ignoring for a moment my desire to jail someone in /var/www, how might I go about jailing PartnerUser to their home directory immediately?

Quote:

Originally Posted by Turbocapitalist

If you leave /var/www writable, then you're limited to something like this:

Code:

Subsystem sftp internal-sftp

Match Group sftp-only
        ChrootDirectory /var/foo
        AllowTCPForwarding no
        X11Forwarding no
        ForceCommand internal-sftp -d /www

Ok the Subsystem entry in the man page is totally confusing. It assumes some deeper understanding that I simply lack:

Code:

     Subsystem
             Configures an external subsystem (e.g. file transfer daemon).  Arguments should be a subsystem
             name and a command (with optional arguments) to execute upon subsystem request.

             The command sftp-server(8) implements the “sftp” file transfer subsystem.

             Alternately the name “internal-sftp” implements an in-process “sftp” server.  This may simplify
             configurations using ChrootDirectory to force a different filesystem root on clients.

             By default no subsystems are defined.  Note that this option applies to protocol version 2
             only.

Quote:

Originally Posted by Turbocapitalist

But that would let the users up into /var where they could still rummage around in the subdirectories there.

This is not self-evident and I do not understand why. I guess I'll have to take your word for it that ChrootDirectory of /var/foo doesn't jail them in foo but they can also hit var?

Quote:

Originally Posted by Turbocapitalist

So, you can put www into a subdirectory. Say you have /var/foo/www where /var/foo is owned by root and not writeable by anyone else:

Code:

Subsystem sftp internal-sftp

Match Group sftp-only
        ChrootDirectory /var
        AllowTCPForwarding no
        X11Forwarding no
        ForceCommand internal-sftp -d /www

Still very confused. On my machine /var is owned by root:root and not writable by anyone else:

Code:

$ ls -dal /var
drwxr-xr-x 20 root root 4096 Mar  2  2014 /var

That means also adjusting the web server's document root and related items in its configuration.[/QUOTE]

suicidaleggroll · 04-28-2016, 07:10 PM

Quote:

Originally Posted by sneakyimp

I thought I might change the permissions on the entire webroot to be 770 for dirs and 660 for files but this would prevent apache from being able to serve the files. Any suggestions for a quick fix to the production server would be welcome.

Create a new privileged group, add apache and any users who need to access the files to the group, change the group ownership of the files to it, and then remove permissions from all others.

Quote:

Originally Posted by sneakyimp

suicidaleggroll, that jailkit thing looks very promising. Am I correct in understanding this is the official source: http://olivier.sessink.nl/jailkit/

yes

Quote:

Originally Posted by sneakyimp

What does this do?

Code:

chkconfig jailkit on

Doesn't that establish jailkit as some kind of startup daemon or something? Seems weird to me that we would need a startup process to jail some user/process.

Yes that enables the jailkit service so it starts on boot. I don't recall exactly what the jailkit service does, but I'm sure it's in their documentation.

Quote:

Originally Posted by sneakyimp

Am I correct in thinking that these commands copy or link certain necessary binaries into the jail so the jailed user can actually do something?

Code:

jk_init -j /home/jail jk_lsh
jk_init -j /home/jail ssh
jk_init -j /home/jail basicshell

Correct

Quote:

Originally Posted by sneakyimp

Why are we creating a jailed user with a specific uid?

Code:

groupadd -g 4006 rssh_user
useradd -m -g 4006 -u 4006 rssh_user
passwd rssh_user

I should clarify - the code I posted was not a suggestion of exactly what you should run, it was a literal copy and paste from my own personal documentation on setting up jailkit. Most of the entries in my documentation are not detailed descriptions of how to set things up, they're simply logs of what I actually ran when I set it up on a system. Therefore they can sometimes contain system-specific commands that don't exactly apply to the wider world. In this case, my systems use NFS pretty heavily, therefore it's important all users have a common UID/GID across all systems. For that reason, I make it a rule that when any user is added to any system on that network, it's assigned a globally unique UID/GID that will never conflict with any other users on any other systems. In this case, "rssh_user" was assigned UID/GID 4006, so that's what I was using. None of that is relevant to your application, you can create the user however you like, or skip that part if the user already exists.

Quote:

Originally Posted by sneakyimp

This approach toward user addition seems really unusual. Why not just adduser?

adduser is non-standard and is not installed by default (or even available) on many systems, including CentOS 6. It's a high level perl wrapper for useradd, actually. When it comes to basic system tools like user and group modification, I prefer to stick to the "real" tools rather than the high level distro-specific wrappers that may or may not be installed on any given system.

Quote:

Originally Posted by sneakyimp

This jails user rssh_user to /home/jail and they can never get out, right?

Code:

jk_jailuser -j /home/jail/ rssh_user

Correct. Inside /home/jail will be a trimmed down directory tree with its own bin, dev, etc directories. rssh_user's home directory will be /home/jail/home/rssh_user, but it will appear as if it's just /home/rssh_user to them. If any directories outside of this jail need to be accessible by the user, you can "mount --bind" them inside.

Quote:

Originally Posted by sneakyimp

So this line looks like jailkit runs as a daemon and we have to restart it every time we jail a new user, right?

Code:

/etc/init.d/jailkit restart

I don't recall to be honest.

sneakyimp · 04-28-2016, 08:41 PM

Quote:

Originally Posted by suicidaleggroll

Create a new privileged group, add apache and any users who need to access the files to the group, change the group ownership of the files to it, and then remove permissions from all others.

I think our situation is a little too tricky for a quick solution. Apache needs to read all the webroot files to serve them. It needs write privileges to *some* of them. We also need to grant read/write privileges to our dev_user to upload files. Some of the files and directories must be writable by some cron_user. At the very least, trying to achieve this is going to involve a thicket of not-entirely-mutually-exclusive groups. I think it would be easier to jail this one partneruser.

Quote:

Originally Posted by suicidaleggroll

I should clarify - the code I posted was not a suggestion of exactly what you should run...

I figured that much out and have been following the instructions on the source site here.

I've compiled jailkit on a testing server and am trying to get it to work without much luck. I performed these steps:

Code:

sudo groupadd -g 1004 sftpgroup
sudo useradd -m -g 1004 -u 1004 sftpuser
sudo passwd sftpuser

# the results
$ grep 1004 /etc/passwd
sftpuser:x:1004:1004::/home/sftpuser:
$ grep 1004 /etc/group
sftpgroup:x:1004:


### NOTE: at this point, I tested login and it worked fine.


# make a place to put jails
sudo mkdir /jail-test

# initialize the jail
sudo jk_init -v -j /jail-test sftp scp
sudo jk_init -v -j /jail-test jk_lsh

# jail the user
sudo jk_jailuser -m -j /jail-test sftpuser

The problem I'm having is that when I try to login, It seems to accept my password and then boots me immediately:

Code:

$ ssh sftpuser@example.com
sftpuser@example.com's password: 
Welcome to Ubuntu 14.04.4 LTS (GNU/Linux 3.13.0-85-generic x86_64)

 * Documentation:  https://help.ubuntu.com/
Last login: Fri Apr 29 01:32:06 2016 from w.x.y.z.socal.res.rr.com
Connection to example.com closed.

I'm wondering what went wrong. I don't see any daemon process running named jailkit when I do this:

Code:

ps aux | grep jailkit

I'd also point out that my username doesn't match my group name -- does that matter?

sneakyimp · 04-28-2016, 08:57 PM

OK I reviewed the installation steps and realized I had neglected to create the /etc/init.d stuff so I did the following:

Code:

# from the src dir
sudo cp extra/jailkit /etc/init.d/jailkit
sudo chmod a+x /etc/init.d/jailkit
# the following is modern ubuntu equivalent of chkconfig
sudo sysv-rc-conf jailkit on
sudo /etc/init.d/jailkit restart

the result of that last one

Code:

$ sudo /etc/init.d/jailkit restart
Stopping jailkit: jk_socketd/usr/sbin/jk_socketd: no process found
 done.
Starting jailkit: jk_socketd done.

I also checked for a running process and their does appear to be jk_socketd:

Code:

$ ps aux | grep jk
nobody    3984  0.0  0.0  14940   156 ?        Ss   01:45   0:00 /usr/sbin/jk_socketd
jadams    4034  0.0  0.0  11980   932 pts/1    R+   01:45   0:00 grep --color=auto jk

I ALSO made the edits to /jail-test/etc/jailkit/jk_lsh.ini and added this:

Code:

[sftpuser]
paths= /usr/bin, /usr/lib/
executables= /usr/bin/scp, /usr/lib/sftp-server

I still get problems whether trying ssh or sftp:

Code:

$ sftp sftpuser@example.com
sftpuser@example.com's password:  # i entered correct password
Connection closed

when i try to scp a file, it rejects my (correct) password repeatedly:

Code:

$ scp some-test-file sftpuser@example.com:~/
sftpuser@example.com's password: 
Permission denied, please try again.
sftpuser@example.com's password: 
Permission denied, please try again.
sftpuser@example.com's password:

I've checked the dir/file permissions on the jail home dir and it seems ok to me:

Code:

$ ls -al /jail-test/home/sftpuser
total 24
drwxr-xr-x 3 sftpuser sftpgroup 4096 Apr 29 01:31 .
drwxr-xr-x 3 root     root      4096 Apr 29 01:29 ..
-rw-r--r-- 1 sftpuser sftpgroup  220 Apr  9  2014 .bash_logout
-rw-r--r-- 1 sftpuser sftpgroup 3637 Apr  9  2014 .bashrc
drwx------ 2 sftpuser sftpgroup 4096 Apr 29 01:31 .cache
-rw-r--r-- 1 sftpuser sftpgroup  675 Apr  9  2014 .profile

I'm at a loss! Any help would be much appreciated.

sneakyimp · 04-28-2016, 09:12 PM

OK I checked /var/log/authlog and when I try this command:

Code:

$ sftp sftpuser@example.com
sftpuser@example.com's password: 
Connection closed

then this is the result in the log:

Code:

Apr 29 02:10:43 ubuntu-14 sshd[6263]: Accepted password for sftpuser from 11.22.33.44 port 37293 ssh2
Apr 29 02:10:43 ubuntu-14 sshd[6263]: pam_unix(sshd:session): session opened for user sftpuser by (uid=0)
Apr 29 02:10:43 ubuntu-14 jk_chrootsh[6282]: now entering jail /jail-test for user sftpuser (1004) with arguments -c /usr/lib/openssh/sftp-server
Apr 29 02:10:43 ubuntu-14 jk_lsh[6282]: jk_lsh version 2.19, started
Apr 29 02:10:43 ubuntu-14 jk_lsh[6282]: WARNING: user sftpuser (1004) tried to run '/usr/lib/openssh/sftp-server', which is not allowed according to /etc/jailkit/jk_lsh.ini
Apr 29 02:10:43 ubuntu-14 sshd[6281]: Received disconnect from 11.22.33.44: 11: disconnected by user
Apr 29 02:10:43 ubuntu-14 sshd[6263]: pam_unix(sshd:session): session closed for user sftpuser

so it looks like I have most stuff working but something is not right.

sneakyimp · 04-28-2016, 09:25 PM

So evidently the error is because I haven't whitelisted something in jk_lsh.ini. I altered the contents of /jail-test/etc/jailkit/jk_lsh.ini:

Code:

[sftpuser]
paths= /usr/bin, /usr/lib/
executables= /usr/bin/scp, /usr/lib/openssh/sftp-server

This seems to work! I was able to upload a file using both sftp and scp. Thank you, suicidaleggroll!

Can anyone suggest a way I might test this to make sure the user can't "break out of jail"?

Also, I don't see any file with passwords in /jail-test/etc/shadow. Where does the jail store the passwords?

Turbocapitalist · 04-28-2016, 09:46 PM

Quote:

Originally Posted by sneakyimp

I do in fact see this in the man pages. Ignoring for a moment my desire to jail someone in /var/www, how might I go about jailing PartnerUser to their home directory immediately?
...

This is not self-evident and I do not understand why. I guess I'll have to take your word for it that ChrootDirectory of /var/foo doesn't jail them in foo but they can also hit var?

Still very confused. On my machine /var is owned by root:root and not writable by anyone else:

Code:

$ ls -dal /var
drwxr-xr-x 20 root root 4096 Mar  2  2014 /var

Sorry. It should read ChrootDirectory /var/foo/www. So that /var/foo is owned by root and /var/foo/www is owned as you have it currently.

As to locking in an SFTP user immediately. The fast way is to ensure that their home directory has at least one subdirectory that they can write to. Then chown the home directory itself to root:theirgroup and set permissions to 555 or 550. They won't be able to write to the home directory but only to the subdirectories and pre-existing files. Then put something like the following in sshd_config:

Code:

Subsystem sftp internal-sftp

Match Group sftp-only
        ChrootDirectory %h
        AllowTCPForwarding no
        X11Forwarding no
        ForceCommand internal-sftp

You can test it by logging in as them and then trying to go up a directory.

sneakyimp · 05-11-2016, 07:07 PM

I managed to get jailkit working and my user is successfully jailed. Thanks for your help.

sneakyimp · 11-10-2017, 12:39 PM

Having recently had to revisit the need to chroot a user, I found myself reviewing this post again and I feel it could be improved a bit. That said, I'm sharing some additional findings which can make this a lot easier.

My recent task was to allow a user, let's call it aux_user belonging to group sftpjail, to upload a file to a machine and nothing else. In the interest of security, It seemed important to make sure this user be chrooted such that they are unable to upload files to other locations and, more importantly, not download or inspect the contents of sensitive PHP files in the web root which might be 644 or 755. I identified a few ways to accomplish something like this:
* sshd_confg - you can chroot a user or group to a particular directory and limit their actions to sftp only using a combination of ChrootDirectory and ForceCommand directives. this is the simplest, but doesn't support linux scp operations -- you have to use sftp (which supports batch mode I think).
* rssh - 'Restricted Shell' can be set as a user's shell prompt and restrict that user to only a few functions like sftp, scp, and others. config is flexible
* rrsync - 'Restricted rsync' is a perl script distributed with rsync which can chroot a user to a particular folder. you can set this for a particular ssh key in authorized_keys or with a ForceCommand directive in sshd_config

I ruled out rssh which, although it effectively limits one's actions, seems really hard to chroot securely. I set aux_user's shell:

Code:

sudo chsh -s /usr/bin/rssh aux_user

And also added a match group directive to sshd_config

Code:

Match Group sftpjail
  # this dir MUST be writable by root ONLY
  ChrootDirectory /var/chroot/aux_user
  AllowTcpForwarding no
  X11Forwarding no

This effectively chrooted the user but login failed, complaining that /usr/bin/rssh did not exist. I.e., the chroot meant no visibility to the rssh executable. I considered copying programs to the chroot dir, etc., but started reading the man page on rssh and was frightened away by various security risks described there.

Following a suggestion on openssh irc channel, I started to look at rrsync which looks very promising and fairly simple to configure. There's a description here. This seems pretty simple. A few steps on Ubuntu. You have to locate the rrsync perl script and install it in some usable spot then you can make the only possible action for a user account either by putting a command in the .ssh/authorized_keys file just preceding a particular public key, e.g.:

Code:

command="$HOME/bin/rrsync -ro ~/backups/",no-agent-forwarding,no-port-forwarding,no-pty,no-user-rc,no-X11-forwarding ssh-rsa <PUBLIC-KEY-GOES-HERE> <SOME COMMENT GOES HERE>

OR
you can put Match User/Group directive in sshd_config like so:

Code:

Match Group sftpjail
  ForceCommand /path/to/rrsync [-ro] [-wo] /path/to/force
  AllowTcpForwarding no
  X11Forwarding no

Any user constrained by this directive must have a shell that can run the perl script (e.g., sh or bash). You will note there is no ChrootDirectory directive. This is handled by the ForceCommand directive.

I ultimately opted for just using the sshd_config approach. I initially set it up and was unable to use the linux scp command, which is apparently an older protocol. I'd get rejected with something like "this account only supports sftp". I later learned that PuTTY's pscp program supports not just scp but also sftp. You just have to set the flags to force the sftp protocol. I think you can also use sftp in batch mode.

Setup involves creating some directory owned by root:root which is only writable by root -- this is your jail directory, e.g., /home/chroot/aux_user. Then you alter sshd_config to add a Match User/Group directive like so:

Code:

Match Group sftpjail
  # this dir MUST be writable by root ONLY
  ChrootDirectory /var/chroot/aux_user
  ForceCommand internal-sftp
  AllowTcpForwarding no
  X11Forwarding no

Make sure your sshd_config has a Subsystem directive like this for Ubuntu:

Code:

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

Once that's added, you restart ssh. VERY IMPORTANT: be very careful doing this. You muck up your sshd_config file and you can lock yourself out forever

Code:

sudo service sshd restart

If you need to upload files, you'll need to add a subdirectory that aux_user can write:

Code:

sudo mkdir /var/chroot/aux_user/upload
sudo chown aux_user:sftpjail /var/chroot/aux_user/upload
chmod 755 /var/chroot/aux_user/upload

For extra security, you can also make sure the user cannot login:

Code:

# You may deny shell login access for the user:
sudo usermod -s /sbin/nologin aux_user

I was able to run this command on a windows machine and it worked fine:

Code:

pscp.exe -v -pw <PASSWORD-HERE> -C -sftp C:\path\to\windows\file.txt username@example.com:upload/

I logged in via sftp as aux_user and was unable to see any files whatsoever outside the chroot. In fact, this method works so well you cannot upload files to any location outside this chroot. Any server processes that want your file must come looking for it there unless you want to try some other approach involving bind/mount, etc..

I hope someone finds this info useful.

Turbocapitalist · 11-10-2017, 01:56 PM

Thanks for the followup explanations.

Quote:

Originally Posted by sneakyimp

Once that's added, you restart ssh. VERY IMPORTANT: be very careful doing this. You muck up your sshd_config file and you can lock yourself out forever

One way around that is if you have a second port open on the server and use a second configuration file for testing. So if you have port 2022 open and wish to test the file sshd_config.test, then launch a second instance of the SSH server:

Code:

sudo /usr/sbin/sshd -p 2022 -f sshd_config.test

Then if you can connect as needed to port 2022, then you can probably safely move the original configuration file out of the way and put the test file in its place.