Makejail – limited SSH account on Ubuntu

Jail Cell in the Rock by hadsie, on Flickr
Creative Commons Attribution-Noncommercial-Share Alike 2.0 Generic License  photo by  hadsie 

Previous I had covered how to setup scponly as a restricted fileserver environment. While this works well, it is very limited and didn’t allow for rsync to run (without heroics beyond what I was willing to do). Using makejail seems to be a better solution for my needs, and it turns out to be quite easy to setup on Ubuntu 12.04. On the journey here I had also tried out rssh which I also decided wasn’t a good fit.

You’ll of course need sshd installed which I’ll assume you have, and makejail which we can install easily:

$ sudo apt-get install makejail

Now we need to modify our openssh configuration by editing /etc/ssh/sshd_config, there are two changes we need to make. Modify the yes setting for UsePrivilegeSeparation:

# Disable Privilege Separation to allow chroot
UsePrivilegeSeparation no

and at the bottom of the configuration file we’ll add:

Match User frank
ChrootDirectory /home/frank
AllowTCPForwarding no
X11Forwarding no
PasswordAuthentication no

Of course, for each restricted user you need to specify the username and home directory. You may have noticed that for the restricted users I’ve disabled password authentication, this is because changing the password is broken in the ‘jailed’ environment so we just avoid the issue by insisting on the use of keys (yes, you’ll need the restricted user to send you their public key to install in the .ssh/authorized_keys file of the restricted user).

Next we need to create a simple python script file that we can pass to makejail as a configuration file. I called mine jailconf.py and the contents look like:

chroot = "/home/frank"
testCommandsInsideJail = ["bash", "ls", "touch", "rm", "rmdir", "less", "cat", "rsync" ]

Then execute makejail with this configuration file.

$ sudo makejail jailconf.py

For some reason, I needed to run makejail twice initially before it ran without errors – but it is something you can run multiple times with no serious side effects, this is handy if you want to add more commands later.

That’s it, now if you take a peek at the filesystem structure that’s been created – it’s a chroot environment. You’ll probably want to go in and create a /home/frank/stuff directory and assign ownership to the user so they can stick files there.

$ sudo ls -l /home/frank
total 36
drwxr-xr-x 2 root root 4096 Sep 19 22:59 bin
drwxr-xr-x 2 root root 4096 Sep 19 22:55 dev
drwxr-xr-x 3 root root 4096 Sep 19 22:56 etc
drwxrwxrwx 4 frank frank 4096 Sep 19 23:28 stuff
drwxr-xr-x 4 root root 4096 Sep 19 22:55 lib
drwxr-xr-x 2 root root 4096 Sep 19 22:55 root
drwxr-xr-x 2 root root 4096 Sep 19 22:59 sbin
drwxr-xr-x 2 root root 4096 Dec 5 2009 selinux
drwxr-xr-x 5 root root 4096 Sep 19 22:55 usr

Now once you sort out the public key login (and remember to make sure the permissions on the .ssh directory and authorized keys are correct), the user frank will be able to log in and see the directory tree /home/frank as if it were the root of the filesystem. Only commands listed in the configuration file (jailconf.py) will be available to that user. Of course, if the filesystem is writeable (and executable) then they could always upload copies of the commands they want to run – but hopefully these are people you trust to some level.

References: I came to this solution initially through this article. There was a serverfault post that helped with the ssh configuration changes related to disabling password authentication.

In my case this is one component in allowing a friend to use my system as a remote (encrypted) backup site using rsync. I’ll post more details on that in the future.

Ubuntu server 10.04 LTS upgrade to 12.04 LTS

Here we go again.. As I mentioned previously, I was back on 8.04 LTS which worked well for me, but end of life on support and my desire to use some of the newer features drove me down this multiple upgrade path. Since I had just come fresh from an upgrade, the second round wasn’t quite as big a deal.

Kick things off with one simple command:

$ sudo do-release-upgrade

I keep track of the changes required in a text file as the upgrade progresses, this is a good practice and has saved me a number of times.

Unfortunately my RAID array broke again on this upgrade. Time time it was /etc/fstab needing to be changed to /dev/md_d2 /dev/md_d3 instead of /dev/md2 /dev/md3.

DKIM-filter isn’t available in 12.04 – I’ve been getting (non fatal) error messages  in /var/log/mail.log about this. I’ll probably move to OpenDKIM at one point, but it’s not a big issue other than generating a bit of extra log data.

NFS broke on me this time. I was using a domain name based exclusion in my /etc/exports which I needed to remove:

/data/stuff/Shared *.lowtek.ca(rw,no_root_squash,async,no_subtree_check)

Changing the *.lowtek.ca to simply * and then running exportfs -r to update the files fixed things. The exportfs utility is new to me, or at least I’ve never needed to use it in order to fiddle with my NFS exports before.

I use the package mailgraph to make pretty charts of my email logs. This broke in the upgrade, I was able to track it down to the configuration file containing BOOT_START="YES" instead of BOOT_START=true (the default). This seems to be some mix of my previous configuration and the new package maintained one.  I will note that the new version of mailgraph is aware of greylisting which helps clean up the graphs a bit.

Dovecot‘s defaults changed to require secure logins only. This didn’t seem like a big deal until I found out that Jenn’s iPhone 3G refused to authenticate. It took a bit of trying, but I did find a solution. The iPhone 3G was running iOS 3.1.3, and that version didn’t like self signed certificates AND secure logins for sites it hadn’t synchronized with previously. To resolve this it was a simple matter of allowing plain text authentication in /etc/dovecot/local.conf

disable_plaintext_auth = no

Don’t forget to restart the dovecot service so the changes are picked up:

$ sudo service dovecot restart

Then synchronizing the phone with plaintext login. Then removing the dovecot configuration change we just made to default back to SSL based logins (and restart the service again), and the iPhone detects this and asks us to accept the self signed certificate. Weird, but it works.

My Slimserver seems to have not survived past this upgrade, I haven’t fixed this yet but it should be relatively simple. Hopefully the end of life status of this product line won’t mean the complete loss of the community around it.

In summary, there were the typical minor upgrade aches and pains but nothing that took my site down for any appreciable amount of time.

Ubuntu server 8.04 LTS upgrade to 10.04 LTS

Ubuntu 8.04 LTS desktop edition hit end of life well over a year ago (May 12, 2011), the server version end of life date is April 2013 – not too far away. With a server exposed to the internet, staying up to date with patches is good hygiene – there is also the tried and true “if it ain’t broke, don’t fix it“. While there have only been a few critical patches in the last while, I want to stay on a supported version.

The end of life date is a good motivator, but what actually triggered my upgrade was wanting to make use of encfs – and discovering that the version available on 8.04 didn’t have the feature (–reverse) that I was looking for.  I’m actually only part way there as I intend to upgrade all the way to 12.04 LTS to avoid compatibility issues with data stored with encfs. This post will focus on issues and solutions that I encountered on the way to 10.04.

Initiating the upgrade process is quite easy. If you choose to do this via SSH (as I did) you’ll be warned that this could be a bad idea. In my case console access is possible if I head down to the dusty corner of my basement where it lives, so I felt certain that I could recover if needed.

$ sudo do-release-upgrade

Through the install process you’ll be warned of conflicts with the package maintained version of configuration files and the ones you have. Some of these conflict warnings will be pure console, and others will use the curses library to display it a bit more graphically. As I was doing a fairly major upgrade (8.04 -> 10.04) I opted in many cases to overwrite my configuration file with the package maintained version then perform a manual merge afterwards. If you pick this route make sure to keep good notes on which files need to be revisited AND that you have a full system backup – it is nice that the installation system will copy your old version to .dpkg-old so comparison is easy.

Things seemed to go very smoothly, up until it was time to reboot. Post reboot I could ping the machine but SSH was not accepted. Time to head down and check out the actual console. It turned out that my RAID volumes wouldn’t mount and this derailing the normal start up.

As with many things, someone else had run into pretty much the same problem and posted a solution. Sadly that wasn’t quite the full solution in my case as the RAID5 volume wasn’t being recognized properly. I did find the help I was looking for, so basically here is what I did.

Since my RAID volumes are not needed to boot the OS, I simply skipped mounting those drives. Once logged in I could issue:

$ sudo mdadm --auto-detect
$ sudo mdadm --examine --scan

This gave me:

ARRAY /dev/md3 level=raid5 num-devices=3 UUID=7a6c5b68:6d6d7031:7653325d:7e304e58
ARRAY /dev/md2 level=raid1 num-devices=2 UUID=593e3663:69294b3b:30443245:23496c5f

Which I effectively cut & pasted into the /etc/mdadm/mdadm.conf file with one small change: I replaced /dev/md3 and /dev/md2 with /dev/md/d3 and /dev/md/d2 respectively. I’m not certain this was necessary but it matched closer what the 1st solution I found described and it is working fine in my system.

Once past that roadblock, most of the other things were trivial. I found copying the config files back to my Ubuntu desktop system and using meld to view differences to be much easier than trying to interpret the console diff utility.

There was a warning about the default TCP port changing for postgrey, yet for some reason mine still appears to be running happily on port 60000. I also had some trouble with my ThinkUp installation, one of the required PHP packages (php5-mcrypt) had been auto removed in the upgrade. While I’ve certainly missed something in the process, it’s been a couple of days and I haven’t seen any serious problems due to the upgrade.