O que é uma maneira limpa e segura de permitir que o usuário Apache faça a clonagem SSH da mesma máquina?

Question

Eu tenho um servidor Apache que hospedará vários sites e uma interface web privada que visa automatizar a implantação de um site a partir de um URL SSH git. Esses git repos estão na mesma máquina, mantidos por uma instância local do Gitlab e de propriedade do root, portanto, o SSH é necessário (ou estou perdendo alguma coisa).

Portanto, temos o PHP executando comandos shell como www-data para clonar sites acessíveis publicamente a partir de um repositório protegido por root na mesma máquina.

Virtualhosts são gerenciados com mod_vhost_alias , se isso for importante. Eu também sei sobre cat ~/.ssh/id_rsa.pub >>~/.ssh/authorized_keys .

Mas gerar chaves ssh para www-data não parece uma ótima ideia.

Se eu criar um usuário "web" dedicado a esse assunto e gerar chaves ssh para ele, o www-data não poderá ser clonado nesse diretório. Eu posso usar ACL na pasta, mas ainda não obtém seu acesso ssh.

Ou talvez eu deva su web com PHP no começo? Nesse caso, os arquivos não seriam de propriedade da www-data, o que pode fazer com que os sites não funcionem.

Isso chega ao ponto em que eu perco a noção do que é bom e do que é seguro. Eu posso encontrar uma solução de trabalho, eventualmente, mas não será limpa e provavelmente não será segura.

Informações adicionais:

• Este não é um servidor de produção. Todos os sites (cerca de 10 de uma só vez) receberão um tráfego muito limitado e a maioria deles será protegida por senha de qualquer maneira (eu disse "publicamente acessível" acima para cobrir os casos mais extremos).

• O desenvolvimento é feito em um ambiente local, as mudanças são enviadas para a versão online com git hooks.

• Existe apenas uma interface da Web que pode iniciar o processo de implantação. Apenas alguns usuários confiáveis têm acesso a ele.

• A implantação não alterará a configuração do Apache, pois mod_vhost_alias manipulará vhosts e nada mais será necessário.

• Todos os sites terão uma pasta pública, o restante dos arquivos não estará acessível. O script de implantação já está escrito no momento da implantação e pode ser facilmente usado para essa finalidade.

• Problemas de implantação intermediária não precisam ser resolvidos.

Answer 1

Não combine desenvolvimento e produção. Idealmente, o servidor de produção NÃO contém VCS - ou quaisquer outros vestígios de toolchain de desenvolvimento. Desde que você está agora colocando esforço na automação da implantação, aumente a separação enquanto você está nisso.

Além disso: Permissões separadas para tarefas separadas. Uma interface de administração solicita a implantação. Um servidor da Web serve arquivos praticamente imutáveis. Um script de implantação grava arquivos.

1. O usuário que atende os arquivos não deve poder gravar em (quase nenhum de) seus arquivos.
2. O usuário que implanta os sites para o apache deve configurar essas permissões e evitar a veiculação de arquivos de implantação intermediária (um desenvolvedor pode não ter pensado nos efeitos colaterais do acesso do apache a qualquer coisa enquanto os aplicativos não são cópias completas)
3. O usuário que implanta os arquivos deve ter permissões de somente leitura para o git e apenas implantar versões com tags e confirmadas (e fazer o checkout de uma maneira semelhante como os desenvolvedores já fazem)
4. uma interface web php nunca deve lidar com qualquer magia satânica de shell. marcar um site como "precisa de implantação" por qualquer meio (criar uma pasta, etc) e ser feito com ele (não implantar de forma síncrona em uma interface web)
5. o script de implantação deve ser independente do aplicativo que está implantando além de alguns padrões comuns ("os arquivos do apache estão na pasta X", "a pasta tmp deve estar sob o nome Y")

Como eu fiz isso em uma configuração aparentemente similar: Um script de propriedade e executado pelo usuário deploy (parte do grupo www-data ). O usuário deploy tem a chave ssh para uma conta readonly no servidor git (no seu caso, gerenciado via gitlab). O script seleciona os nomes do repositório que foram marcados e implementados da seguinte forma:

1. verifique se a última implantação foi limpa
2. verifique se algum site precisa ser implantado
3. derrubar (impedir que o servidor exiba sites parcialmente copiados)
4. se necessário, obtenha um clone (no seu caso, um usuário somente leitura no git)
5. checkout nova versão (para sanidade: a última tag marcou uma que corresponda a um regex razoável)
6. configuração (copie os arquivos para webroot, no seu caso atual, não recomendável , que é uma pasta local, chown to www-data)
7. remove mark "precisa ser implantado" para este site
8. marcar implantação como bem-sucedida