Você pode fazer isso de forma um pouco transparente, forçando o usuário a usar um ProxyCommand localmente, tratando seu próprio servidor como um host de bastião do SSH .
No seu servidor (o bastião), restrinja o usuário a nc da seguinte forma em sshd_config :
Match User restricted_usr
ForceCommand nc -w 600 restricted_usr_vm 22
No cliente (assumindo OpenSSH ) em ~/.ssh/config :
Host myserver
ProxyCommand ssh bastion nc -w 600 restricted_usr_vm 22
(Usuários do Windows podem usar proxies ssh via PuTTY usando o PuTTY's plink ).
No entanto, graças ao seu ForceCommand , tenho certeza que o comando ssh é ignorado; ProxyCommand ssh bastion I am a bannana deve ter o mesmo efeito. Uma conexão direta (sem ProxyCommand ) do usuário resultará em um despejo SSH bruto para restricted_usr_vm.
Como mencionado em um comentar para outra resposta aqui , ForceCommand dificultará muito o gerenciamento do acesso por chave SSH ao host de bastiões. Posso pensar em duas soluções fáceis: (1) Instale uma chave SSH sem senha para esse usuário no bastião que concede acesso ao host de destino e tenha o crontab desse usuário no bastião executando scp restricted_usr_vm:.ssh/authorized_keys ~/.ssh/ ou (2) Crie um formulário web (como o do GitHub) para permitir o upload desse arquivo. (3) O NFS também pode funcionar, mas eu não gosto muito dele porque o diretório .ssh pode ser comprometido por alguém com root (ou o mesmo UID) em qualquer sistema que o monta.
Postei uma resposta muito semelhante (com mais detalhes sobre o ProxyCommand) para a muito semelhante pergunta ServerFault Proxy SSH baseado em nome de usuário .
Eu gosto muito mais do que ForceCommand ssh -t restricted_usr_vm porque ele lida melhor com timeouts e ssh -t é meio desajeitado (e, talvez até agora, às vezes não confiável). Eu também estou supondo que coisas como scp não funcionarão através deste método enquanto elas funcionarão perfeitamente via ProxyCommand .