El famoso "ERROR: permiso para .git denegado al usuario" de Git

Intenté buscar en Google y leer https://help.github.com/en/articles/connecting-to-github-with-ssh y varias guías. No puedo git push -u origin mastero git push origin master(el mismo comando).

He tenido mi cuenta de git durante al menos 2 años más o menos. He podido crear repositorios con éxito y push -u origin masterbien en mi computadora portátil, pero en este escritorio tengo problemas.

Esto es lo que probé:

1. He configurado mi nombre de usuario de git

2. He configurado mi correo electrónico de usuario de git

3. He subido el contenido de mi /home/meder/.ssh/id_rsa.pub a la página de la cuenta de github. He verificado que no pegué ningún espacio en blanco

4. He creado un ~ / .ssh / config con estos contenidos:

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

Modifiqué el .ssh a 700, id_rsa 600

5. He agregado el origen remoto adecuado sin cometer errores tipográficos :git remote add origin [email protected]:medero/cho.git

6. Para confirmar el número 5, aquí está mi .git / config. El directorio es correcto y no otro directorio:

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

7. ssh [email protected] -v me da una autenticación exitosa

8. Una cosa extraña es que el nombre de usuario con el que me saluda se ha tadjuntado. Mi nombre de usuario de github es medero, no medert.

¡Hola mederot! Se autenticó correctamente, pero GitHub no proporciona acceso de shell.

9. Soy no detrás de un proxy o servidor de seguridad

10. Se ofrece la clave, aquí está el resultado 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. Estos son los comandos que usé

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. No quiero crear una nueva clave SSH.

13. Si git clone usando ssh y hago una edición, confirmación y git push, obtengo exactamente lo mismo.

14. Aquí está el error real:

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

15. He configurado mi nombre de usuario de github y el token de github:

$ git config --global github.user medero $ git config --global github.token 0123456789yourf0123456789token Establece el token de GitHub para todas las instancias de git en el sistema

16. He confirmado que mi nombre de usuario de github NO lo es mederoty mi token de github ES CORRECTO según la página de mi cuenta (los primeros 2 caracteres validados y los últimos 2 caracteres).

17. Para confirmar # 16, ~ / .gitconfig contiene

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

18. Lo hice ssh-key add ~/.ssh/id_rsasi es necesario ...

TEORÍAS:

Sospecho que hay algo sospechoso porque cuando me autentico ssh, el saludo del usuario es mederoty no medero, que es mi cuenta. ¿Es posible que algo en mi cuenta de github esté almacenado en caché incorrectamente?

También sospecho alguna rareza de almacenamiento en caché ssh local porque si yo mv ~/.ssh/id_rsa KAKAy mv ~/.ssh/id_rsa.pub POOPOO, y lo hago ssh [email protected] -v, todavía me autentica y dice que sirve a mi /home/meder/.ssh/id_rsa cuando lo renombré. ¡¿Tiene que estar en caché ?!

En el paso 18, supongo que te refieres a ssh-add ~/.ssh/id_rsa? Si es así, eso explica esto:

También sospecho alguna rareza del almacenamiento en caché ssh local porque si mv ~ / .ssh / id_rsa KAKA y mv ~ / .ssh / id_rsa.pub POOPOO, y hago ssh [email protected] -v, todavía me autentica y dice que sirve mi /home/meder/.ssh/id_rsa cuando le cambié el nombre? ¡¿Tiene que estar en caché ?!

... ya que ssh-agentestá almacenando en caché su clave.

Si miras en GitHub, hay una cuenta mederot . ¿Estás seguro de que esto no tiene nada que ver contigo? GitHub no debería permitir que se agregue la misma clave pública SSH a dos cuentas, ya que cuando usas las [email protected]:...URL, identifica al usuario según la clave SSH. ( Aquí se confirma que esto no debería estar permitido ).

Entonces, sospecho (en orden decreciente de probabilidad) que uno de los siguientes es el caso:

1. Creaste la cuenta de mederot anteriormente y le agregaste tu clave SSH.
2. Alguien más ha obtenido una copia de su clave pública y la ha agregado a la cuenta mederot GitHub.
3. Hay un error horrible en GitHub.

Si 1 no es el caso, entonces informaría esto a GitHub, para que puedan verificar 2 o 3.

Más :

ssh-add -l compruebe si existe más de una identificación si es así, elimínela mediante ssh-add -d "ese archivo de clave"

Después de buscar en Google durante unos días, descubrí que esta es la única pregunta similar a mi situación.

Sin embargo, ¡acabo de resolver el problema! Así que pongo mi respuesta aquí para ayudar a cualquier otra persona que busque este problema.

Aquí esta lo que hice:

1. Abra "Keychain Access.app" (puede encontrarlo en Spotlight o LaunchPad)

2. Seleccione "Todos los artículos" en la categoría

3. Buscar "git"

4. Elimina todos los elementos antiguos y extraños

5. Intente presionar de nuevo y simplemente FUNCIONÓ

Si el problema viene en Windows, elimine las Credenciales del historial de Windows.

• Ir al administrador de credenciales
• Ir a Credenciales de Windows
• Eliminar las entradas en Credenciales genéricas
• Intenta conectarte de nuevo. Esta vez, debería pedirte el nombre de usuario y la contraseña correctos.

eliminar credenciales de git

En Mac, si tiene varios inicios de sesión de GitHub y no está usando SSH, fuerce el inicio de sesión correcto usando:

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

Esto también funciona si tiene problemas para enviar a un repositorio privado.

Es debido a un conflicto.

Borrar todas las claves de ssh-agent

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

Agregar la clave ssh de github

ssh-add   ~/.ssh/github

Debería funcionar ahora.

Estoy usando Mac y el problema se resuelve eliminando el registro github de la aplicación de acceso al llavero: Esto es lo que hice:

1. Abra "Keychain Access.app" (puede encontrarlo en Spotlight o LaunchPad)
2. Seleccione "Todos los artículos" en la categoría
3. Buscar "git"
4. Elimine todos los elementos antiguos y extraños Intente presionar nuevamente y simplemente FUNCIONÓ

Los pasos anteriores se copian de @spyar para mayor facilidad.

Encuentro que la solución es la misma que @spyar proporciona, que es la aplicación Keychain Access que almacena el nombre de usuario anterior.

Hay 2 soluciones para esta situación:

1. Elimina la información en Acceso a llaveros por
   • Abrir la aplicación Keychain Access
   • Buscar github
   • Eliminar las credenciales correspondientes

O

2. Si usa desea usar la clave ssh . Simplemente cambie su URL de Repo de https

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

dentro

[email protected]: nombre de usuario / repo.git

Espero que esto ayude.

Recientemente me encontré con este problema en un repositorio antiguo en mi máquina que había sido subido usando https. Los pasos 5 y 6 resolvieron mi problema al volver a configurar la URL remota para mi repositorio para que no use la URL https en la URL ssh

comprobar el control remoto está usando la URL https

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

luego restablecer el origen para usar la URL ssh

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

verificando nuevo control remoto

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

ahora podría con éxito git push -u origin

Todavía no estoy seguro de qué configuración habría cambiado que podría haber causado que el empuje fallara cuando el control remoto es https, pero esta fue la solución a mi problema

Yo tenía el mismo problema que tú. Después de pasar mucho tiempo buscando en Google, descubrí que mi error fue causado por varios usuarios que habían agregado la misma clave en sus cuentas.

Entonces, aquí está mi solución: elimine la clave ssh del usuario incorrecto (puedo hacerlo porque el usuario incorrecto también es mi cuenta). Si el usuario incorrecto no es su cuenta, es posible que deba cambiar su clave ssh, pero no creo que esto suceda.

Y creo que su problema puede deberse a un error de escritura en el nombre de su cuenta.

Este problema también es causado por:

Si está en un mac / linux y está usando 'ControlMaster' en su ~ / .ssh / config, puede haber algunos procesos maestros de control ssh en ejecución.

Para encontrarlos, ejecute:

ps aux | grep '\[mux\]'

Y mata a los relevantes.

Yo también me encontré con esto, lo que me causó esto es que mientras clonaba el repositorio al que estaba presionando mis cambios, recogí la URL clonada de una pestaña de incógnito sin iniciar sesión (todavía no tengo ni idea de cómo afecta). Eso, por alguna razón, llevó a git a elegir otra cuenta de usuario. Cuando lo probé de nuevo desde una página debidamente registrada, funcionó como de costumbre para mí.

Encontré este error al usar Travis CI para implementar contenido , lo que implicaba enviar ediciones a un repositorio.

Finalmente resolví el problema actualizando el token de acceso personal de GitHub asociado con la cuenta de Travis con el public_repopermiso de acceso al alcance: