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 .