Como posso proteger ainda mais esses dois scripts usados em SSH authorized_keys?

Question

itunes.sh :

#!/bin/sh

set -f
set -- $SSH_ORIGINAL_COMMAND

case "$1" in
  /home/dimm0k/progs/scripts/*)
    ;;
  *)
    exit 1
esac

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

exec "/home/dimm0k/progs/scripts/$command" "$@"

rsync.sh :

#!/bin/sh
case "$SSH_ORIGINAL_COMMAND" in
  *\&*)
    echo "Rejected 1"
    ;;
  *\;*)
    echo "Rejected 2"
    ;;
    rsync*)
    $SSH_ORIGINAL_COMMAND
    ;;
  *true*)
    echo $SSH_ORIGINAL_COMMAND
    ;;
  *)
    echo "Rejected 3"
    ;;
esac

    

Answer 1

Sua pergunta não é muito significativa, pois você não definiu nenhum objetivo de segurança. "Isso é seguro" não tem sentido: seguro contra o quê? Um objetivo de segurança seria algo como “um adversário que não conhece a chave privada não pode acessar nenhum arquivo no sistema” (que seu esquema obviamente cumpre) ou “um adversário que não tem acesso ao sistema além daquele chave só pode acessar arquivos em /home/dimm0k e não executar comandos arbitrários ”(que seu esquema não cumpre).

Dito isso, aqui estão algumas coisas que você não parece ter pensado.

• No script itunes.sh , você tem comentários que afirmam que algo é rejeitado, mas nenhuma de suas instruções case contém qualquer código, portanto, todo o case é um não-op e a única filtragem no comando é que deve começar com /home/dimm0k/progs/scripts/ .
• No script rsync.sh , você permite qualquer comando que comece com rsync , não apenas rsync em si.
• No script rsync.sh , rejeitar & e ; é bizarro. A string não é avaliada por um shell, portanto, se você estava pensando no significado de & e ; na sintaxe do shell, elas são irrelevantes. E se a string fosse executada por um shell, muitos outros caracteres seriam relevantes, em particular '$|<> .
• Em qualquer script, você permite que o chamador passe opções arbitrárias para o comando executado no final. Com itunes.sh , o que isso permite depende do que você tem em /home/dimm0k/progs/scripts/ , mas provavelmente não é bom. Com rsync.sh , isso permite a execução arbitrária de comandos, por exemplo, passando a opção -e .
• Você não faz nada para restringir quais arquivos o usuário pode acessar. Em particular, se ~/.ssh/authorized_keys de qualquer dos arquivos em /home/dimm0k/progs/scripts/ for gravável pelo usuário, eles poderão usar um comando para substituí-lo e, em seguida, efetuar login uma segunda vez para executar o que foi carregado.

Em suma, esses scripts realmente não impõem nenhuma medida de segurança que eu possa ver. Por motivos de segurança, trate-os como permitindo que o usuário execute comandos arbitrários. Funcionalmente, o comando mangling é bizarro e provavelmente causará mais erros de escape quando seus scripts forem usados por um usuário cooperativo.

Se você quis impor algumas restrições ao usuário, está muito longe de fazer algo útil. Esqueça de fazer isso sozinho e use uma ferramenta robusta como rssh ou scponly . Investigue o chrooting também. Use uma conta dedicada com permissões mínimas, se possível. Para melhor isolamento, permita que o usuário faça o login somente dentro de um contêiner ou uma máquina virtual.