Linux ssh: permite autenticação de chave pública sem conceder direitos de leitura ao usuário à chave privada

Os usuários conectados ao meu servidor Linux devem poder fazer ssh em uma máquina remota específica com uma conta padrão. A autenticação na máquina remota usa chave pública, portanto, no servidor, a chave privada correspondente está disponível.

Não quero que os usuários do servidor possam realmente ler a chave privada. Basicamente, o fato de terem acesso ao servidor lhes permite o direito ssh, e removê-los do servidor também deve impedir a conexão com a máquina remota.

Como posso permitir que os usuários abram uma conexão ssh sem dar a eles acesso de leitura à chave privada?

Minha opinião até agora: obviamente, o executável ssh deve ser capaz de ler a chave privada; portanto, ele deve ser executado sob outro usuário no servidor que possui esses direitos. Depois que a conexão ssh é estabelecida, eu posso "encaminhá-la" ao usuário para que ele possa digitar comandos e interagir com a máquina remota.

Será esta uma boa abordagem?
Como devo implementar o encaminhamento?
Como o usuário pode iniciar a conexão (ou seja, a execução do ssh pelo usuário que possui direitos de leitura na chave)?
Existe uma brecha na segurança? - se os usuários podem executar um ssh como outro usuário, eles podem fazer tudo o que outro usuário poderia (incluindo ler a chave privada)?

— Philipp
fonte

Parece ser uma duplicata de stackoverflow.com/questions/9286622/protecting-ssh-keys

— wenzul

Configurar o servidor remoto para aceitar conexões com essa chave apenas do IP do seu servidor? Dessa forma, mesmo que roubem a chave, não podem fazer nada.

@ AndréDaniel bem, talvez eles possam entrar em outro computador completamente independente, que também esteja configurado para aceitar logins sem senha do servidor. Essa é a única razão pela qual consigo pensar em ter uma configuração como essa; se não é isso, estou bastante curioso sobre o que é. (Não que isso importe, realmente.)

— David Z

@ DavidZ Eu realmente não entendo ... a chave não deve ser confiável em nenhum lugar, mas no servidor de destino, assumindo que o IP corresponda ao do primeiro servidor (ao qual os usuários se conectam).

Se você precisar bloqueá-lo dessa maneira, presumo que você tenha tomado medidas para impedir que os usuários adicionem novas chaves públicas ao ~/.ssh/authorized_keysarquivo?

— mpontillo

Respostas:

Essa é uma das razões que sudoexiste. Simplesmente permita que seus usuários executem um único comando com apenas as opções de linha de comando pré-autorizadas e as evasões mais óbvias são resolvidas. por exemplo

#/etc/sudoers
%users ALL = (some_uid) NOPASSWD: /usr/bin/ssh -i /home/some_uid/.ssh/remote-host.key username@remotehost

configura sudopara que todos os membros do grupo userspossam executar o comando ssh como usuário some_uid sem inserir sua própria senha (ou a da conta some_uid) ao executar:

sudo -u some_uid /usr/bin/ssh -i /home/some_uid/.ssh/remote-host.key username@remotehost

Remova a NOPASSWD:opção para forçar os usuários a inserir suas próprias senhas antes de efetuar login no host remoto.
Possivelmente configure um script de alias ou wrapper como uma conveniência para seus usuários, pois sudoé bastante exigente quanto ao uso dos argumentos corretos.

— HBruijn
fonte

Funciona como um encanto. Essa também deve ser a resposta recomendada para a duplicata mencionada pela wenzul.

— Philipp

Esse parece ser um bom caso de uso para autenticação baseada em host. Este é um método de autenticação em que o SSH não usa a chave de um usuário individual na máquina local (neste caso, seu servidor) para autenticar; em vez disso, ele usa a chave privada do host , a /etc/ssh/que está armazenada e que é legível apenas por root.

Para configurar isso, você precisará criar um arquivo nomeado .shostsna máquina remota, no diretório inicial do usuário no qual você deseja que as pessoas efetuem login (não no ~/.ssh). O arquivo deve ter o conteúdo

server-hostname +

onde server-hostnameé o nome do seu servidor e +é um sinal de mais literal que serve como um curinga que significa "qualquer usuário".

Você também precisará garantir que a máquina remota possa verificar a chave do host do servidor, o que significa que a chave do host do servidor precisa estar listada na máquina remota /etc/ssh/ssh_known_hostsou ~/.ssh/known_hostsna máquina. Se esse ainda não é o caso, você pode configurá-lo entrando na máquina remota e executando

ssh-keyscan server-hostname >> /etc/ssh/ssh_known/hosts

Depois de configurar essas etapas, você poderá excluir completamente a chave privada do servidor, se não precisar dela para mais nada. (E se o fizer, você sempre pode configurá-lo para ser legível apenas por rootalgo assim.)

Você também pode facilmente fazer coisas como permitir ou negar o acesso de certos usuários à máquina remota. Veja as páginas de manual sshe hosts.equivpara detalhes.

Um problema com essa configuração é que os usuários que efetuam login na máquina remota podem modificar .shosts. Não há nada que eles possam fazer que lhes permita efetuar login na máquina remota como um usuário diferente, mas eles podem interromper o acesso deles ou de outras pessoas à máquina remota. Se isso for uma preocupação, você poderá tornar .shostsapenas gravável rootou algo assim - não tenho certeza se isso funciona, mas você pode tentar e ver. (Outros métodos como esse sudosão suscetíveis ao mesmo risco, pois um usuário sempre pode excluir ~/.ssh/authorized_keys.)

— David Z
fonte

+1; Eu acho que essa opção oferece boa flexibilidade, caso o usuário precise usar outros recursos SSH que não sejam o terminal, como encaminhamento de porta, cópia segura, etc. Até mesmo um cliente SSH alternativo deve funcionar. A sudoopção poderia ser melhor para um ambiente bloqueado, embora ...

— mpontillo