
Eu sou novo no Linux.
Estou trabalhando com um servidor Redhat 5.5 e usando um script SFTP baseado em Java que permitirá que vários usuários carreguem arquivos de texto para um servidor. Não tenho certeza se cada usuário terá um diretório separado ou se usarei uma convenção de nomenclatura que inclua seu ID de cliente.
Os arquivos incluem algumas informações pessoais sobre as configurações da LAN, por isso prefiro usar SFTP em vez de FTP. Entendo que o SFTP é criptografado (além disso, tenho uma classe Java configurada para fazer upload via SFTP, então prefiro não trocar de protocolo, a menos que haja um bom motivo).
O protótipo é para um sistema que suportará um grande número de clientes e a ideia de adicionar e remover continuamente clientes através da linha de comando parece altamente impraticável. (Novamente, sou novo/aprendendo Linux e Redhat).
Quais são as convenções normais para conceder permissão a vários usuários para fazer upload de arquivos SFTP com um nome de usuário e senha exclusivos para cada um.
Responder1
Você pode fazer isso configurando seu sshd externo como sftpd com chroot (use a opção sftpd-internal em sshd_config para isso). Cada usuário pode ter seu próprio chroot-jail. No arquivoauthorized_key dos seus usuários (não permita senhas!), você deve prefixar cada chave pública com os prefixos necessários que impedirão o acesso ao shell. Seu chroot também deve conter apenas a configuração básica para acesso sftp (sem binários, sem bibliotecas, apenas/dev/null,/dev/zero,/dev/random e/dev/urandom - tanto quanto me lembro).
Responder2
O que você está descrevendo é possível, mas provavelmente não é a melhor das ideias, especialmente se você, como você disse, é novo no Linux.
Como você disse, gerenciar permissões de arquivos e usuários será um pesadelo, e o SFTP requer SSH que por si só pode expor todos os tipos de funcionalidades, como execução de código no servidor remoto e download de arquivos.
IstoéÉ possível configurar um servidor SFTP com um mínimo de segurança, mas há muitas armadilhas em configurá-lo. Há muitos conselhos enganosos na Internet sobre como configurar usuários somente SFTP com SSHd. Resumindo a história, énãosuficiente para simplesmente alterar seu shell de login para um shell inválido, você também precisa se preocupar com sua capacidade de executar comandos remotamente ignorando o shell e com sua capacidade de ler arquivos de sistema potencialmente sensíveis fora de seu diretório inicial, bem como com sua capacidade de usar Tunelamento SSH para contornar firewalls. Bem como qualquer outra funcionalidade que talvez não me lembre de cara.
E issoépossível contornar toda a questão da "necessidade de criar um usuário para cada cliente", seja fazendo alguma magia obscura com o PAM para permitir a autenticação do SSH em algum outro banco de dados de usuário, ou simplesmente compartilhando uma única conta de usuário (o que deve ser suficiente, desde que já que você só se preocupa em permitir que os usuárioscarregararquivos).
Além disso, você resolverá de alguma forma um problema básico de segurança que o SFTP tem em seu tipo de aplicativo com muitos usuários remotos que precisam ser capazes de verificar se o servidor remoto é o que parece ser. Não há autoridades de certificação para SSH - o método que o SSH usa para proteger contra ataques man-in-the-middle é armazenar em cache uma impressão digital das chaves do servidor SSH dos servidores aos quais o cliente se conecta e se a chave corresponde à chave vista anteriormente , tudo está bem. No entantose a chave não for conhecida, como é a primeira vez que um cliente se conecta, o SSH exige que o usuário verifique a impressão digital manualmente. Não é razoável esperar que seus clientes realmente façam isso, quase todo mundo simplesmente clicará em “sim” porque querem continuar com suas vidas. Você pode distribuir a impressão digital válida do host com seu aplicativo, mas isso parece um pesadelo.
Se você decidir prosseguir com o SFTP, apesar dos possíveis problemas descritos, sugiro investigarrsshpara restringir os usuários apenas ao SFTP. Além disso, você deve manter todos os seus usuários SFTP em uma prisão chroot, onde eles não podem interferir nas operações do servidor ou acessar quaisquer arquivos do sistema. (Mesmo assim, pode ser possível para um invasor enumerar os usuários do seu sistema...) E você também precisa ter certeza de que o sshd está configurado para evitar o tunelamento SSH dos seus usuários SFTP.
...
Em vez de lidar com esse tipo de confusão, sugiro considerar outro protocolo para fazer upload de seus arquivos que pareça muito mais adequado ao seu caso de uso - por que não considerar fazer upload de arquivos usando HTTPS? Você precisaria de algum tipo de script CGI do lado do servidor ou de um servlet Java ou algo assim para receber os arquivos e fazer algo útil com eles e realizar a autenticação. O script do lado do servidor pode cuidar do armazenamento dos arquivos em um local útil. Quanto ao problema do lado do cliente, enviar um arquivo por HTTPS é uma coisa tão comum de se fazer, que eu ficaria surpreso se não houvesse alguma classe de API pronta para uso que você pudesse usar facilmente para fazer esse tipo de upload de arquivo.
Claro, isso significa que você teria que escrever algum script CGI do lado do servidor para lidar com o seu problema, mas eu suspeito que você iria querer de alguma forma lidar programaticamente com os arquivos recebidos de qualquer maneira, isso na verdade torna tudo mais fácil porque o código será chamado para você sempre que houver um novo arquivo.