Take the 2-minute tour ×
Server Fault is a question and answer site for professional system and network administrators. It's 100% free, no registration required.

There are times where using ssh keys with empty passphrase is highly desirable (backups, ...). The well-known problem is that such keys are safe only to the point they are kept from untrusted hands.

Yet, in the case they would be compromised, those keys may be further protected from doing too much harm by prepending some options to them in the server authorized_keys file, e.g.:

command="/usr/bin/foo",no-port-forwarding,no-agent-forwarding,no-X11-forwarding,no-pty ssh-rsa AAA.....

Theoretically, this key could only be used to run command /usr/bin/foo on the server. A new problem arises then since one would need a special dedicated key for every command.

For this reason, a more elaborated variant may be found on the internet (e.g. on this very same site : sshd_config versus authorized_keys command parameter) that consists of installing a generic key restricted to a locally crafted script that would make use of the SSH_ORIGINAL_COMMAND environment variable set by ssh.

The (restricted) key blurb in authorized_keys would then look like :

command="/usr/local/bin/myssh",no-port-forwarding,no-agent-forwarding,no-X11-forwarding,no-pty ssh-rsa AAA.....

and the myssh script would look like :

#!/bin/sh
msg="Command not allowed with this key"
case "$SSH_ORIGINAL_COMMAND" in
  *\&*)
      echo $msg
      ;;
  *\(*)
      echo $msg
      ;;
  *\{*)
      echo $msg
      ;;
  *\;*)
      echo $msg
      ;;
  *\<*)
      echo $msg
      ;;
  *\`*)
      echo $msg
      ;;
  *\|*)
      echo $msg
      ;;
  rsync\ --server*)
      # optionnally check for extra arguments
      # ....
      # then
      $SSH_ORIGINAL_COMMAND
      ;;
  some-local-script*)
      # optionnally check for extra arguments
      # ....
      # then
      $SSH_ORIGINAL_COMMAND
      ;;
  *)
      echo $msg
      ;;
esac

My one and only question is : can one be sure that such a protected key could not used to escape out of its cage ?

Thanks in advance !

share|improve this question

3 Answers 3

up vote 1 down vote accepted

Actually, gitolite use the same method to authenticate the user (identify the user base on the SSH key used) and restrict what the user could run (effectively only the command which starts gitolite).

gitolite is used by kernel.org for access control their git repo, so I think that method should be quite reliable.1

share|improve this answer
    
Thank you Raymond for pointing to gitolite. As I said in my reply to Michael's interesting comment, studying gitolite's code is really interesting wrt securing the setup. While your answer is more empirical than theoretical, I accept it since this is the one that is the more on-topic. –  phep Jun 1 '13 at 16:09

It depends on the security of the wrapper script and the allowed commands.

The wrapper script needs to guard against attempts to run multiple commands (e.g. allowed-command blah; other-command) or abuse PATH differences. I would probably write the script to call allowed commands with their full path, and use exec to prevent further interpretation of the client provided command:

set -- $SSH_ORIGINAL_COMMAND
case "$SSH_ORIGINAL_COMMAND" in
    rsync\ --server*)
        shift 2;
        exec /usr/bin/rsync --server "$@"
        ;;

You also need to ensure that the allowed commands don't have a mechanism to execute other commands. For example, rsync -e "other-command" would make rsync execute a different command. (--server should prevent this in the above script however.)

share|improve this answer
    
Thank you Michael for pointing to those necessary supplemental steps to have a really secure script. De facto I only use such setups with local scripts (the "some-local-script" of my question) that encapsulate and protect all of the "exec" machinery.As Raymond pointed in its reply, gitolite has very interesting dispositions to prevent such abuses. –  phep Jun 1 '13 at 16:07

I am no ssh or security expert, but barring some kind of bug in ssh or your 'myssh' script I can't see any security problems with that. But you know that old adage, better safe than sorry. Maybe you could also configure ip based filtering, if applicable.

share|improve this answer

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.