Depois de restaurar o backup do GitLab, novas chaves públicas de SSH substituem aleatoriamente as chaves existentes de outros usuários

Question

Isso ocorreu com uma nova instalação (não atualizada) do GitLab 8.6.4.

Eu instalei o GitLab e minha equipe o avaliou. É claro que eu e outras pessoas inserimos nossas chaves públicas SSH.

Como parte de nossa avaliação, fiz um backup do GitLab e o restaurei.

Depois que eu restaurei o backup, o novo usuário Shung Wang digitou sua chave pública SSH.

Agora, sempre que eu tento acessar os repositórios git via SSH, o servidor acha que sou Shung Wang. Por exemplo, quando eu testei minha conexão SSH do meu laptop Ubuntu 14.04, eu entendi:

ssh -T git@gitserver Welcome to GitLab, Shung Wang!

Como segundo teste, tentei clonar um repositório privado ao qual o Shung não tinha acesso:

git clone git@gitserver:sw/devops.git Cloning into 'devops'... GitLab: The project you were looking for could not be found. fatal: Could not read from remote repository. Please make sure you have the correct access rights and the repository exists.

Depois, fiz de Shung um membro do projeto devops e git clone foi bem-sucedido. Eu realmente estou acessando os repositórios do GitLab como Shung Wang.

Obviamente, esta é uma situação de segurança mais insatisfatória. Como posso acessar os repositórios do GitLab como eu além de Shung Wang?

    

Answer 1

Explicação

O GitLab mantém o arquivo ~git/.ssh/authorized_keys , no qual ele atribui nomes de chave pública de cada SSH key-1 , key-2 e assim por diante.

Após a restauração do backup, o nome é redefinido para key-1 , para que as chaves subseqüentes tenham nomes duplicados. Aqui está o meu arquivo ~git/.ssh/authorized_keys mostrando a minha chave e a chave do Shung Wang chamada key-1 :

# Managed by gitlab-shell
command="/opt/gitlab/embedded/service/gitlab-shell/bin/gitlab-shell key-1",no-port-forwarding,no-X11-forwarding,no-agent-forwarding,no-pty ssh-rsa AAA...2SkSQ== [email protected]
###################################################################################################################################################################################
#####################################################################################################################################################################################
command="/opt/gitlab/embedded/service/gitlab-shell/bin/gitlab-shell key-1",no-port-forwarding,no-X11-forwarding,no-agent-forwarding,no-pty ssh-rsa AAA...nKQ== [email protected]
...

Aparentemente, a última ocorrência de key-1 é usada para mim e para o Shung.

Eu relatei esse bug do GitLab na questão GitLab 1263 .

Soluções alternativas

Até que o bug seja corrigido, os usuários podem tentar essas soluções alternativas.

Solução 1

Use sudo gitlab-rake gitlab:shell:setup para reconstruir o arquivo authorized_keys

Solução 2

Eu recomendo tentar a solução 1 primeiro.

Segue-se o que eu realmente fiz antes de descobrir a solução 1.

1. Depois de restaurar um backup, faça o login como algum usuário existente e registre uma nova chave pública de SSH
2. Pesquise o arquivo ~git/.ssh/authorized_keys por key-1 . Se você encontrar dois, você tem o problema descrito acima.
3. Essas linhas de ######... não são decoração. São chaves que foram deletadas pelos usuários. Quando uma chave é excluída, o GitLab substitui todos os caracteres com # , presumivelmente, para que as chaves restantes não se movam no arquivo. Substitua todos os caracteres em todas as chaves SSH criadas antes da restauração de backup pelo caractere # de maneira semelhante à que você vê no ~git/.ssh/authorized_keys mostrado acima.
4. Diga a todos os seus usuários que eles devem inserir novamente suas chaves públicas SSH. Se eles reclamarem, lembre-os de agradecer que o restante do backup funcionou.

Em vez de toda essa tediosa edição na etapa 3, suspeito que você possa simplesmente mover o arquivo ~git/.ssh/authorized_keys de lado e substituí-lo por um arquivo vazio e, em seguida, avisar a todos que insiram novamente suas chaves públicas SSH. No entanto, eu não tentei isso sozinho. Se isso funciona para você, por favor, conte-nos em um comentário.