[jerf]

Read the SSH man pages every so often, even if you think you know how to use it. There's a lot of features in there. Don't miss the "AUTHORIZED_KEYS FILE FORMAT" in sshd's man page for the uber-cool "command='command'" options for authorized keys (restricts a given key to just be able to run a certain command, very useful). See also SSH's port forwarding, -D, learn how to use ssh-agent, and "man ssh_config".

[voltagex_]

the command= syntax is (was?) how gitolite works - I'm not sure what the difference between that and a jail is, though.

[stormbrew]

They're not really related concepts. A jail is allows you to run arbitrary things in a restricted environment while ssh's command feature just forces a particular command to run no matter what's passed.

If your authorized_keys line for a key has command="blah" on it and you go:

    ssh server ls

the server will, rather than running ls as it normally would, run blah and pass the command you specified in as an environment variable. Then blah can parse it and do whatever it wants with it.

You could use command to establish a jail or virtual environment of some sort in which to run the program specified if you wanted to.

[txutxu]

The command= simply changes "what" gets executed when the user logs in.

A jail (ChrootDirectory in ssh) changes "where" the user gets when logs in.

The most creative thing I've do with command= was a "select" menu in bash (with some actions in the shudoers).

Other interesting tool I've discovered recently is rrsync. I'm doing the backups of my systems isolated with this. It's distributed with the rsync sources, you put it like:

    command="rrsync /path/to/chroot/the/remote/rsync/client/"

[stock_toaster]

I used to use rsnapshot with command= set to a custom script that would let a few things through (rsync being one of them), by instrospecting `$SSH_ORIGINAL_COMMAND`.

[MrDOS]

A true BSD chroot jail restricts the user's mobility around the file system, effectively limiting them to running only what binaries have been explicitly placed within that jail. It means, among other things, that the fork hacks that command= is vulnerable to (e.g., vim running other programs) don't work because non-permitted programs basically don't exist as far as the user can see. The downside to jails is that, without automation, they're tedious to maintain, and disk overhead is not insignificant as you have to have a duplicate set of system binaries for each user. In practice, chroot jails end up being very similar to OpenVZ “virtualization” on Linux.

[Freaky]

> The downside to jails is that, without automation, they're tedious to maintain, and disk overhead is not insignificant as you have to have a duplicate set of system binaries for each user

On FreeBSD it's common to use nullfs to reduce this - you make one jail skeleton hierarchy and then null-mount it for individual jails so they all share the same underlying files (and cache). zfs clones can be used similarly. I'm sure other OS's have similar capabilities.

[jvoorhis]

That's a lot like the layered model used by docker and warden.

[jvoorhis]

They work in totally different spheres. The command directive can assign different commands per ssh key. Think [e-mail] for all of your users, a la Github.

Jails limit the capabilities of users of the OS, instead of users of the network.