O famoso “ERROR: Permission to .git denied to user” do Git

Tentei pesquisar no Google e li https://help.github.com/en/articles/connecting-to-github-with-ssh e vários, vários guias. Não consigo git push -u origin masterou git push origin master(o mesmo comando).

Eu tenho minha conta git há pelo menos 2 ou mais anos. Tenho conseguido criar repositórios e push -u origin mastermuito bem no meu laptop, mas estou tendo problemas neste desktop.

Aqui está o que eu tentei:

1. Eu configurei meu nome de usuário git

2. Eu configurei meu e-mail de usuário git

3. Fiz upload do conteúdo de meu /home/meder/.ssh/id_rsa.pub para a página da conta do github. Eu verifiquei que não colei nenhum espaço em branco

4. Eu criei um ~ / .ssh / config com estes conteúdos:

  Host github.com
  User git
  Hostname github.com
  PreferredAuthentications publickey
  IdentityFile ~/.ssh/id_rsa

Eu modifiquei o .ssh para 700, id_rsa 600

5. Eu adicionei a origem remota adequada sem cometer erros de digitação :git remote add origin [email protected]:medero/cho.git

6. Para confirmar o nº 5, aqui está meu .git / config. O diretório está correto e não outro diretório:

[remote "origin"]
        fetch = +refs/heads/*:refs/remotes/origin/*
        url = [email protected]:medero/cho.git

7. ssh [email protected] -v me dá uma autenticação bem-sucedida

8. Uma coisa estranha é que o nome de usuário com o qual ele me saúda foi tanexado a ele. Meu nome de usuário do github é medero, não medert.

Oi mederot! Você foi autenticado com sucesso, mas o GitHub não fornece acesso ao shell.

9. Estou não atrás de um proxy ou firewall

10. A chave é oferecida, aqui está a saída de -v:

debug1: Host 'github.com' is known and matches the RSA host key.
debug1: Found key in /home/meder/.ssh/known_hosts:58
debug1: ssh_rsa_verify: signature correct
debug1: SSH2_MSG_NEWKEYS sent
debug1: expecting SSH2_MSG_NEWKEYS
debug1: SSH2_MSG_NEWKEYS received
debug1: SSH2_MSG_SERVICE_REQUEST sent
debug1: SSH2_MSG_SERVICE_ACCEPT received
debug1: Authentications that can continue: publickey
debug1: Next authentication method: publickey
debug1: Offering public key: /home/meder/.ssh/id_rsa
debug1: Remote: Forced command: gerve mederot
debug1: Remote: Port forwarding disabled.
debug1: Remote: X11 forwarding disabled.
debug1: Remote: Agent forwarding disabled.
debug1: Remote: Pty allocation disabled.
debug1: Server accepts key: { some stuff, dont know if i should share it

debug1: Remote: Forced command: gerve mederot
debug1: Remote: Port forwarding disabled.
debug1: Remote: X11 forwarding disabled.
debug1: Remote: Agent forwarding disabled.
debug1: Remote: Pty allocation disabled.
debug1: Authentication succeeded (publickey).

11. Aqui estão os comandos que usei

mkdir cho
git init
touch README
git add README
git commit -m 'test'
git remote add origin [email protected]:medero/cho.git
git push -u origin master

12. Não quero criar uma nova chave SSH.

13. Se eu clone usando ssh e faço uma edição, um commit e um git push, obtenho exatamente a mesma coisa.

14. Aqui está o erro real:

$ git push
ERROR: Permission to medero/cho.git denied to mederot.
fatal: The remote end hung up unexpectedly

15. Configurei meu nome de usuário e token github:

$ git config --global github.user medero $ git config --global github.token 0123456789yourf0123456789tokenDefine o token GitHub para todas as instâncias git no sistema

16. Confirmei que meu nome de usuário do github NÃO é mederote meu token do github ESTÁ CORRETO de acordo com a página da minha conta (validado nos primeiros 2 caracteres e nos últimos 2 caracteres).

17. Para confirmar # 16, ~ / .gitconfig contém

[github]
    token = mytoken...
    user = medero

18. Eu fiz ssh-key add ~/.ssh/id_rsase for necessário ...

TEORIAS:

Eu suspeito que há algo estranho porque quando eu obtenho a autenticação do ssh, a saudação do usuário é mederote não medero, que é minha conta. Será que algo em minha conta do github pode estar incorretamente armazenado em cache?

Eu também suspeito de alguma estranheza de cache ssh local porque se eu mv ~/.ssh/id_rsa KAKAe mv ~/.ssh/id_rsa.pub POOPOO, e fizer ssh [email protected] -v, ele ainda me autentica e diz que atende meu /home/meder/.ssh/id_rsa quando eu renomei-o ?! Tem que ser cacheado ?!

Na etapa 18, suponho que você quer dizer ssh-add ~/.ssh/id_rsa? Se sim, isso explica o seguinte:

Eu também suspeito de alguma estranheza de cache de ssh local porque se eu mv ~ / .ssh / id_rsa KAKA e mv ~ / .ssh / id_rsa.pub POOPOO, e faço ssh [email protected] -v, ele ainda me autentica e diz que serve meu /home/meder/.ssh/id_rsa quando mudei o nome ?! Tem que ser cacheado ?!

... já que ssh-agentestá armazenando sua chave em cache.

Se você olhar no GitHub, verá que existe uma conta mederot . Tem certeza de que isso não tem nada a ver com você? O GitHub não deve permitir que a mesma chave pública SSH seja adicionada a duas contas, pois quando você está usando os [email protected]:...URLs ele está identificando o usuário com base na chave SSH. (Que isso não deveria ser confirmado aqui .)

Então, eu suspeito (em ordem decrescente de probabilidade) que um dos seguintes é o caso:

1. Você criou a conta mederot anteriormente e adicionou sua chave SSH a ela.
2. Outra pessoa obteve uma cópia da sua chave pública e a adicionou à conta do mederot GitHub.
3. Há um bug horrível no GitHub.

Se 1 não for o caso, eu relataria isso ao GitHub, para que eles pudessem verificar cerca de 2 ou 3.

Mais :

ssh-add -l verifique se há mais de uma identificação existente se sim, remova-o por ssh-add -d "aquele arquivo de chave"

Depois de pesquisar no Google por alguns dias, descobri que esta é a única pergunta semelhante à minha situação.

Porém, acabei de resolver o problema! Portanto, estou colocando minha resposta aqui para ajudar qualquer pessoa que esteja procurando por esse problema.

Aqui está o que eu fiz:

1. Abra "Keychain Access.app" (você pode encontrá-lo no Spotlight ou LaunchPad)

2. Selecione "Todos os itens" na categoria

3. Pesquisar "git"

4. Exclua todos os itens antigos e estranhos

5. Tente empurrar novamente e funcionou

Se o problema estiver surgindo no Windows, remova as credenciais do histórico do Windows.

• Vá para o Gerenciador de credenciais
• Vá para as credenciais do Windows
• Exclua as entradas em Credenciais genéricas
• Tente conectar-se novamente. Desta vez, ele deve solicitar o nome de usuário e a senha corretos.

remover credenciais do git

No Mac, se você tiver vários logins GitHub e não estiver usando SSH, force o login correto usando:

git remote set-url origin https://[email protected]/username/repo-name.git

Isso também funciona se você estiver tendo problemas para enviar para um repositório privado.

É devido a um conflito.

Limpe todas as chaves do ssh-agent

ssh-add -d ~/.ssh/id_rsa
ssh-add -d ~/.ssh/github

Adicione a chave ssh do github

ssh-add   ~/.ssh/github

Deve funcionar agora.

Estou usando o Mac e o problema é resolvido excluindo o registro github do aplicativo de acesso às chaves: Aqui está o que eu fiz:

1. Abra "Keychain Access.app" (você pode encontrá-lo no Spotlight ou noLaunchPad)
2. Selecione "Todos os itens" na categoria
3. Pesquisar "git"
4. Exclua todos os itens antigos e estranhos Tente empurrar novamente e funcionou

As etapas acima foram copiadas de @spyar para facilitar.

Acho que a solução é a mesma que @spyar fornece, que é o Keychain Access aplicativo armazenado com o nome de usuário antigo.

Existem 2 soluções para esta situação:

1. Exclua as informações no Keychain Access por
   • Abra o aplicativo Keychain Access
   • Pesquisar github
   • Excluir credenciais correspondentes

Ou

2. Se você quiser usar a chave ssh . Você acabou de alterar o url do Repo de https

https://github.com/username/repo.git

para dentro

[email protected]: username / repo.git

Espero que isto ajude.

Recentemente, encontrei esse problema em um repositório antigo em minha máquina que foi enviado por push usando https. as etapas 5 e 6 resolveram meu problema redefinindo o url remoto para meu repo usando o url https para o url ssh

verificar se o remoto está usando o url https

> git remote -v
origin  https://github.com/ExampleUser/ExampleRepo.git (fetch)
origin  https://github.com/ExampleUser/ExampleRepo.git (push)

em seguida, reconfigurando a origem para usar o url ssh

> git remote set-url origin [email protected]:ExampleUser/ExampleRepo.git

verificando novo controle remoto

> git remote -v
origin  [email protected]:ExampleUser/ExampleRepo.git (fetch)
origin  [email protected]:ExampleUser/ExampleRepo.git (push)

poderia agora com sucesso git push -u origin

Ainda não tenho certeza de qual configuração eu teria alterado que poderia ter causado a falha do push quando o remoto é https, mas essa foi a solução para o meu problema

Eu tive o mesmo problema que você. Depois de muito tempo pesquisando no Google, descobri que meu erro foi causado por vários usuários que adicionaram a mesma chave em suas contas.

Então, aqui está minha solução: deletar a chave ssh do usuário errado (posso fazer isso porque o usuário errado também é minha conta). Se o usuário errado não for sua conta, você pode precisar alterar sua chave ssh, mas eu não acho que isso vá acontecer.

E acho que seu problema pode ser causado por um erro de digitação no nome de suas contas.

Este problema também é causado por:

Se você estiver em um mac / linux, e estiver usando 'ControlMaster' em seu ~ / .ssh / config, pode haver alguns processos mestre de controle ssh em execução.

Para encontrá-los, execute:

ps aux | grep '\[mux\]'

E mate os relevantes.

Eu também me deparei com isso, o que causou isso para mim é que ao clonar o repositório para o qual estava enviando minhas alterações, peguei o URL clone de uma guia anônima sem fazer login. (Ainda não tenho ideia de como isso afeta). Isso por algum motivo levou o git a escolher outra conta de usuário. Quando tentei novamente em uma página de login adequada, funcionou normalmente para mim.

Encontrei este erro ao usar o Travis CI para implantar conteúdo , que envolvia enviar edições para um repositório.

Acabei resolvendo o problema atualizando o token de acesso pessoal GitHub associado à conta Travis com a public_repopermissão de acesso ao escopo: