SSH - SSH jails

From Helpful
Jump to: navigation, search
Security related stuff.

Practical


Theory


Unsorted


This article/section is a stub — probably a pile of half-sorted notes, is not well-checked so may have incorrect bits. (Feel free to ignore, fix, or tell me)

Intro

I like to occasionally do things like:

  • put up tunnels to allow SSH 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 you suddenly have to worry your filesystem permissions, 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, avoid all shells or other execution: (As this wish's implications are best defined, this is arguably the easiest case)


OpenSSH's built-in SFTP

This article/section is a stub — probably a pile of half-sorted notes, is not well-checked so may have incorrect bits. (Feel free to ignore, fix, or tell me)

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:

  • /home 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

Restricted copying commands/shells

This article/section is a stub — probably a pile of half-sorted notes, is not well-checked so may have incorrect bits. (Feel free to ignore, fix, or tell me)

Specific commands only (and restricted shells)

This article/section is a stub — probably a pile of half-sorted notes, is not well-checked so may have incorrect bits. (Feel free to ignore, fix, or tell me)


SSH / tunnels without execution

This article/section is a stub — probably a pile of half-sorted notes, is not well-checked so may have incorrect bits. (Feel free to ignore, fix, or tell me)

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 — probably a pile of half-sorted notes, is not well-checked so may have incorrect bits. (Feel free to ignore, fix, or tell me)

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

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

People can still upload and run their executables.

And hackers may manage to break out of this jail. It can't hurt to limit everyone else, just know that/why chroot alone chroot is not a secure solution in itself.


Probably the easiest way to do this is to

  1. if you want more than one jailed user, it's easier to match them by group:
groupadd jailedusers
adduser -g jailedusers myuser
  1. ...then preferably use OpenSSH 4.9+'s built-in chroot feature
  2. (In part because it does half the work of starting that chroot shell,
  3. also in part because the skeleton environment is easier)

In your /etc/ssh/sshd_config:

Match group jailedusers
    # this assumes that you have /home/jail/home/myuser
    ChrootDirectory /home/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


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.


Errors

Unsorted

See also