Quão seguro é proteger uma chave ssh sem passphrase usando a opção “command” no arquivo authorized_keys?

Question

Há momentos em que o uso de chaves ssh com senha vazia é altamente desejável (backups, ...). O problema bem conhecido é que essas chaves são seguro apenas ao ponto em que eles são mantidos de mãos não confiáveis.

No entanto, no caso em que eles seriam comprometidos, essas chaves podem ser protegidos de fazer muito dano ao incluir algumas opções para eles no servidor authorized_keys file, por exemplo:

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

Teoricamente, essa chave só pode ser usada para executar o comando /usr/bin/foo no servidor. Um novo problema surge em seguida, uma vez que seria necessário um especial chave dedicada para cada comando.

Por esse motivo, uma variante mais elaborada pode ser encontrada na Internet (por exemplo, neste mesmo site: sshd_config versus parâmetro de comando authorized_keys ) que consiste em instalar uma chave genérica restrita a um local script criado que usaria o ambiente SSH_ORIGINAL_COMMAND variável definida por ssh.

O resumo da chave (restrito) em authorized_keys seria assim:

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

e o script myssh ficaria assim:

#!/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

Minha primeira e única pergunta é: podemos ter certeza de que essa chave protegida não poderia ser usado para escapar fora de sua jaula ?

Obrigado antecipadamente!

    

Answer 1

Na verdade, o gitolite usa o mesmo método para autenticar o usuário (identificar a base de usuários na chave SSH usada) e restringir o que o usuário pode executar (efetivamente apenas o comando que inicia o gitolite).

gitolite é usado pelo kernel.org para controle de acesso do seu repositório git, então eu acho que esse método deve ser bastante confiável. 1

    

Answer 2

Depende da segurança do script wrapper e dos comandos permitidos.

O script de wrapper precisa proteger contra tentativas de executar vários comandos (por exemplo, allowed-command blah; other-command ) ou de abuso de PATH differences. Eu provavelmente escreveria o script para chamar os comandos permitidos com seu caminho completo, e use exec para evitar interpretações adicionais do comando client provided:

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

Você também precisa garantir que os comandos permitidos não tenham um mecanismo para executar outros comandos. Por exemplo, rsync -e "other-command" faria o rsync executar um comando diferente. ( --server deve evitar isso no script acima, no entanto.)

    

Answer 3

Eu não sou especialista em SSH ou segurança, mas com exceção de algum tipo de bug no script ssh ou seu 'myssh', não consigo ver nenhum problema de segurança com isso. Mas você sabe esse velho ditado, melhor prevenir do que remediar. Talvez você também possa configurar a filtragem baseada em ip, se aplicável.