Как да поправите грешката „Отказано разрешение (публичен ключ)“ в GitHub SSH

Текущата документация на GitHub за отстраняване на проблеми с SSH, проверена на 13 септември 2026 г., все още третира Permission denied (publickey)като неуспешно удостоверяване: GitHub отхвърли SSH връзката, защото не прие използваем публичен ключ за представените от вас акаунт и връзка. Най-бързият начин да го поправите е да проверите връзката в определен ред, вместо незабавно да изтривате ключовете или да генерирате нови. Официалната страница за отстраняване на проблеми с „Отказано разрешение (публичен ключ)“ на GitHub препоръчва да проверите сървъра, SSH потребителя, предлагания ключ и дали съответстващият публичен ключ е прикачен към вашия акаунт.

Един добър ремонт има два наблюдаеми резултата. Първо, ssh -T git@github.comидентифицира GitHub акаунта, който сте възнамерявали да използвате, и докладва за успешно удостоверяване. Второ, действителната команда на хранилището – като например git fetch, git pull, git pushили git clone– работи с хранилището, до което имате оторизиран достъп. Преминаването само на първия тест доказва SSH удостоверяване, а не разрешение за достъп до хранилището.

Контролен списък за бърза диагностика

1. Проверете местоназначението, SSH потребителя и отдалечения URL адрес

Преди да докоснете клавишите си, потвърдете, че се свързвате с GitHub.com и че потребителското име за SSH е буквално git. GitHub документира, че SSH връзките към GitHub.com трябва да използват gitпотребителя, а не вашето лично потребителско име за GitHub. Очаква се команда като тази ssh -T yourname@github.comда се провали.

git remote -v
ssh -vT git@github.com

За нормално SSH дистанционно управление на GitHub.com, URL адресът трябва да изглежда така:

git@github.com:OWNER/REPOSITORY.git

Ако дистанционното управление е грешно, коригирайте го с конфигурацията на Git за дистанционно управление, вместо да генерирате отново идентификационни данни:

git remote set-url origin git@github.com:OWNER/REPOSITORY.git

Също така избягвайте да изпълнявате обикновени Git команди с sudoили с повишени привилегии. GitHub отбелязва, че това може да доведе до това Git да работи в различна потребителска среда и следователно да използва различни SSH ключове от тези, които сте конфигурирали. Целта на този етап е проста: подробният изход трябва да показва опит за свързване на github.comпорт 22, освен ако умишлено не сте конфигурирали заобиколното решение за HTTPS порт, описано по-късно.

2. Потвърдете, че съществува използваем ключ и е зареден

Проверете локалната си SSH директория, преди да създавате нещо ново. Настоящите насоки на GitHub препоръчват първо да потърсите съществуваща поддържана двойка ключове.

ls -al ~/.ssh

Често срещаните имена на файлове с публични ключове по подразбиране включват id_ed25519.pub, id_ecdsa.pubи id_rsa.pub. GitHub вече не поддържа DSA ключове. Ако вече имате двойка ключове, която възнамерявате да използвате за GitHub, запазете я и продължете с проверката на агента.

ssh-add -l -E sha256

Здрав резултат изброява един или повече пръстови отпечатъци. Ако желаният ключ не е зареден, стартирайте SSH агента, както е подходящо за вашата среда, и добавете частния ключ:

eval "$(ssh-agent -s)"
ssh-add ~/.ssh/id_ed25519

В Windows, точната команда agent-start зависи от това дали използвате Git Bash, Windows OpenSSH, PowerShell или друга среда. Официалното ръководство за генериране на ключове и ssh-agent на GitHub предоставя специфични за платформата инструкции. Следвайте раздела за SSH клиента, който действително използвате; смесването на SSH на Git за Windows с Windows OpenSSH е често срещан източник на объркване.

Ако нямате двойка ключове

Генерирайте такъв само когато предишната проверка покаже, че нямате подходящ ключ, който искате да използвате. Настоящите инструкции на GitHub препоръчват Ed25519 за стандартен софтуерен ключ, когато се поддържа:

ssh-keygen -t ed25519 -C "your_email@example.com"

Използвайте парола, ако отговаря на вашите изисквания за сигурност. SSH агентът може да кешира отключения личен ключ за вашата сесия. Никога не качвайте и не поставяйте самия файл с личния ключ в GitHub; файлът, завършващ на , .pubе публичният ключ, предназначен за регистрация на акаунт.

3. Прикачете съответстващия публичен ключ към правилния GitHub акаунт

Наличието на локален ключ не е достатъчно. GitHub трябва да има съответстващ публичен ключ, свързан с акаунта, който трябва да се удостовери. Покажете публичния ключ и след това копирайте целия ред:

cat ~/.ssh/id_ed25519.pub

В GitHub отворете Настройки , след това SSH и GPG ключове , изберете Нов SSH ключ или Добавяне на SSH ключ , изберете ключ за удостоверяване и поставете публичния ключ. Тези етикети съответстват на текущата официална документация на GitHub за добавяне на SSH ключ .

Сравнете пръстови отпечатъци, когато не сте сигурни кой локален ключ съответства на записа в GitHub:

ssh-add -l -E sha256

Ако хранилището принадлежи на организация, която използва SAML еднократно влизане, добавянето на ключа към вашия акаунт може да не е достатъчно. GitHub документира, че SSH ключ може също да изисква оторизация от организацията. В Настройки > SSH и GPG ключове използвайте Конфигуриране на SSO за ключа и оторизирайте съответната организация, когато този контрол е наличен. Вижте ръководството за оторизация на SSO за SSH ключ на GitHub .

4. Тествайте удостоверяването независимо от Git

Не използвайте git pushкато единствен тест. Тествайте SSH директно:

ssh -T git@github.com

Съобщението за успех трябва да поздрави потребителското ви име в GitHub и да обясни, че GitHub не предоставя достъп до shell. GitHub също така отбелязва, че този тест може да приключи със статус код 1, дори когато удостоверяването е успешно, така че го преценете по съобщението за удостоверяване, вместо да очаквате нормален интерактивен shell.

Ако тестът все още завършва на Permission denied (publickey), изпълнете подробен режим:

ssh -vT git@github.com

Потърсете редове като Offering public key. Ако логът никога не предлага очаквания от вас ключ, проблемът е в локалния избор на ключ или конфигурацията на агента. Ако желаният ключ е предложен, но е отхвърлен, проверете дали този публичен ключ е прикачен към правилния GitHub акаунт и дали е необходима SSO авторизация.

Няколко GitHub акаунта: проверете коя самоличност действително се използва

Ако използвате служебен и личен акаунт на един и същ компютър, успешното SSH удостоверяване може все още да доведе до грешен акаунт. GitHub документира използването IdentitiesOnly=yesна специфичен файл за самоличност, за да контролира кой ключ SSH предлага. За еднократна диагностика:

ssh -v -o "IdentitiesOnly=yes" -i ~/.ssh/work_ed25519 git@github.com

Ако GitHub поздрави грешно потребителско име, значи сте открили несъответствието. Конфигурирайте отделни ключове или псевдоними на хостове, вместо да изтривате и добавяте ключове многократно. Официалното ръководство за множество акаунти на GitHub разглежда този случай по-подробно.

5. Опитайте отново командата за хранилище, след което променете подхода само ако доказателствата сочат другаде

След като ssh -T git@github.comсе удостоверите като очаквания потребител, опитайте отново действителната операция с хранилището:

git fetch origin
git pull
git push

Ако SSH удостоверяването е успешно, но Git сега докладва грешка в разрешенията, специфични за хранилището, спрете промяната на SSH ключа. В този момент ключът вече е свършил своята работа. Проверете дали удостовереният акаунт има достъп до хранилището, дали собственикът и името на хранилището в отдалечения URL адрес са правилни и дали организацията е предоставила необходимата роля. Отделната страница за отстраняване на неизправности с разрешенията за хранилище на GitHub обяснява случая, в който ключът принадлежи на акаунт без достъп.

Ако порт 22 е блокиран

Защитна стена или прокси сървър може да попречи на валидна SSH настройка да достигне GitHub на порт 22. Тествайте документираната крайна точка на GitHub за SSH през HTTPS:

ssh -T -p 443 git@ssh.github.com

Името на хоста е ssh.github.com, а не github.com, за този директен тест на порт-443. Ако работи, GitHub документира тази SSH конфигурация:

Host github.com
    Hostname ssh.github.com
    Port 443
    User git

След това тествайте отново с ssh -T git@github.com. Вижте ръководството на GitHub за SSH през порт 443 . Това решение не е приложимо за всяка GitHub Enterprise среда и прокси сървърите все още могат да пречат.

Как да разберете кога да спрете да опитвате едно и също решение

Често срещани поправки, които често губят време

Генериране на ключ след ключ без проверка какво предлага SSH. Повече ключове могат да затруднят избора. Използвайте първо ` ssh -vTи` ssh-add -l -E sha256.

Използвайки потребителското си име в GitHub преди @github.com. SSH крайната точка на GitHub очаква SSH потребителя git. Вашата GitHub идентичност се определя от публичния ключ, който GitHub разпознава.

Качване на частния ключ. Не правете това. GitHub се нуждае от публичната .pubстойност; частният ключ остава на вашата машина или одобрено хранилище за ключове.

Ако приемем, че един успешен SSH тест гарантира достъп до push файлове. Това доказва удостоверяване на акаунта. Авторизацията на хранилището е отделна проверка.

Игнориране на SSO. Ресурсите на организацията могат да изискват допълнително SSH-ключово удостоверяване, дори когато ключът е наличен в личния ви акаунт.

Използване на Git команди с повишени права. Стартирането на Git като друг потребител на операционната система може да промени коя домашна директория, SSH конфигурация, агент и ключове се използват.

Кога HTTPS е по-добрият отговор

SSH не е задължителен. GitHub поддържа и HTTPS отдалечени сървъри. Ако заключена корпоративна мрежа, политика за управлявани крайни точки или прокси правят SSH непрактичен, превключването на отдалечената сървърна част на хранилището към HTTPS може да е по-лесно от борбата с мрежата. Това е промяна на метода за удостоверяване, а не поправка на SSH конфигурацията, така че го използвайте, когато вашата среда прави SSH нежелан, а не като начин за скриване на неразрешено несъответствие на ключове.

За SSH най-надеждната точка на спиране е базирана на доказателства: очакваният ключ е зареден, GitHub го разпознава като очаквания акаунт, организацията го оторизира, когато е необходимо, и реалната Git операция е успешна. Ако една от тези проверки се провали, променете само слоя, който е провалил. Това контролира процеса на отстраняване на неизправности и избягва ненужната подмяна на работещи ключове.

Официални препратки

• Документация на GitHub: Грешка – Отказано разрешение (публичен ключ)
• Документация на GitHub: Проверка за съществуващи SSH ключове
• Документация на GitHub: Генериране на нов SSH ключ и добавянето му към ssh-agent
• Документация на GitHub: Добавяне на нов SSH ключ към вашия GitHub акаунт
• Документация на GitHub: Тестване на вашата SSH връзка
• Документация на GitHub: Използване на SSH през HTTPS порт