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
.