Jak opravit chybu „Oprávnění odepřeno (veřejný klíč)“ v GitHub SSH

Aktuální dokumentace GitHubu pro řešení problémů s SSH, zkontrolovaná 13. září 2026, stále chybu bere Permission denied (publickey)jako selhání ověření: GitHub odmítl připojení SSH, protože pro účet a připojení, které jste uvedli, nepřijal použitelný veřejný klíč. Nejrychlejším způsobem, jak to opravit, je ověřit připojení v určitém pořadí namísto okamžitého mazání klíčů nebo generování nových. Oficiální stránka GitHubu pro řešení problémů s odepřením přístupu (veřejný klíč) doporučuje zkontrolovat server, uživatele SSH, nabízený klíč a to, zda je k vašemu účtu připojen odpovídající veřejný klíč.

Dobrá oprava má dva pozorovatelné výsledky. Zaprvé ssh -T git@github.comidentifikuje účet GitHub, který jste chtěli použít, a oznámí úspěšné ověření. Zadruhé, skutečný příkaz repozitáře – například git fetch, git pull, git pushnebo git clone– funguje s repozitářem, ke kterému máte oprávnění přistupovat. Úspěšné složení pouze prvního testu prokáže SSH ověření, nikoli oprávnění k repozitáři.

Rychlý diagnostický kontrolní seznam

1. Ověřte cíl, uživatele SSH a vzdálenou URL adresu

Než se dotknete kláves, ověřte, že se připojujete ke GitHub.com a že uživatelské jméno SSH je doslova git. GitHub dokumentuje, že připojení SSH ke GitHub.com musí používat gituživatele, nikoli vaše osobní uživatelské jméno GitHubu. Příkaz jako ssh -T yourname@github.comje pravděpodobně selže.

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

Pro normální vzdálené připojení přes SSH na GitHub.com by URL adresa měla vypadat takto:

git@github.com:OWNER/REPOSITORY.git

Pokud je vzdálený přístup chybný, opravte ho pomocí konfigurace vzdáleného přístupu v Gitu, místo abyste znovu generovali přihlašovací údaje:

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

Také se vyhněte spouštění běžných příkazů Gitu s oprávněními sudonebo zvýšenými oprávněními. GitHub upozorňuje, že takové jednání může způsobit, že Git bude běžet v jiném uživatelském prostředí, a proto bude používat jiné klíče SSH, než jaké jste nakonfigurovali. Cíl v této fázi je jednoduchý: podrobný výstup by měl zobrazovat pokus o připojení na github.comportu 22, pokud jste záměrně nenakonfigurovali alternativní řešení portu HTTPS popsané později.

2. Ověřte, že existuje a je načten použitelný klíč.

Před vytvářením čehokoli nového zkontrolujte svůj lokální adresář SSH. Aktuální pokyny GitHubu doporučují nejprve vyhledat existující podporovaný pár klíčů.

ls -al ~/.ssh

Mezi běžné výchozí názvy souborů s veřejnými klíči patří id_ed25519.pub, id_ecdsa.puba id_rsa.pub. GitHub již nepodporuje klíče DSA. Pokud již máte pár klíčů, který chcete pro GitHub použít, ponechte si ho a pokračujte v kontrole agenta.

ssh-add -l -E sha256

V pořádku je uveden jeden nebo více otisků prstů. Pokud požadovaný klíč není načten, spusťte agenta SSH dle potřeby pro vaše prostředí a přidejte soukromý klíč:

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

Ve Windows závisí přesný příkaz agent-start na tom, zda používáte Git Bash, Windows OpenSSH, PowerShell nebo jiné prostředí. Oficiální průvodce generováním klíčů a ssh-agent na GitHubu poskytuje pokyny specifické pro danou platformu. Řiďte se částí pro SSH klienta, kterého skutečně používáte; směšování SSH z Gitu pro Windows s Windows OpenSSH je častým zdrojem nejasností.

Pokud nemáte pár klíčů

Vygenerujte jej pouze tehdy, když předchozí kontrola ukáže, že nemáte vhodný klíč, který chcete použít. Aktuální pokyny GitHubu doporučují Ed25519 jako standardní softwarový klíč, pokud je podporován:

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

Pokud heslo splňuje vaše bezpečnostní požadavky, použijte ho. Agent SSH může ukládat odemčený soukromý klíč pro vaši relaci do mezipaměti. Nikdy nenahrávejte ani nevkládejte samotný soubor se soukromým klíčem do GitHubu; soubor končící na .pubje veřejný klíč určený pro registraci účtu.

3. Připojte odpovídající veřejný klíč ke správnému účtu GitHub

Mít lokální klíč nestačí. GitHub musí mít odpovídající veřejný klíč přidružený k účtu, který se má ověřit. Zobrazte veřejný klíč a poté zkopírujte celý řádek:

cat ~/.ssh/id_ed25519.pub

Na GitHubu otevřete Nastavení , poté Klíče SSH a GPG , vyberte Nový klíč SSH nebo Přidat klíč SSH , vyberte ověřovací klíč a vložte veřejný klíč. Tyto popisky odpovídají aktuální oficiální dokumentaci GitHubu k přidání klíče SSH .

Porovnejte otisky prstů, pokud si nejste jisti, který lokální klíč odpovídá záznamu na GitHubu:

ssh-add -l -E sha256

Pokud repozitář patří organizaci, která používá jednotné přihlašování SAML, nemusí být přidání klíče k vašemu účtu dostatečné. GitHub dokumentuje, že klíč SSH může také vyžadovat autorizaci organizace. V Nastavení > Klíče SSH a GPG použijte pro klíč možnost Konfigurovat SSO a autorizujte příslušnou organizaci, pokud je tato kontrola k dispozici. Viz průvodce autorizací klíče SSO na GitHubu .

4. Otestujte autentizaci nezávisle na Gitu

Nepoužívejte git pushjako jediný test. Otestujte SSH přímo:

ssh -T git@github.com

Zpráva o úspěchu by měla přivítat vaše uživatelské jméno na GitHubu a vysvětlovat, že GitHub neposkytuje přístup k shellu. GitHub také poznamenává, že tento test může skončit se stavovým kódem 1, i když je ověření úspěšné, takže jej posuďte podle ověřovací zprávy, spíše než očekávat normální interaktivní shell.

Pokud test stále končí v Permission denied (publickey), spusťte podrobný režim:

ssh -vT git@github.com

Hledejte řádky jako Offering public key. Pokud protokol nikdy nenabídne očekávaný klíč, problém je ve výběru lokálního klíče nebo konfiguraci agenta. Pokud je zamýšlený klíč nabídnut, ale odmítnut, zkontrolujte, zda je daný veřejný klíč připojen ke správnému účtu GitHub a zda je vyžadováno autorizace SSO.

Více účtů GitHub: ověření, která identita se skutečně používá

Pokud používáte pracovní i osobní účet na stejném počítači, úspěšné ověření SSH může stále vést k nesprávnému účtu. Dokumentace GitHubu používá IdentitiesOnly=yesnebo specifický soubor identity k řízení toho, který klíč SSH nabízí. Pro jednorázovou diagnostiku:

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

Pokud GitHub přivítá nesprávné uživatelské jméno, zjistili jste neshodu. Namísto opakovaného mazání a opětovného přidávání klíčů nakonfigurujte samostatné klíče nebo aliasy hostitele. Oficiální průvodce GitHubem pro více účtů se tímto případem zabývá podrobněji.

5. Zkuste příkaz repozitáře znovu a poté změňte přístup pouze v případě, že důkazy ukazují jinam.

Jakmile ssh -T git@github.comse ověříte jako očekávaný uživatel, zkuste znovu skutečnou operaci s úložištěm:

git fetch origin
git pull
git push

Pokud je ověřování SSH úspěšné, ale Git nyní hlásí chybu oprávnění specifického pro repozitář, přestaňte měnit klíč SSH. V tomto okamžiku klíč již vykonal svou funkci. Ověřte, zda má ověřený účet přístup k repozitáři, zda jsou vlastník a název repozitáře ve vzdálené URL správné a zda organizace udělila požadovanou roli. Samostatná stránka GitHubu pro řešení problémů s oprávněními k repozitáři vysvětluje případ, kdy klíč patří účtu bez přístupu.

Pokud je port 22 blokován

Firewall nebo proxy může zabránit platnému nastavení SSH v přístupu k GitHubu na portu 22. Otestujte zdokumentovaný koncový bod SSH přes HTTPS na GitHubu:

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

Pro tento přímý test portu 443 je název hostitele ssh.github.com, nikoli github.com. Pokud to funguje, GitHub dokumentuje tuto konfiguraci SSH:

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

Pak to otestujte znovu s . Viz průvodce SSH přes port 443ssh -T git@github.com na GitHubu . Toto řešení se nevztahuje na všechna podniková prostředí GitHubu a proxy servery mohou stále rušit.

Jak poznat, kdy přestat zkoušet stejnou opravu

Běžné opravy, které často ztrácejí čas

Generování klíče za klíčem bez kontroly, co SSH nabízí. Více klíčů může ztížit výběr. Použijte nejprve ssh -vT`and` ssh-add -l -E sha256.

Používáte své uživatelské jméno GitHubu předtím @github.com. Koncový bod SSH GitHubu očekává uživatele SSH git. Vaše identita GitHubu je určena veřejným klíčem, který GitHub rozpoznává.

Nahrávání soukromého klíče. Nedělejte to. GitHub potřebuje veřejnou .pubhodnotu; soukromý klíč zůstává na vašem počítači nebo ve schváleném úložišti klíčů.

Za předpokladu úspěšného SSH testu je zaručen přístup k push e-mailům. Prokazuje se tím ověření účtu. Autorizace repozitáře je samostatná kontrola.

Ignorování SSO. Prostředky organizace mohou vyžadovat dodatečnou autorizaci pomocí SSH klíče, i když je klíč přítomen ve vašem osobním účtu.

Používání příkazů Gitu s oprávněními vyššího oprávnění. Spuštění Gitu jako jiného uživatele operačního systému může změnit, který domovský adresář, konfigurace SSH, agent a klíče se používají.

Kdy je HTTPS lepší odpovědí

SSH není povinné. GitHub podporuje i vzdálené připojení přes HTTPS. Pokud je SSH nepraktické kvůli uzamčené firemní síti, zásadám spravovaných koncových bodů nebo proxy, může být přepnutí vzdáleného připojení repozitáře na HTTPS jednodušší než bojovat se sítí. Jedná se o změnu metody ověřování, nikoli o opravu konfigurace SSH, takže jej používejte, když je vaše prostředí SSH nežádoucí, spíše než jako způsob, jak skrýt nevyřešený nesoulad klíčů.

Pro SSH je nejspolehlivějším bodem zastavení založený na důkazech: očekávaný klíč je načten, GitHub ho rozpozná jako očekávaný účet, organizace ho v případě potřeby autorizuje a skutečná operace Gitu je úspěšná. Pokud jedna z těchto kontrol selže, změňte pouze vrstvu, která selhala. Tím se udrží proces řešení problémů pod kontrolou a zabrání se zbytečné výměně funkčních klíčů.

Oficiální reference

• Dokumentace GitHubu: Chyba – Oprávnění odepřeno (veřejný klíč)
• Dokumentace GitHubu: Kontrola existujících SSH klíčů
• Dokumentace GitHubu: Generování nového SSH klíče a jeho přidání do ssh-agent
• Dokumentace GitHubu: Přidání nového SSH klíče k vašemu účtu GitHub
• Dokumentace GitHubu: Testování SSH připojení
• Dokumentace GitHubu: Použití SSH přes port HTTPS