Como alternativa, você poderia prefixar a chave no arquivo authorized_keys de [email protected] com um "from = ip.address.of.gateway.org", efetivamente fazendo a chave funcionar somente se a conexão vier do sistema de gateway.
Veja "man sshd" para mais detalhes.
Outra possibilidade seria ter a chave privada em uma conta separada em gateway.org
com logins desabilitados. Vamos chamar essa conta secretkeeper
por exemplo. Então você poderia dar acesso limitado ao sudo sysadmins a essa conta ( sudoers
file syntax):
User_Alias ADMINUSERS=sysadmin1, sysadmin2, sysadmin3 #...etc.
ADMINUSERS ALL=(secretkeeper) /usr/bin/ssh secretremote
Tem ~secretkeeper/.ssh/config
especificando o máximo de parâmetros de conexão possível para facilidade de uso:
Host secretremote
User topsecret
HostName remote.org
EscapeChar none
IdentityFile /some/where/ts_key.priv
Agora, seu sysadmin1
e outros poderão executar sudo -u secretkeeper ssh secretremote
, mas nenhum outro comando por meio de sudo
(a menos que haja outras definições de sudoers
). secretremote
é apenas uma palavra-chave que pode ser qualquer coisa, desde que seja a mesma nos arquivos sudoers
e ~secretkeeper/.ssh/config
.
Como o comando especificado no arquivo sudoers
inclui parâmetros, somente esse comando específico será aceito. Em seguida, sudo
executará o comando (e somente esse comando) como o usuário secretkeeper
, que pode ler o arquivo de configuração SSH e a chave privada e estabelecer a conexão. E como a sessão sudo
está executando apenas esse comando ssh
, quando o SSH for desconectado, a sessão sudo
será encerrada; não haverá shell interativo em execução como o usuário secretkeeper
.
Obviamente, tudo isso exige que os usuários do seu administrador de sistema não tenham acesso raiz ao sistema gateway.org
.