Git знаменитый "ОШИБКА: разрешение на. Git отклонено пользователю"

Я попробовал поискать в Google и прочитать https://help.github.com/en/articles/connecting-to-github-with-ssh и различные руководства. Я не могу git push -u origin master или git push origin master (та же команда).

У меня был свой аккаунт Git по крайней мере 2 года или около того. Я успешно смог создать репозитории и push -u origin master нормально на своем ноутбуке, но на этом рабочем столе у меня проблемы.

Вот что я попробовал:

1. Я настроил свое имя пользователя git

2. Я настроил свою электронную почту пользователя git

3. Я загрузил содержимое моего /home/meder/.ssh/id_rsa.pub на страницу учетной записи github. Я подтвердил, что не вставлял пробелы

4. Я создал ~/.ssh/config со следующим содержимым:

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

Я изменил .ssh на 700, id_rsa 600

5. Я добавил правильное удаленное происхождение без опечаток: git remote add origin [email protected]:medero/cho.git

6. Для подтверждения # 5, вот мой .git/config. Каталог правильный, а не другой каталог:

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

7. ssh [email protected] -v дает мне успешную аутентификацию

8. Одна странная вещь - к нему добавлено имя пользователя, с которым он встречает меня t. Моё имя пользователя на github - medero, а не medert.

Привет Медеро! Вы успешно аутентифицирован, но GitHub не обеспечить доступ к оболочке.

9. Я не являюсь за прокси-сервером или брандмауэром

10. Ключ предлагается, вот вывод из -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. Вот команды, которые я использовал

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. Я не хочу создавать новый ключ SSH.

13. Если я выполняю git clone с помощью ssh и выполняю редактирование, фиксацию и git push, то получаю точно такую же вещь.

14. Здесь актуальная ошибка:

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

15. Я настроил свое имя пользователя github и токен github:

$ git config --global github.user medero $ git config --global github.token 0123456789yourf0123456789token Устанавливает токен GitHub для всех экземпляров git в системе

16. Я подтвердил, что мое имя пользователя github НЕ mederot, и мой токен github является ПРАВИЛЬНЫМ для страницы моего аккаунта (проверены первые 2 символа и последние 2 символа).

17. Для подтверждения # 16, ~/.gitconfig содержит

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

18. Я сделал ssh-key add ~/.ssh/id_rsa, если это даже необходимо...

Теории:

Я подозреваю, что там что-то подозрительное, потому что когда я получаю ssh-аутентификацию, приветствие пользователя - mederot, а не medero, что является моим действием. Возможно, что-то в моем аккаунте github может быть неправильно кэшировано?

Я также подозреваю, что некоторые странные странные SSH-кеширование, потому что если я mv ~/.ssh/id_rsa KAKA и mv ~/.ssh/id_rsa.pub POOPOO и сделаю ssh [email protected] -v, он все еще аутентифицирует меня и говорит, что обслуживает мой /home/meder/.ssh/id_rsa, когда я его переименовал?! Это должно быть в кеше?!

Ответ 1

На шаге 18 я предполагаю, что вы имеете в виду ssh-add ~/.ssh/id_rsa? Если это так, то это объясняет следующее:

Я также подозреваю, что некоторые локальные ssh кэширование странности, потому что, если я mv ~/.ssh/id_rsa KAKA и mv ~/.ssh/id_rsa.pub POOPOO, и сделать ssh git @github.com -v, он все еще проверяет подлинность меня и говорит, что он служит моему /home/meder/.ssh/id_rsa, когда я переименовал его?! Его нужно кэшировать?!

... поскольку ssh-agent кэширует ваш ключ.

Если вы посмотрите на GitHub, есть учетная запись mederot. Вы уверены, что это не имеет никакого отношения к вам? GitHub не должен позволять добавлять один и тот же открытый ключ SSH к двум учетным записям, поскольку, когда вы используете URL [email protected]:..., он идентифицирует пользователя на основе ключа SSH. (Чтобы это не было разрешено, подтверждается здесь.)

Итак, я подозреваю (в порядке убывания вероятности), что имеет место одно из следующего:

Вы создали учетную запись mederot ранее и добавили к ней свой SSH-ключ.
Кто-то еще получил копию вашего открытого ключа и добавил его в учетную запись meditot GitHub.
В GitHub есть ужасная ошибка.

Если это не так, я сообщаю об этом GitHub, поэтому они могут проверять около 2 или 3.

Дополнительно:

ssh-add -l проверить, существует ли более одного идентификатора если да, удалите его с помощью ssh-add -d "этого ключевого файла"

Ответ 2

После нескольких дней поиска в Google я обнаружил, что это единственный вопрос, похожий на мою ситуацию.

Однако я просто решил проблему! Поэтому я размещаю свой ответ здесь, чтобы помочь кому-либо еще в поиске этой проблемы.

Вот что я сделал:

Откройте "Keychain Access.app" (вы можете найти его в Spotlight или LaunchPad)
Выберите "Все предметы" в категории
Поиск "git"
Удалить все старые и странные вещи
Попробуйте нажать еще раз, и он просто работал

Ответ 3

Если проблема возникает в Windows, удалите учетные данные из истории Windows.

Перейти в Диспетчер учетных данных
Перейдите в учетные данные Windows
Удалить записи в разделе Общие учетные данные
Попробуйте снова подключиться. В это время он должен запросить правильное имя пользователя и пароль.

удалить учетные данные из git

Ответ 4

Из-за конфликта.

Удалить все ключи из ssh-agent

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

Добавить ключ gshub ssh

ssh-add   ~/.ssh/github

Теперь он должен работать.

Ответ 5

На Mac, если у вас несколько логинов GitHub и не используются SSH, принудительно введите логин, используя:

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

Это также работает, если у вас возникают проблемы с нажатием на частный репозиторий.

Ответ 6

Я использую Mac, и проблема решена, удалив запись github из приложения доступа к keychain: Вот что я сделал:

Откройте "Keychain Access.app" (вы можете найти его в Spotlight илиLaunchPad)
Выберите "Все элементы" в категории
Поиск "git"
Удалить все старые и странные предметы. Попробуйте снова нажать, и это просто РАБОТАЕТ.

Вышеуказанные шаги копируются из @spyar для удобства.

Ответ 7

Я считаю, что решение такое же, как @spyar, которое представляет собой приложение Keychain Access, которое хранит старое имя пользователя.

В этой ситуации есть 2 решения:

Удалить информацию в Доступ к брелокам
- Откройте Доступ к Keychain Access.
- Поиск github
- Удалить соответствующие учетные данные

Или

Если вы используете, хотите использовать ssh-ключ. Вы просто изменяете свой URL-адрес репо из https

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

git @github.com: имя пользователя /repo.git

Надеюсь, что это поможет.

Ответ 8

У меня была такая же проблема, как и вы. После долгого времени, проведенного Googling, я узнал, что моя ошибка была вызвана несколькими пользователями, которые добавили один и тот же ключ в свои учетные записи.

Итак, вот мое решение: удалить ssh-ключ неправильного пользователя (я могу это сделать, потому что неправильный пользователь также является моей учетной записью). Если неправильный пользователь не является вашей учетной записью, вам может потребоваться изменить свой ssh-ключ, но я не думаю, что это произойдет.

И я думаю, что ваша проблема может быть вызвана ошибкой ошибки в имени вашей учетной записи.

Ответ 9

Недавно я столкнулся с этой проблемой для старого репозитория на моей машине, который был загружен с помощью https. шаги 5 и 6 решили мою проблему, заново установив удаленный URL для моего репозитория, используя URL-адрес https для URL-адреса ssh

проверка удаленного использует URL-адрес https

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

затем заново установите источник для использования URL-адреса SSH

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

проверка нового пульта

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

теперь может успешно git push -u origin

я до сих пор не уверен, какую настройку я бы изменил, что могло привести к сбою push-сообщения, когда для пульта дистанционного управления установлен https, но это было решением моей проблемы.

Ответ 10

Эта проблема также вызвана:

Если вы используете mac/linux и используете "ControlMaster" в вашем файле ~/.ssh/config, могут выполняться некоторые управляющие процессы управления ssh.

Чтобы найти их, запустите:

ps aux | grep '\[mux\]'

И убейте соответствующих.

Ответ 11

Я тоже столкнулся с этим, что вызвало для меня то, что, клонируя репозиторий, на который я отправлял свои изменения, я взял URL-адрес клона со вкладки инкогнито, не выполняя вход (я до сих пор не знаю, как это повлияет). Это по какой-то причине привело к выбору другой учетной записи пользователя. Когда я попробовал это снова с надлежащей авторизованной страницы, это работало как обычно для меня.

Ответ 12

Я столкнулся с этой ошибкой при использовании Travis CI для развертывания контента, который включал передачу изменений в репозиторий.

В конце концов я решил эту проблему, обновив токен личного доступа GitHub, связанный с учетной записью Travis, с разрешением доступа области public_repo:

Ответ 13

Для меня решение, предложенное FAHID (для Windows) и LEANNE (для Mac), работало только. Спасибо вам обоим!