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

Question

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

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

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

Meus pensamentos 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 tenha esses direitos. Uma vez que a conexão ssh é estabelecida, eu posso "encaminhar" para o usuário para que ele possa inserir comandos e interagir com a máquina remota.

• Essa é uma boa abordagem?
• Como devo implementar o encaminhamento?
• Como o usuário pode iniciar a conexão (isto é, a execução do ssh pelo usuário que possui direitos de leitura na chave)?
• Existe alguma lacuna de segurança? - se os usuários podem executar um ssh como outro usuário, eles podem fazer tudo o que outro usuário poderia fazer (inclusive ler a chave privada)?

Answer 1

Essa é uma das razões pelas quais sudo existe. Basta permitir que seus usuários executem um único comando com apenas as opções de linha de comando pré-autorizadas e as soluções mais óbvias foram resolvidas. por exemplo.

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

configura sudo para que todos os membros do grupo users possam executar o comando ssh como usuário some_uid sem digitar sua própria senha (ou a da conta some_uid) quando eles forem executados:

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

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

    

Answer 2

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

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

server-hostname +

em que server-hostname é o nome do seu servidor e + é um sinal de adição literal que serve como um caractere curinga que significa "qualquer usuário".

Você também precisará garantir que a máquina remota possa verificar a chave de host do servidor, o que significa que a chave de host do servidor precisa ser listada em /etc/ssh/ssh_known_hosts ou ~/.ssh/known_hosts na máquina remota. Se este não for o caso, você pode configurá-lo fazendo login na máquina remota e executando

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

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

Você também pode facilmente fazer coisas como permitir ou negar a certos usuários o acesso à máquina remota. Veja as man pages de ssh e hosts.equiv para 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 para permitir que façam login na máquina remota como um usuário diferente, mas podem cortar o acesso deles ou de outras pessoas à máquina remota. Se isso for uma preocupação, talvez seja possível tornar .shosts gravável apenas por root ou algo assim - não sei se isso funciona, mas você pode tentar e ver. (Outros métodos como o com sudo são suscetíveis ao mesmo risco, já que um usuário sempre pode excluir ~/.ssh/authorized_keys .)