O rbash é seguro se o login do usuário e as senhas ssh estiverem desativados?

Question

Eu tenho um servidor que quero usar como um gateway SSH para encaminhamento de porta local e remota. Eu não quero que comandos arbitrários possam ser executados nele, apenas meus scripts.

Eu continuo lendo sobre como as shells restritas são fáceis de quebrar, mas o rbash é bom o suficiente se:

• o usuário não possui senha (então ele / ela não pode efetuar login em um shell)
• As senhas ssh estão desativadas (por isso, é necessária uma chave)
• CAMINHO = ~ / usr / bin (apenas para que nenhum arquivo de outro lugar possa ser executado)
• a entrada em ~ / .ssh / authorized_keys é prefixada com: %código%

"cmd_handler" é um script de shell rbash que pode fazer algumas coisas específicas diferentes com base no que é canalizado para o ssh de stdin. Ele mora na pasta ~ / usr / bin junto com links simbólicos para executáveis que ele requer, especificamente command="cmd_handler",no-pty,permitopen="127.0.0.1:*",permitopen="localhost:*",no-agent-forwarding,no-X11-forwarding , fold , head , nc , sed , ssh-keygen , tee . ~ / usr / bin é a única pasta no PATH, então estes são os únicos comandos disponíveis.

O usuário é o proprietário do grupo, com acesso somente leitura, para todos os arquivos ou pastas que requerem acesso (incluindo a pasta ~ / usr / bin). O usuário não é o proprietário e não tem acesso de gravação a nenhum arquivo ou pasta diferente de ~ / .ssh e ~ / .ssh / authorized / keys (que é obrigatório).

Não vejo como isso deixe o sistema vulnerável, já que o único comando que pode ser executado pelo computador remoto é o "cmd_handler". E se, de alguma forma, o usuário remoto pudesse, de fato, executar outro comando, não há muita coisa disponível. tr , tee e sed criam a possibilidade teórica de ~ / .ssh / authorized_keys serem modificados para executar comandos arbitrários, mas, mesmo que pudessem, tudo que está por aí para usar são os sete comandos e se eles escreverem algo em / tmp ou ~ / .ssh, não importará porque o rbash não executará nada que não esteja no PATH.

Então, voltando à pergunta original: isso é bom o suficiente para o que eu quero fazer, ou eu realmente preciso olhar para o AppArmor ou algo assim? Eu gostaria de uma resposta que explica uma vulnerabilidade específica, em vez de declarações gerais sobre todos sabendo que o rbash é fácil de romper e outros. Isso pode ser verdade, mas é especificamente inseguro para este aplicativo?