Відомий 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.