Security of only allowing a few vetted commands using $SSH_ORIGINAL_COMMAND

Question

Using a authorized_keys forced command with ssh and a wrapper-script like this:

#!/usr/bin/env bash

case "$SSH_ORIGINAL_COMMAND" in
  /var/lib/authorized-scripts/*)
    $SSH_ORIGINAL_COMMAND
    ;;
  *)
    exit 1
    ;;
esac

Can a malicious user somehow chain another command after /usr/bin/authorized-scripts/ and therefore overcome this security measure or is this secure?

This suggests that I could simply use ssh user@host '/var/lib/authorized-scripts/script.sh && cat /etc/passwd', but this did not work in my tests.

Can I somehow improve the security of this script while still allowing multiple commands with user-supplied arguments for a single ssh key?

I am aware that the allowed commands themselves should ofcourse not allow any kind of subshells (so, find for example is a nogo for example due to its exec functionality).

Answer 1

Your forced command is unsafe. Consider:

ssh -l user your-server /var/lib/authorized-scripts/../../../bin/rm -rf /

The command name starts with /var/lib/authorized-scripts/ so it's safe, right? Nope!

You'll want something more along these lines:

#!/bin/sh

set -- $SSH_ORIGINAL_COMMAND
case "$1" in
  /var/lib/authorized-scripts/*)
    ;;
  *)
    exit 1
esac

command="${1#/var/lib/authorized-scripts/}"
shift
case "$command" in
  */*)
    # Simplest is to reject anything with a slash...
    exit 1
  .*)
    # ...and anything starting with dot.
    # If you need to whitelist subdirectories of /var/lib/authorized-scripts
    # then you need much more sophisticated pathname parsing and care.
    exit 1
  *)
    ;;
esac

exec "/var/lib/authorized-scripts/$command" "$@"

As for shell syntax like && and ; embedded in the command, that should be safe. As you've already discovered, such things are not interpreted by the shell in your solution but passed verbatim to the command.

However, wildcards in the arguments of the command will be interpreted. If you want to avoid that, put set -f before the line with set -- $SSH_ORIGINAL_COMMAND.

Make sure that the authorized scripts interpret their arguments in a safe way. The arguments could be options that allow shell injection (like find -exec does), file names, including symbolic links (which point to a file in a different directory), etc.

Finally: #!/usr/bin/env bash is not necessary. Your script uses no bashisms, so why not let be more portable by running under /bin/sh?

Answer 2

[Disclosure: I wrote sshdo which is described below]

There's a program called sshdo for doing this. It controls which commands may be executed via incoming ssh connections. It's available for download at:

http://raf.org/sshdo/ (read manual pages here)
https://github.com/raforg/sshdo/

It has a training mode to allow all commands that are attempted, and a --learn option to produce the configuration needed to allow learned commands permanently. Then training mode can be turned off and any other commands will not be executed.

It also has an --unlearn option to stop allowing commands that are no longer in use so as to maintain strict least privilege as requirements change over time.

It is very fussy about what it allows. It won't allow a command with any arguments. Only complete shell commands can be allowed so it might not meet your needs.

But it does support simple patterns to represent similar commands that vary only in the digits that appear on the command line (e.g. sequence numbers or date/time stamps).

It's like a firewall or whitelisting control for ssh commands.