Git: enviar via ssh para um repositório de propriedade raiz com logins raiz ssh desabilitados

Question

É mesmo possível?

Resumo, estou executando o puppet master em um servidor e, idealmente, queremos logins root via ssh desabilitados, queremos forçar todo o acesso via sudo se o acesso root for necessário

no entanto, temos o puppet instalado usando um repositório git para gerenciar os manifestos, este repositório é atualmente propriedade do root e atualmente só conheço 2 soluções

1. (menos ideal) permitir acesso root apenas por meio de autenticação de chave - em caso afirmativo, como posso bloqueá-lo para permitir apenas os comandos git push?
2. possui o repositório em /etc/puppet como um proprietário diferente - o puppet funcionará de maneira confiável com isso?
3. A configuração e o comando relevantes do Sudo poderiam resolver isso?

Answer 1

Os repositórios Git podem ser configurados para manter permissões de gravação do grupo (opção --sharedao criar o repositório). Usando isso, você pode adicionar qualquer conta que precise de acesso ao repositório a um grupo específico, para que eles possam acessá-lo.

Eu faço isso para o nosso servidor git. Também coloquei um link simbólico no diretório inicial de cada usuário para cada repositório que eles têm acesso, para que todos possam acessar com uma URL relativa.

Answer 2

Para responder à minha própria pergunta, olhei as informações fornecidas por Daniel, mas não corresponderam, pesquisei git group write e me depareihttp://andyregan.net/blog/archives/504

concedendo ao meu grupo de repositórios a propriedade de um grupo comum (fantoche) e adicionando os usuários relevantes a esse grupo e, em seguida, executando:

chmod -R g+swX /etc/puppet/
cd /etc/puppet
git repo-config core.sharedRepository true

funcionou perfeitamente para mim, posso enviar para um repositório de propriedade root, o fantoche ainda funciona e não uso um login ssh root para fazer isso

Ganhar, Ganhar

ATUALIZAR

Eu tive esse problema novamente também com o puppet, mas procurei lidar com isso de uma maneira melhor e resolvi isso alternativamente com a parte certa da configuração do sudoers, adicionando o seguinte após a linha env_reset:

Defaults    env_keep += SSH_AUTH_SOCK

isso me permite executar um comando como este:

cd /etc/puppet && sudo git pull && sudo git submodule sync && sudo git submodule update --init --recursive

digamos, um Rakefile (meu usuário já tem permissões nopasswd via Sudo) e tudo funciona de acordo. O que consegui foi basicamente passar minha chave ssh encaminhada pelo agente ssh para o usuário root e, em seguida, fazer um git pull como se estivesse conectado como meu usuário não root sem armazenar minha chave ssh no usuário root (ou meu não -conta privilegiada no servidor) Win Win

Answer 3

O que eu gosto de fazer é ter um repositório git simples de "teste" no puppet master que eu empurro para executar vários ganchos de pré-commit e pós-commit. Os ganchos pré-confirmação verificam a sintaxe do fantoche (para que o código com sintaxe incorreta não possa ser confirmado) e os ganchos pós-confirmação realmente colocam o código em /etc/puppet e reiniciam o Apache (para corrigir um bug antigo de cache no fantoche 2.6)

Ter uma área de teste para a qual você envia torna o processo de implantação do código fantoche mais atômico. Caso contrário, pode ser possível que seu mestre de marionetes forneça código semi-comprometido aos clientes.