GitHubs nåværende SSH-feilsøkingsdokumentasjon, sjekket 13. september 2026, behandler fortsatt Permission denied (publickey)som en autentiseringsfeil: GitHub avviste SSH-tilkoblingen fordi den ikke godtok en brukbar offentlig nøkkel for kontoen og tilkoblingen du presenterte. Den raskeste måten å fikse dette på er å bekrefte tilkoblingen i en bestemt rekkefølge i stedet for å umiddelbart slette nøkler eller generere nye. GitHubs offisielle feilsøkingsside for tilgang nektet (offentlig nøkkel) anbefaler å sjekke serveren, SSH-brukeren, nøkkelen som tilbys, og om den samsvarende offentlige nøkkelen er knyttet til kontoen din.
En god reparasjon har to observerbare utfall. For det første ssh -T git@github.comidentifiserer den GitHub-kontoen du hadde tenkt å bruke og rapporterer vellykket autentisering. For det andre fungerer den faktiske repository-kommandoen – for eksempel git fetch, git pull, git pusheller git clone– med repositoryen du er autorisert til å få tilgang til. Å bestå kun den første testen beviser SSH-autentisering, ikke repository-tillatelse.
| Sjekke | Sunt resultat | Hvis det mislykkes |
|---|---|---|
| Ekstern URL | Bruksområdergit@github.com:OWNER/REPOSITORY.git | Rett verten eller SSH-brukeren før du endrer nøkler |
| Lokale nøkkelfiler | Det finnes et støttet offentlig/privat nøkkelpar | Generer et nytt nøkkelpar bare hvis du ikke har et du har tenkt å bruke |
| SSH-agent | ssh-add -l -E sha256lister opp den tiltenkte nøkkelen | Start agenten og legg til den private nøkkelen |
| GitHub-konto | Den samsvarende offentlige nøkkelen vises under SSH- og GPG-nøkler | Legg til den offentlige nøkkelen til riktig konto; autoriser den for SSO når det er nødvendig |
| Autentiseringstest | GitHub hilser på det forventede brukernavnet | Bruk detaljert SSH-utdata for å se hvilken nøkkel som faktisk tilbys |
| Repository-operasjon | Henting, trekk, push eller kloning lykkes | Sjekk tilgang til repositorium, kontoidentitet, SSO, ekstern URL eller nettverksbegrensninger |
Før du berører tastene, bekreft at du kobler til GitHub.com og at SSH-brukernavnet bokstavelig talt er git. GitHub dokumenterer at SSH-tilkoblinger til GitHub.com må bruke gitbrukeren, ikke ditt personlige GitHub-brukernavn. En kommando som ssh -T yourname@github.comforventes å mislykkes.
git remote -v
ssh -vT git@github.comFor en vanlig GitHub.com SSH-fjernkontroll, bør URL-en se slik ut:
git@github.com:OWNER/REPOSITORY.gitHvis fjernkontrollen er feil, korriger den med Gits fjernkonfigurasjon i stedet for å generere legitimasjon på nytt:
git remote set-url origin git@github.com:OWNER/REPOSITORY.gitUnngå også å kjøre vanlige Git-kommandoer med sudoeller med forhøyede rettigheter. GitHub bemerker at dette kan føre til at Git kjører under et annet brukermiljø og derfor bruker andre SSH-nøkler enn de du konfigurerte. Målet på dette stadiet er enkelt: detaljert utdata skal vise et tilkoblingsforsøk på github.comport 22, med mindre du med vilje konfigurerte HTTPS-portløsningen som beskrives senere.
Sjekk din lokale SSH-katalog før du oppretter noe nytt. GitHubs nåværende veiledning anbefaler at du først ser etter et eksisterende støttet nøkkelpar.
ls -al ~/.ssh
Vanlige standardfilnavn for offentlige nøkler inkluderer id_ed25519.pub, id_ecdsa.pubog id_rsa.pub. GitHub støtter ikke lenger DSA-nøkler. Hvis du allerede har et nøkkelpar du har tenkt å bruke for GitHub, behold det og fortsett med agentsjekken.
ssh-add -l -E sha256Et sunt resultat viser ett eller flere fingeravtrykk. Hvis den tiltenkte nøkkelen ikke lastes inn, start SSH-agenten som passer for miljøet ditt og legg til den private nøkkelen:
eval "$(ssh-agent -s)"
ssh-add ~/.ssh/id_ed25519
På Windows avhenger den nøyaktige agent-start-kommandoen av om du bruker Git Bash, Windows OpenSSH, PowerShell eller et annet miljø. GitHubs offisielle veiledning for nøkkelgenerering og ssh-agent gir plattformspesifikke instruksjoner. Følg delen for SSH-klienten du faktisk bruker; å blande Git for Windows' SSH med Windows OpenSSH er en vanlig kilde til forvirring.
Generer bare en når den tidligere sjekken viser at du ikke har en passende nøkkel du vil bruke. GitHubs nåværende instruksjoner anbefaler Ed25519 for en standard programvarenøkkel når den støttes:
ssh-keygen -t ed25519 -C "your_email@example.com"Bruk en passordfrase hvis det passer sikkerhetskravene dine. SSH-agenten kan mellomlagre den ulåste private nøkkelen for økten din. Last aldri opp eller lim inn selve den private nøkkelfilen i GitHub; filen som slutter på .puber den offentlige nøkkelen som er ment for kontoregistrering.
Det er ikke nok å ha en lokal nøkkel. GitHub må ha den samsvarende offentlige nøkkelen knyttet til kontoen som skal autentiseres. Vis den offentlige nøkkelen, og kopier deretter hele linjen:
cat ~/.ssh/id_ed25519.pubI GitHub åpner du Innstillinger , deretter SSH- og GPG-nøkler , velger Ny SSH-nøkkel eller Legg til SSH-nøkkel , velger en autentiseringsnøkkel og limer inn den offentlige nøkkelen. Disse etikettene samsvarer med GitHubs nåværende offisielle dokumentasjon for å legge til en SSH-nøkkel .
Sammenlign fingeravtrykk når du er usikker på hvilken lokal nøkkel som samsvarer med oppføringen på GitHub:
ssh-add -l -E sha256Hvis depotet tilhører en organisasjon som bruker SAML-enkeltpålogging, er det kanskje ikke nok å legge til nøkkelen i kontoen din. GitHub dokumenterer at en SSH-nøkkel også kan kreve organisasjonsautorisasjon. I Innstillinger > SSH- og GPG-nøkler bruker du Konfigurer SSO for nøkkelen og autoriserer den relevante organisasjonen når den kontrollen er tilgjengelig. Se GitHubs veiledning for SSH-nøkkel SSO-autorisasjon .
Ikke bruk git pushsom din eneste test. Test SSH direkte:
ssh -T git@github.com
Vellykketmeldingen skal hilse GitHub-brukernavnet ditt og forklare at GitHub ikke gir skalltilgang. GitHub bemerker også at denne testen kan avsluttes med statuskode 1 selv når autentiseringen lykkes, så bedøm den ut fra autentiseringsmeldingen i stedet for å forvente et normalt interaktivt skall.
Hvis testen fortsatt slutter på Permission denied (publickey), kjør verbose-modus:
ssh -vT git@github.comSe etter linjer som Offering public key. Hvis loggen aldri tilbyr nøkkelen du forventet, er problemet valg av lokal nøkkel eller agentkonfigurasjon. Hvis den tiltenkte nøkkelen blir tilbudt, men avvist, sjekk om den offentlige nøkkelen er knyttet til riktig GitHub-konto og om SSO-autorisasjon kreves.
Hvis du bruker jobb- og personlige kontoer på samme datamaskin, kan vellykket SSH-autentisering fortsatt havne på feil konto. GitHub-dokumenter bruker IdentitiesOnly=yeseller en spesifikk identitetsfil for å kontrollere hvilken nøkkel SSH tilbyr. For en engangsdiagnose:
ssh -v -o "IdentitiesOnly=yes" -i ~/.ssh/work_ed25519 git@github.comHvis GitHub mottar feil brukernavn, har du funnet feilen. Konfigurer separate nøkler eller vertsaliaser i stedet for å gjentatte ganger slette og legge til nøkler på nytt. GitHubs offisielle veiledning for flere kontoer dekker dette tilfellet mer detaljert.
Når ssh -T git@github.comdu har autentisert deg som forventet bruker, prøv den faktiske depotoperasjonen på nytt:
git fetch origin
git pull
git push
Hvis SSH-autentisering lykkes, men Git nå rapporterer en depotspesifikk tillatelsesfeil, må du slutte å endre SSH-nøkkelen. På det tidspunktet har nøkkelen allerede gjort jobben sin. Bekreft at den autentiserte kontoen har tilgang til depotet, at eieren og depotnavnet i den eksterne URL-en er riktige, og at en organisasjon har gitt den nødvendige rollen. GitHubs separate feilsøkingsside for depottillatelser forklarer tilfellet der nøkkelen tilhører en konto uten tilgang.
En brannmur eller proxy kan forhindre at et gyldig SSH-oppsett når GitHub på port 22. Test GitHubs dokumenterte SSH-over-HTTPS-endepunkt:
ssh -T -p 443 git@ssh.github.comVertsnavnet er ssh.github.com, ikke github.com, for denne direkte port-443-testen. Hvis det fungerer, dokumenterer GitHub denne SSH-konfigurasjonen:
Host github.com
Hostname ssh.github.com
Port 443
User gitTest deretter på nytt med ssh -T git@github.com. Se GitHubs veiledning for SSH over port 443 . Denne løsningen gjelder ikke for alle GitHub Enterprise-miljøer, og proxy-servere kan fortsatt forstyrre.
| Det du observerer | Hva det betyr | Neste trekk |
|---|---|---|
ssh-add -lviser ingen tiltenkt nøkkel | Klienten kan ikke tilby riktig privatnøkkel | Rett opp agent- eller nøkkelbanen |
Detaljert SSH vises aldri Offering public keyfor den tiltenkte nøkkelen | SSH-valget er feil | Bruk -i, IdentitiesOnly=yes, eller korriger~/.ssh/config |
| Den tiltenkte nøkkelen blir tilbudt, men avvist | GitHub godtar ikke den nøkkelen for den forsøkte identiteten | Sjekk den opplastede offentlige nøkkelen, målkontoen og SSO-autorisasjonen |
| SSH hilser feil GitHub-brukernavn | En annen kontos nøkkel brukes | Separate kontonøkler og eksplisitt velg den tiltenkte identiteten |
| SSH lykkes, men depotet avviser push eller henting | Autentisering fungerer; autorisasjon av repositorium eller URL er nå problemet | Sjekk tilgang til arkivet og eksternt eierskap |
| Port 22 kan ikke koble til i det hele tatt | Nettverket kan blokkere standard SSH | Test port 443 eller bruk HTTPS |
Genererer nøkkel etter nøkkel uten å sjekke hva SSH tilbyr. Flere nøkler kan gjøre valget vanskeligere. Bruk ssh -vTog ssh-add -l -E sha256først.
Bruk av GitHub-brukernavnet ditt før @github.com. GitHubs SSH-endepunkt forventer at SSH-brukeren git. GitHub-identiteten din bestemmes av den offentlige nøkkelen som GitHub gjenkjenner.
Laster opp den private nøkkelen. Ikke gjør dette. GitHub trenger den offentlige .pubverdien; den private nøkkelen forblir på maskinen din eller godkjent nøkkellagring.
Forutsatt at en vellykket SSH-test garanterer push-tilgang. Det beviser kontoautentisering. Autorisasjon av arkivet er en separat kontroll.
Ignorerer SSO. Organisasjonsressurser kan kreve en ekstra SSH-nøkkelautorisasjon selv om nøkkelen finnes i din personlige konto.
Bruk av forhøyede Git-kommandoer. Å kjøre Git som en annen OS-bruker kan endre hvilken hjemmekatalog, SSH-konfigurasjon, agent og nøkler som brukes.
SSH er ikke obligatorisk. GitHub støtter også HTTPS-fjernkontroller. Hvis et låst bedriftsnettverk, en administrert endepunktpolicy eller en proxy gjør SSH upraktisk, kan det være enklere å bytte den eksterne depottilkoblingen til HTTPS enn å kjempe mot nettverket. Det er en endring av autentiseringsmetoden, ikke en reparasjon av SSH-konfigurasjonen, så bruk den når miljøet ditt gjør SSH uønsket i stedet for som en måte å skjule en uløst nøkkelavvik.
For SSH er det mest pålitelige stoppestedet evidensbasert: den forventede nøkkelen lastes inn, GitHub gjenkjenner den som den forventede kontoen, organisasjonen autoriserer den når det er nødvendig, og den virkelige Git-operasjonen lykkes. Hvis en av disse kontrollene mislykkes, endrer du bare laget som mislyktes. Det holder feilsøkingsprosessen kontrollert og unngår å bytte ut fungerende nøkler unødvendig.
Fix Tailwind CSS styles not updating in Vite React by checking Tailwind v4 setup, CSS imports, source detection, dynamic classes, HMR, and stale caches.
Fiks Python 3s ModuleNotFoundError for pip på Windows, macOS og Linux med ensurepip, OS-pakker, virtuelle miljøer og tolkekontroller.
Fiks GitHub SSH-tillatelse nektet (offentlig nøkkel) ved å sjekke verten, aktiv SSH-nøkkel, GitHub-konto, SSO-autorisasjon, ekstern URL og port 22-tilgang.
Fix a Git non-fast-forward push safely. Protect local work, fetch remote commits, choose merge or rebase, resolve conflicts, and push without losing changes.
Rett Nginx 502 Bad Gateway-feil med en Node.js-oppstrøm ved å sjekke appporten, NGINX-logger, proxy_pass-adresse, containernettverk, tidsavbrudd og omlasting.
Rett TypeScripts feilmelding «Typen 'null' kan ikke tilordnes til type» med unionstyper, innsnevring, standardverdier og sikre påstander under strictNullChecks.
Fiks feilen med at Prisma Client ikke er generert ved å sjekke generatoren, skjemaet, utdatastien, importene, versjonene, monorepo-oppsettet og byggetrinnene ved distribusjon.
Fiks Node.js ERR_MODULE_NOT_FOUND i ESM ved å sjekke importstier, filtyper, pakkeinstallasjon, eksport, ESM-modus og rene installasjoner.
Løs Git-feilmeldingen 'unable to get local issuer certificate' ved å identifisere tillitsbakgrunnen, installere riktig CA-kjede og beholde SSL-verifisering aktivert.
Løs MongoDB nettverksavbrudd i Mongoose ved å identifisere avbruddstypen, teste Atlas- eller TCP-tilgjengelighet, korrigere URI-en, og justere tidsavbrudd kun når det er berettiget.
