Tenho uma rede privada de servidores Centos 7. Cada um dos servidores só pode ser acessado por meio de um bastião SSH. Além disso, todos esses servidores usam SSSD para autenticar as chaves dos usuários SSH em um diretório LDAP.
Como as chaves são autenticadas em um diretório LDAP, não existe um authorized_keysarquivo padrão. Em vez de um arquivo padrão authorized_keys, o binário /usr/bin/sss_ssh_authorizedkeyscanaliza uma consulta no LDAP para sshdser formatado como um authorized_keysarquivo - mas não como um arquivo. Portanto, não é possível limitar os usuários a comandos específicos vinculando chaves RSA a commands=" ... "entradas, até onde eu sei.
Os usuários SSH podem se autenticar por meio do bastion em suas estações de trabalho usando o seguinte comando:
ssh -A -l [email protected] joes.workstation.ip -o ProxyCommand="ssh -l [email protected] -q bastion.ip nc joes.workstation.ip %p"
Infelizmente, eles também são capazes de fazer SSH em uma sessão no servidor bastião, algo que eu não gostaria que eles pudessem fazer.
Existe alguma maneira de usar minhas ferramentas atuais - SSSD, SSHD, um diretório LDAP - para permitir usuários SSH através do bastião, mas nãoemo bastião?
Responder1
A versão sssdque permite definir configurações por grupo ainda estava em desenvolvimento quando me deparei com esse problema.
Acabei adicionando uma ForceCommandentrada à minha sshd_configdiretiva Match, bem como a uma AcceptEnvdiretiva:
Match Group [email protected]
AcceptEnv SomeVariable
AcceptEnv SomeOtherVariable
ForceCommand /path/to/some/script/I/wrote
Então, no shell script, utilizo as variáveis passadas pelo cliente ssh para realizar alguma ação.
Por exemplo, se o cliente chamou assim:
$ SomeVariable=foo ssh -i path/to/key -l [email protected] -o SendEnv=SomeVariable bastion.server
O script terá acesso a uma variável de ambiente SomeVariable; acesse-o usando o idioma que desejar, usando-o para realizar alguma ação.
Certifique-se de que seu script não saia para uma sessão de shell no bastião.