Linux: cria uma conta SSH “pública” que executa um binário específico e depois fecha?

Question

Eu escrevi um aplicativo simples que é executado no modo de console. Eu quero permitir que pessoas da Internet façam SSH para este host e usem o aplicativo em questão.

Cada vez que alguém SSH é para o servidor, eu quero ser capaz de permitir que uma instância do aplicativo seja executado em sua sessão SSH. Eles trabalharão com o programa e, depois que ele for concluído (isto é, sair), a sessão do SSH deverá ser encerrada.

As advertências são:

1. Eu não quero usar um script de shell como o .bash_profile. Muitas oportunidades para isso ser hackeado!
2. De preferência, nem quero que a conta de usuário seja atribuída a um "shell" válido. Em outras palavras, eu quero que o shell do usuário seja algo como / bin / false, de modo que FTP, SFTP, etc. todo o resto não seja permitido. A única coisa que eu quero permitido da conta é o acesso a este aplicativo de console específico, em execução no modo não privilegiado como este usuário.
3. Talvez eu queira oferecer mais de um desses aplicativos em nomes de usuários diferentes. Por exemplo, "pesquisa" apresentará um aplicativo de console, enquanto "pesquisar" apresentará outro, dependendo de como o usuário faz login.
4. A exigência de uma senha para a sessão SSH não é necessária. Seria bom se ele simplesmente ignorasse a autenticação, mas ter que dar aos usuários finais a senha do SSH não é um problema. A única coisa aqui é claro, sendo seguro - eu não quero que a conta seja autorizada a fazer qualquer outra coisa.
5. O usuário não deveria ter que fazer nada de especial no final. Eles devem ser capazes de apenas "ssh [email protected]" e obter o serviço.

6. O programa que executa pode precisar de argumentos de linha de comando. Eu estou bem em escrever um wrapper para fazer isso, mas isso cria uma insegurança? por exemplo. Se o comando for "/ usr / local / bin / myapp --mode = search", escrevo um script como:

   ! / bin / bash

   / usr / local / bin / myapp --mode = pesquisa

... isso cria uma situação insegura? Suponha que todas as permissões de arquivo estejam definidas corretamente - o usuário não pode modificar o arquivo.

Isso é possível? Se sim, como isso pode ser feito e, mais importante, como isso pode ser feito com segurança?

O servidor já oferece SSH para o exterior para login remoto, o que é bom. Eu ainda quero que isso funcione, obviamente. Então, por exemplo, se eu fizer login como meu próprio usuário, eu quero ser perguntado por uma senha como de costume e, em seguida, apresentou um shell.

Obrigado!

F

    

Answer 1

Existem três opções:

1. Defina o aplicativo (ou invólucro adequado para ele) como o shell da conta.

   Desta forma, a conta não tem um shell. Quando o usuário passar o comando, ele será passado como argumento de linha de comando para o "shell" precedido pelo sinalizador -c . Faça o que quiser com isso.

2. Use a autenticação de chave pública e defina o que cada usuário pode executar usando a opção command em .ssh/authorized_keys .

   Isso permite executar diferentes comandos para diferentes chaves e permite revogar permissões de usuários individuais. No entanto, ele precisa que cada usuário envie sua chave pública (as chaves particulares nunca devem sair da máquina em que são geradas, portanto, os usuários devem gerar chaves e enviar as partes públicas para você).

   O comando obtém o comando passado na linha de comando ssh na variável de ambiente SSH_ORIGINAL_COMMAND , para que você possa usá-lo se quiser.

   Nesse caso, a conta precisa de um shell válido, porque ssh a utiliza para executar o comando configurado.

3. Será que realmente tem que ser ssh? Você menciona que não tem que ser autenticado, nesse caso, talvez iniciá-lo diretamente de inetd poderia fazer. Ou telnet se você precisar de terminal ao invés de apenas stdin / stdout. Note que a opção 1 também funcionará com o telnet.

Um script de wrapper é seguro se você tomar o devido cuidado ao escrevê-lo. Se não aceitar nenhuma entrada, deve estar OK. Se você quiser usar a entrada (argumentos de linha de comando em 1., SSH_ORIGINAL_COMMAND envvar em 2.), você deve limpá-lo com cuidado e citá-lo corretamente.

É claro que dependendo de quanto você confia no próprio aplicativo, você ainda pode querer colocá-lo em chroot ou em namespace separado.

    

Answer 2

Sim .... use um par de chaves pública / privada. No arquivo authorized_key, se você fizer sua pesquisa, você notará que pode restringir uma chave privada a uma chave específica e até mesmo protegê-la contra a permissão de apenas um determinado número de IP.

    

Answer 3

O que você quer é usar o ChrootDirectory no seu arquivo sshd_config. Aqui está um bom tutorial no processo.