Criando vários usuários de SFTP para uma conta

Question

Estou no processo de migrar um sistema de hospedagem compartilhada antigo para tecnologias mais modernas. No momento, o FTP antigo e inseguro é a única maneira de os clientes acessarem seus arquivos.

Eu pretendo substituir isso pelo SFTP, mas preciso de uma maneira de criar vários usuários de SFTP que correspondam a uma conta do UNIX. Um cliente tem uma conta na máquina (por exemplo, customer ) com um diretório inicial como /home/customer/ .

Nossos clientes estão acostumados a criar um número arbitrário de contas FTP para seus domínios (para distribuir a pessoas diferentes). Precisamos da mesma capacidade com o SFTP.

Meu primeiro pensamento é usar chaves SSH e apenas adicionar cada novo "usuário" a authorized_keys , mas isso é confuso para nossos clientes, muitos dos quais não são tecnicamente inclinados e preferem ficar com senhas.

O SSH não é um problema, apenas o SFTP está disponível. Como podemos criar várias contas SFTP ( customer , customer_developer1 , customer_developer2 , etc.) que todas funcionam como equivalentes e não interferem nas permissões de arquivo (idealmente, todos os arquivos devem reter customer como proprietário) ?

Meu pensamento inicial foi algum tipo de módulo PAM, mas não tenho uma ideia clara de como realizar isso dentro de nossas restrições. Estamos abertos a usar um daemon SSH alternativo se o OpenSSH não for adequado para a nossa situação; novamente, ele precisa suportar apenas SFTP e não SSH.

Atualmente, nossa configuração de SSH tem isso anexada a fim de prender os usuários em seus próprios diretórios:

# all customers have group 'customer'
Match group customer
    ChrootDirectory /home/%u    # jail in home directories
    AllowTcpForwarding no
    X11Forwarding no
    ForceCommand internal-sftp  # force SFTP
    PasswordAuthentication yes  # for non-customer accounts we use keys instead

Nossos servidores estão executando o Ubuntu 12.04 LTS.

    

Answer 1

Nossa solução é criar uma conta de usuário principal para cada cliente, como flowershop . Cada cliente pode criar um número arbitrário de contas secundárias com suas próprias senhas, como flowershop_developer , flowershop_tester , flowershop_dba , etc. Isso permite que elas distribuam contas sem compartilhar a senha da conta principal, o que é melhor para um Um monte de razões (por exemplo, se eles precisam remover a conta do DBA, eles podem facilmente fazer isso sem alterar suas próprias senhas).

Cada uma dessas contas está no grupo flowershop , com uma pasta pessoal de /home/flowershop/ . O SSH usa isso como o diretório chroot ( /home/%u , conforme mostrado na configuração da questão).

Em seguida, usamos as ACLs para permitir que todos os usuários do grupo flowershop modifiquem todos os arquivos. Quando uma nova conta de cliente é criada, definimos as ACLs da seguinte forma:

setfacl -Rm \
d:group:admin:rwx,d:user:www-data:r-x,d:user:$USERNAME:rwx,d:group:$USERNAME:rwx,\
  group:admin:rwx,  user:www-data:r-x,  user:$USERNAME:rwx,  group:$USERNAME:rwx \
/home/$USERNAME/

Isso faz o seguinte:

• Concede grupo admin (para nós, os provedores de hospedagem) rwx
• Concede ao usuário www-data (Apache) r-x aos arquivos *
• Concede ao usuário $USERNAME rwx para os arquivos
• Concede grupo $USERNAME rwx aos arquivos

Esta configuração parece estar funcionando bem para nós, mas estamos abertos a qualquer sugestão para fazer melhor.

_{* usamos suexec para CGI / PHP sendo executado como a conta do cliente}

    

Answer 2

Não tenho certeza do que você quer dizer com "equivalentes". Todas as contas devem ter seu próprio diretório pessoal? Nesse caso, basta criar contas individuais com diretórios pessoais individuais. Ou todas as contas devem compartilhar o mesmo diretório inicial? Essa provavelmente não é uma ideia muito boa, mas você pode criar todas as contas com o mesmo grupo principal (ou suplementar) e usar ACLs para lidar com permissões.

    

Answer 3

Não tenho certeza de como a solução acima ajuda a responder ao problema da Op. Se o flowershop_developer entrar, ele será chroot para o diretório /home/%u i.e /home/flowershop_developer . E da mesma forma para outros usuários.

Como eles podem ver o conteúdo do diretório /home/flowershop se forem presos em seu diretório pessoal?

Espero que não esteja faltando algo tão trivial. Eu tenho uma solução de trabalho usando a opção mount -o bind que me permite montar /home/flowershop dentro de /home/flowershop_developer , mas esperava que houvesse uma solução mais fácil e elegante.