EDIT: Depois de muita escavação, isso é quase certamente um resultado do /etc/profile.d/... ser chamado antes do rbash ser executado e, portanto, não é um problema com o bash restrito em si mesmo.
Parece haver uma evasão trivial do rbash, em que um usuário do SSH pode simplesmente solicitar que o bash seja executado.
O ambiente consiste em um $PATH restrito, com um pequeno subconjunto de comandos disponíveis. O comando id não está disponível, que é o que eu baseio a seguinte transcrição em:
testuser@jumphost:~$ id
-rbash: id: command not found
.. mas depois ..
testuser@jumphost:~$ ssh localhost "bash"
testuser@localhost's password:
id
uid=3033(testuser) gid=4033(jumpuser) groups=5033(foogroup) context=jumpuser_u:jumpuser_r:jumpuser_t:s0
.. bash é chamado; concha restrita foi contornada.
Eu tentei implementar o rbash sendo chamado através de um Match Group / ForceCommand no sshd_config , e enquanto isso faz chamar o rbash para mim, o problema de ser capaz de simplesmente execute bash ainda existe.
Por padrão, não estamos usando chaves públicas para os usuários externos devido a razões logísticas, portanto, a capacidade de "command=" no arquivo ~/.authorized_keys não é uma opção. Nós também gostaríamos de oferecer mais do que apenas ssh para os usuários .. um kinit / klist bem como alguns outros programas manuais.
Existe um mecanismo para restringir esse comportamento?
No fechamento, a solução foi controlar melhor o ambiente inicial entre o momento da autenticação bem-sucedida e a chamada do rbash.
Isso foi conseguido com um shell de wrapper que chama um bash "limpo" com os sinalizadores --restricted , --rcfile ... , --noprofile , etc .... e um caso padrão que registra a tentativa de execução antes de sair.
Com desculpas pelo título alarmista ...