Início / server / Perguntas / 772514
Accepted
John McGehee
Asked: 2016-04-24 17:32:18 +0800 CST

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

  • 772

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

Instalei o GitLab e minha equipe o avaliou. É claro que eu e outros inserimos nossas chaves públicas SSH.

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

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

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

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

Como segundo teste, tentei clonar um repositório privado ao qual 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.

Então tornei Shung um membro do projeto devops e git cloneconsegui. Eu realmente estou acessando os repositórios do GitLab como Shung Wang.

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

gitlab ssh-keys

1 respostas

  1. Best Answer

    Explicação

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

    Após a restauração do backup, o nome é redefinido para key-1, portanto, as chaves subsequentes têm nomes duplicados. Aqui está meu ~git/.ssh/authorized_keysarquivo mostrando minha chave e a chave de Shung Wang, ambas nomeadas 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 tanto para mim quanto para Shung.

    Eu relatei esse bug do GitLab no problema 1263 do GitLab .

    Soluções alternativas

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

    Solução alternativa 1

    Use sudo gitlab-rake gitlab:shell:setuppara reconstruir o authorized_keysarquivo

    Solução alternativa 2

    Eu recomendo tentar a solução alternativa 1 primeiro.

    O seguinte é o que eu realmente fiz antes de descobrir a solução alternativa 1.

    1. Depois de restaurar um backup, faça login como algum usuário existente e registre uma nova chave pública SSH
    2. Pesquisar arquivo ~git/.ssh/authorized_keyspara key-1. Se você encontrar dois, terá o problema descrito acima.
    3. Essas linhas ######...não são decoração. São chaves que foram apagadas pelos usuários. Quando uma chave é excluída, o GitLab substitui todos os caracteres nela por um #, 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 do backup pelo #caractere de maneira semelhante à ~git/.ssh/authorized_keysmostrada 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 aquela edição tediosa na etapa 3, suspeito que você pode simplesmente mover o arquivo de ~git/.ssh/authorized_keyslado e substituí-lo por um arquivo vazio e, em seguida, dizer a todos para inserir novamente suas chaves públicas SSH. No entanto, eu não tentei isso sozinho. Se isso funcionar para você, por favor, diga-nos em um comentário.

    • 1

relate perguntas