Відомий Git "Помилка: користувачеві заборонено дозвіл на .git"


118

Я спробував гуглінг і читав 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 git@github.com:medero/cho.git

6. Щоб підтвердити номер 5, ось мій .git / config. Каталог правильний, а не інший каталог:

[remote "origin"]
        fetch = +refs/heads/*:refs/remotes/origin/*
        url = git@github.com:medero/cho.git

7. ssh git@github.com -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 git@github.com: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 git@github.com -v, він все ще підтверджує мене і каже, що він обслуговує мій /home/meder/.ssh/id_rsa, коли я перейменував його ?! Це потрібно кешувати ?!


Я використовую "Github для Windows" і у мене виникли подібні проблеми при перемиканні між двома обліковими записами Github. Ось моє рішення: stackoverflow.com/questions/18565876/…
Аліса,

Якщо ви хочете , щоб натиснути від 2 -х різної місцевої РЕПО з відповідними їх походження вилученого репо , то перевірити це: stackoverflow.com/q/63291726/12033855
an4s911

Відповіді:


35

На кроці 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 до двох облікових записів, оскільки, коли ви використовуєте git@github.com:...URL-адреси, він ідентифікує користувача на основі ключа SSH. (Це не можна допускати, підтверджується тут .)

Отже, я підозрюю (у порядку зменшення ймовірності), що це одна з наступних ситуацій:

  1. Ви створили обліковий запис mederot раніше і додали до нього свій ключ SSH.
  2. Хтось ще отримав копію вашого відкритого ключа та додав її до акаунта mederot GitHub.
  3. У GitHub є жахлива помилка.

Якщо 1 не так, я б повідомив про це GitHub, щоб вони могли перевірити приблизно 2 або 3.

Більше:

ssh-add -l перевірте, чи існує більше ніж одна ідентифікація, якщо так, видаліть її за допомогою ssh-add -d "цей файл ключа"


Прекрасна допомога Марку! Це виправило і для мене.
Leachy Peachy

Це було все. Ти врятував мені величезний головний біль. Тепер мені просто запам’ятати, щоб запускати ssh-add ...кожен раз, коли я хочу переключити свої логіни github / ssh.
Серін

Чомусь ssh-add -d <keyfile>не працює. (Здійснюється вручну видалення файлів tyhe.) Кешування, яке ви згадали, має бути якось перезавантажено вручну. Як?
not2qubit

ssh-add -d-> "Не вдалося відкрити з'єднання з вашим агентом аутентифікації."
Алекс

Це ssh-addбув шматочок, який зробив це для мене. Дякую!
rayryeng

160

Після Googling протягом декількох днів я виявив, що це єдине питання, схоже на мою ситуацію.

Однак я просто вирішив проблему! Отож, я даю тут свою відповідь, щоб допомогти іншим, хто шукає це питання.

Ось що я зробив:

  1. Відкрийте "Keychain Access.app" (Ви можете знайти його в Spotlight або LaunchPad)

  2. Виберіть "Усі елементи" в категорії

  3. Пошук "git"

  4. Видаліть кожен старий та дивний елемент

  5. Спробуйте знову натиснути, і це просто РОБОТИ


17
Великий палець приятель. Ти герой.
Принц Бансал

1
Чорт так, нарешті, після боротьби з незліченними ключами SSH, це відповідь, яка спрацювала! Здається, що для Mac та https доступу використовується брелок. Божевільний.
Патрік Чу

1
БЛАГОДУЙТЕ ВИ ВІДКРИТИ, щоб вирішити це за тиждень
Джон Хендершот

1
Виглядає дуже корисно, але незрозуміло, що таке old & strange. Я збираюся зіпсувати набір речей ..?
геотеорія

1
@geotheory Ці old & strangeречі означають старі елементи дати та неправильну електронну пошту чи ім’я користувача. Ви можете сортувати таблицю за Date Modified.
Аліса Чан

91

Якщо проблема виникає у Windows, вийміть облікові дані з історії Windows.

  • Перейдіть до диспетчера кредитів
  • Перейдіть до облікових даних Windows
  • Видаліть записи в розділі Загальні облікові дані
  • Спробуйте підключитися ще раз. Цього разу він повинен підказати правильне ім’я користувача та пароль.

введіть тут опис зображення введіть тут опис зображення

видалити облікові дані з git


2
Ідеально. Я отримував 403 доступу до облікового запису, яким я більше не користуюся. Зараз вирішено.
Антон Епіхін

1
для мене було достатньо лише видалення облікових даних github.com
Bart De Boeck

І там ви можете змінити своє ім’я користувача і що завгодно. Це шлях.
WesternGun

Насправді це працювало і для мене, але що б я зробив, якби у мене були 2 різні облікові записи?
an4s911

22

На Mac, якщо у вас є кілька логінів GitHub і не використовуєте SSH, примушуйте правильно ввійти, використовуючи:

git remote set-url origin https://username@github.com/username/repo-name.git

Це також працює, якщо у вас виникають проблеми з переходом до приватного сховища.


1
Дякую, це працювало для мене. Це запропонувало мені ввести пароль, і я зміг натиснути після надання свого пароля. Цінується!
піксель

... але це не вирішило проблему для мене в Windows, тільки на Mac
піксель

... але @Fahid offerson вище для очищення облікових даних у Windows допоміг
піксель

Ти герой.
Вайбхав

Це правильна відповідь, якщо ми кілька проектів github, які належать до різних облікових записів
Gangadhar JANNU

14

Її через конфлікт.

Очистити всі ключі від ssh-агента

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

Додайте ключ gshub ssh

ssh-add   ~/.ssh/github

Це має працювати зараз.


3
також ssh-add -Dвидаляє всі ідентичності, може бути корисним, якщо агент потрапляє в недійсний стан.
Сем

6

Я використовую Mac, і проблему вирішують, видаляючи запис github з програми доступу до брелоків: ось що я зробив:

  1. Відкрийте "Keychain Access.app" (Ви можете знайти його в Spotlight абоLaunchPad)
  2. Виберіть "Усі елементи" в категорії
  3. Пошук "git"
  4. Видаліть всі старі та дивні елементи Спробуйте натиснути ще раз, і це просто РОБОТИ

Наведені вище кроки скопійовані з @spyar для зручності.


6

Я вважаю, що рішення таке ж, як і @spyar, який є доступом до брелоків додаток , що зберігає старе ім'я користувача.

Для цієї ситуації є два рішення:

  1. Видаліть інформацію в Keychain Access за допомогою
    • Відкрийте додаток Keychain Access
    • Шукати github
    • Видаліть відповідні облікові дані

Або

  1. Якщо ви хочете використовувати ключ ssh . Ви просто змінюєте URL-адресу Repo з https

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

в

git@github.com: ім'я користувача / repo.git

Сподіваюся, це допомагає.


2

Нещодавно я зіткнувся з цим випуском для старого репо на моїй машині, який був висунутий за допомогою 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 git@github.com:ExampleUser/ExampleRepo.git

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

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

тепер міг успішно git push -u origin

Я все ще не впевнений, яке налаштування я змінив би, що могло спричинити невдачу натискання, коли пульт буде https, але це було вирішенням моєї проблеми


ПОМИЛКА: Дозвіл на unrealcv / синтетичний-комп'ютер-бачення.git відмовлено monajalal. fatal: Не вдалося прочитати з віддаленого сховища. Переконайтеся, що у вас є правильні права доступу та сховище існує.
Мона Джалал

1

У мене була така ж проблема, як у вас. Після довгого часу роботи в Google, я з'ясував, що мою помилку викликали багато користувачів, які додали один і той же ключ у своїх облікових записах.

Отже, ось моє рішення: видаліть ssh-ключ невірного користувача (я можу це зробити, тому що неправильний користувач - це також мій обліковий запис). Якщо неправильний користувач не є вашим обліковим записом, можливо, вам доведеться змінити свій ssh-ключ, але я не думаю, що це станеться.

І я думаю, що ваша проблема може бути викликана помилкою помилки в назві облікових записів.


0

Ця проблема також викликана:

Якщо ви перебуваєте на mac / linux та використовуєте 'ControlMaster' у вашому ~ / .ssh / config, можливо, запущені основні процеси управління ssh.

Щоб знайти їх, запустіть:

ps aux | grep '\[mux\]'

І вбийте відповідних.


0

Я теж натрапив на це, що для мене це спричинило те, що під час клонування репо, на який я підштовхував свої зміни, я взяв URL-адресу клонування з вкладки анонімного режиму, не входячи в систему (я все ще не знаю, як це впливає). Це чомусь призвело до того, щоб git вибирав інший обліковий запис користувача. Коли я знову спробував це з належної сторінки, що підписався, він працював як зазвичай для мене.


0

Я зіткнувся з цією помилкою під час використання програми Travis CI для розгортання контенту , яка передбачала переміщення змін до сховища.

Я врешті-решт вирішив цю проблему, оновивши маркер доступу GitHub, пов’язаний із обліковим записом Travis, на public_repoдозвіл доступу:

Виберіть <code> public_repo </code>

Використовуючи наш веб-сайт, ви визнаєте, що прочитали та зрозуміли наші Політику щодо файлів cookie та Політику конфіденційності.
Licensed under cc by-sa 3.0 with attribution required.