Service account

Assume you have a single purpose account. Maybe some service account, user which should run a single task ever, or even a case of a limited menu interface. You want your user(s) to reach there using SSH because that is the method to do it right and secured. You want it to be easy for the users – combine your ability to have a secure session with ease of use through SSH keys, while fearing an abuse.

You can probably see how this balances. In most cases, it balances as “we will make our users’ life hard and they will have to type a password”, which is fine, except that you hardly ever actually enforce password policy or password age limitations, so you compromise security. Also – you have to trust your users to be nice, and never attempt to test the limits of your system. It’s bad, but finding a simple-to-manage solution for that specific single task you want is so complicated. You even consider (and sometimes actually enforce) chroot environment, which is such a pain to maintain. Either too secure or too loose.

Wow, that was long. The reason for this long prologue is that I have found a very nice utilization for a powerful and capable tool, jailkit, without the fuss of the entire chroot stuff. This is no invention of mine, but it appears to be a feature of this wonderful tool which is commonly ignored for no good reason.

This is the tool called jk_lsh – jailkit limited shell. You can define this tool on a per-user or per-group granularity through editing /etc/jailkit/jk_lsh.ini and changing the settings to match your requirements.

This allows you to use ssh keys for seamless authentication from defined client machines, and with limited set of commands which can be executed. Your job, as a sysadmin, is to make sure that these commands cannot be exploited – don’t let your users write permissions for these predefined commands so they would not be able to override your commands. Don’t let these commands reside on a share, so that replacing the command from another computer will not be possible, etc. Also – use full path for the child commands inside scripts, if used, so that altering PATH directives cannot change how your scripts work. This is quite basic, when you get to think about it.

The bottom line – your script on a remote machine which must run some specific task on this jk_lsh-modified machine can run safely and do only what it was intended to do. Same goes for icons on your users desktops, with a specific ssh command included.

I recommend this configuration – enjoy the benefits of controlled environment without the pain of chroot. That is – if it fits your needs, of course.