SSH - SSH jails

Security related stuff. Linux - PAM notes · SELinux Securing services Public key encryption; SSL and TLS SSH: tunnels, X forwarding · keypair logins · SSH jails · loose notes · agent Apache config and .htaccess - security A little more practical security for the everyday person not-so-formal notes Ingredients that might be useful to know - MFA / 2FA · One-Time Passwords; also, authenticators More techincal waffling Message signing notes · Hashing notes · Auth - Kinds of auth setup · identity and auth notes ·· OAuth notes · OpenID notes Kerberos notes · · SASL notes Encryption - Encryption notes · public key encryption notes · data-at-rest encryption ·pre-boot authentication · encrypted connections Unsorted - · Anonymization notes · website security notes · integrated security hardware · Glossary · unsorted

✎ This article/section is a stub — some half-sorted notes, not necessarily checked, not necessarily correct. Feel free to ignore, or tell me about it.

Intro

I like to occasionally do things like:

• put up a tunnel to allow SSH access to hosts behind a firewall, via my home server (see also autossh)

• set up a subversion repository that some other host can access transparently

• give some people the ability to copy data in or out (sftp, sometimes rsync), e.g. for datasets at work

When you give someone a general-purpose user account, particularly set up a keypair (e.g. for autossh, for passwordless subversion), you give them a login. You now have to worry about permissions on all your filesystem - whether there are any places where their group permissions apply, or where your world permissions were permissive.

Instead, you can lock things down for specific logins, but when you've never done that before, that may be more work figuring out how.

SSH's various features make the problem more interesting. While it can lock things down hard, the gradations inbetween are harder, in part because SSH isn't only a shell, doesn't require a shell, allows command execution without a shell, not everything done with SSH is due to things that might restrict a user's main shell, and other such fun details (verify).

Ways you could do this

SFTP copying only

When you want to allow data copying, but avoid all shells or other execution:

(Arguably the easiest case, because the implications are best defined)

OpenSSH's built-in SFTP

✎ This article/section is a stub — some half-sorted notes, not necessarily checked, not necessarily correct. Feel free to ignore, or tell me about it.

Probably the easiest solution, because it requires minimal additional setup, and the security implications are fairly easily understood.

Say

• you create have a *nix account called copy specifically for this
• which should only get SFTP access (no shell/command),
• optionally restrict it to just see its own directory:

Match User copy
    ForceCommand internal-sftp
    ChrootDirectory /home/copy
    # and quite possibly
    AllowTCPForwarding no
    X11Forwarding no

Notes:

• the parent directory, here /home by convention, would need to be owned by root (see man sshd_config under ChrootDirectory), or you get the bad ownership or modes for chroot directory component error.

sometimes that means you may wish to put this account elsewhere

• If the point was access to the entire filesystem (without a shell) omit ChrootDirectory

• Since it does not allow shell or other execution, you don't need to worry about people breaking out of the chroot jail.

• internal-sftp is similar to the external sftp-server, except it's in-process and the chrooting works without any further preparation from you (see its mention on the sshd_config man page).
  • command line arguments seem to be the same for both(verify), see sftp-server's man page

• If you want to chroot for many users, there is some useful reading at: http://en.wikibooks.org/wiki/OpenSSH/Cookbook/SFTP

Restricted copying commands/shells

✎ This article/section is a stub — some half-sorted notes, not necessarily checked, not necessarily correct. Feel free to ignore, or tell me about it.

Specific commands only (and restricted shells)

✎ This article/section is a stub — some half-sorted notes, not necessarily checked, not necessarily correct. Feel free to ignore, or tell me about it.

SSH / tunnels without execution

✎ This article/section is a stub — some half-sorted notes, not necessarily checked, not necessarily correct. Feel free to ignore, or tell me about it.

The wish: Using SSH for one of its services securely, while not allowing execution of arbitrary commands (interactively or not).

Just changing their default shell is not enough, because the user's shell is only the default command SSH runs - the client can ask for any other.

And whatever the command is, it has access as the effective SSH user, not least of which to the filesystem. Which is sometimes the point: Certain services rely on this, and are a command, e.g. rsync, svn, and some ways of providing SFTP (there's now also an internal one -- which neatly handles chroot stuff for you).

Tunnels are not a command. So if you want tunnel-only SSH, one choice is to override the command at the server side.

An important detail here is that the connection needs to stay up, without allowing any remote command.

(a bonus detail you can pay attention to is that some home routers drop idle connections. See SSH_-_loose_notes#Dropped_idle_connections)

via authorized_keys

✎ This article/section is a stub — some half-sorted notes, not necessarily checked, not necessarily correct. Feel free to ignore, or tell me about it.

If you use keypair-based trust anyway, then look at using options in the relevant user's ~/.ssh/authorized_keys lines.

Notes:

• This only makes sense if the admin sets up rights so that the relevant user's authorized_keys cannot be written to, or deleted, by the user you log as.

• no-user-rc prevents execution of lines from ~/.ssh/rc

• no-pty means allocating a terminal will fail

does not prevent command execution, just things that expect a pty (such as a shell)

• command="command" - execute this instead of whatever the client requests

sometimes useful to restrict to a single service -- see the sftp example above, or when the only point is a tunnel

...while for e.g. rsync this is hardly an option since you fix a specific command (can be made to work for structured backups)

• Examples:

no-pty,no-user-rc,command="/bin/echo do not send commands, use -N" ssh-rsa actualkey

...causes instant disconnect (because echo is immediately finished) when a client connects with a request for a command or shell, and letting the client know why

no-user-rc,command="/usr/bin/watch /bin/date" ssh-rsa actualkey

keeps displaying the date. I use this to avoid idle-timeout, and also to be able to check logs for when it stopped working

• To only allow specific (-L-style) tunnels, use something like permitopen="localhost:2229"

when allowing multiple, comma-separate them

without this, any tunnels are permitted(verify)

SSH and chroot

✎ This article/section is a stub — some half-sorted notes, not necessarily checked, not necessarily correct. Feel free to ignore, or tell me about it.

The idea here is that chroot means people can't poke around your filesystem.

However, that's all it does. People can still upload and run their executables.

And what chroot does can often be undone. While it can't hurt to do, chroot alone chroot is not a secure solution in itself.

OpenSSH 4.9+'s built-in chroot feature, which is nice in that it does much of the work of starting that chroot shell, and setting up the skeleton environment is easier.

In your /etc/ssh/sshd_config:

Match group jailedusers
    # this assumes that you have /jail/home/myuser
    ChrootDirectory /jail

    # You might want to ensure you disable features that you may have enabled globally
    # (unless one of these is the point of the account), for example:
    AllowTcpForwarding no
    X11Forwarding no

The above matches on a group, because when you want to do this for more than one account, it's less work to do

groupadd jailedusers

once and then jail individual accounts via

adduser -g jailedusers myuser

See: http://serverfault.com/questions/418931/sftp-fatal-bad-ownership-or-modes-for-chroot-directory-ubuntu-12-04

There are a few things to be aware of. See man sshd_config, search for ChrootDirectory.

See also

• chroot