SSH - SSH jails

From Helpful
(Redirected from SSH jails)
Jump to navigation Jump to search
Security related stuff.


Linux - PAM notes · SELinux

Securing services


A little more practical


More techincal waffling

Message signing notes · Hashing notes ·
Auth - identity and auth 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 — probably a pile of half-sorted notes and is probably a first version, is not well-checked, so may have incorrect bits. (Feel free to ignore, or tell me)

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 — probably a pile of half-sorted notes and is probably a first version, is not well-checked, so may have incorrect bits. (Feel free to ignore, 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:

  • 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

Restricted copying commands/shells

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

Specific commands only (and restricted shells)

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


SSH / tunnels without execution

This article/section is a stub — probably a pile of half-sorted notes and is probably a first version, is not well-checked, so may have incorrect bits. (Feel free to ignore, 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 and is probably a first version, is not well-checked, so may have incorrect bits. (Feel free to ignore, 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

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

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.

rush

Errors

Unsorted

See also