Kratak odgovor
Greška permission denied publickey znači da server nije prihvatio vaš javni ključ, iako je lozinka možda ispravna. Najčešći krivci su pogrešan ključ na klijentu, pogrešne dozvole na ~/.ssh i authorized_keys ili podešavanje u sshd_config. Proverite ih redom i pristup se vraća bez reinstalacije.
Kako se problem prepoznaje
- Prijava preko SSH-a pada sa porukom Permission denied (publickey)
- Lozinka se ne traži ili je server odmah odbija
- Isti ključ je radio juče, danas više ne
- Prijava radi sa jednog računara, a sa drugog ne
- Nakon promene korisnika ili reinstalacije servera ključ se odbija
Najčešći uzroci
Pogrešan ili nepostojeći privatni ključ
SSH klijent pokušava da se prijavi ključem koji server ne poznaje ili ključ nije učitan u agenta. Proverite koji ključ se zaista nudi serveru.
Pogrešne dozvole na .ssh i authorized_keys
Ako home direktorijum, ~/.ssh ili authorized_keys imaju preširoke dozvole, sshd ih odbija iz bezbednosnih razloga. To je najčešći uzrok nakon ručnog kopiranja fajlova.
Ključ nije u authorized_keys za tog korisnika
Ključ je dodat pogrešnom nalogu, na primer root umesto deploy, ili je fajl prepisan umesto dopisan. Server tada nema šta da uporedi.
sshd_config ne dozvoljava prijavu ključem
Opcije poput PubkeyAuthentication, AuthorizedKeysFile ili AllowUsers mogu isključiti ključ ili korisnika. Posle izmene konfiguracije servis mora da se učita ponovo.
SELinux ili home direktorijum sa pogrešnim kontekstom
Na sistemima sa SELinuxom fajl može imati pogrešan bezbednosni kontekst iako su dozvole ispravne. Restorecon obično rešava problem.
Rešenje korak po korak
- 1
Pročitajte tačnu poruku i korisnika
Pokrenite prijavu sa
-vda vidite detalje:ssh -v korisnik@server. U izlazu tražite koje ključeve klijent nudi i da li server odbija sve. Proverite i da li ste na pravom korisniku i portu, jer se greška često javlja samo za jedan nalog. - 2
Proverite koji ključ klijent koristi
Na klijentu pokrenite
ssh-add -lda vidite ključeve u agentu. Ako je potreban drugi ključ, navedite ga eksplicitno:ssh -i ~/.ssh/id_ed25519 korisnik@server. U~/.ssh/configmožete za host dodatiIdentityFileiIdentitiesOnly yesda klijent ne nudi pogrešne ključeve. - 3
Uporedite otisak ključa sa serverom
Na klijentu izračunajte otisak:
ssh-keygen -lf ~/.ssh/id_ed25519.pub. Na serveru, ako imate drugi pristup, proveritessh-keygen -lf ~/.ssh/authorized_keys. Otisci moraju da se poklope; ako ne, ključ nije dodat ili je dodat pogrešnom korisniku. - 4
Ispravite dozvole na serveru
Prijavite se preko konzole ili drugog naloga i pokrenite (zamenite
korisnikstvarnim imenom, a/home/korisnikstvarnom putanjom do home direktorijuma; ako niste root, dodajtesudo):chmod 700 /home/korisnik/.ssh,chmod 600 /home/korisnik/.ssh/authorized_keys,chmod go-w /home/korisnikichown -R korisnik:korisnik /home/korisnik/.ssh. Vlasnik.sshiauthorized_keystreba da bude taj korisnik. Ako niste sigurni u postojeće dozvole, prvo ih zabeležite sastat -c '%a %U:%G' /home/korisnik /home/korisnik/.ssh /home/korisnik/.ssh/authorized_keys. Ovo rešava većinu slučajeva nakon ručnog kopiranja. - 5
Dodajte javni ključ na pravo mesto
Sadržaj fajla
id_ed25519.pubdodajte u/home/korisnik/.ssh/authorized_keystog korisnika, u novi red, bez brisanja postojećih. Ako koristitessh-copy-id, proverite da li je ciljani korisnik tačan. Posle izmene ponovo proverite dozvole iz prethodnog koraka. - 6
Proverite sshd_config
U
/etc/ssh/sshd_config(ili fajlu usshd_config.d) proveritePubkeyAuthentication yes,AuthorizedKeysFile .ssh/authorized_keysi da vas ne blokiraAllowUsersiliDenyUsers. Pre izmene napravite kopiju fajla. Posle izmene uraditesudo sshd -tza proveru sintakse. - 7
Ponovo učitajte SSH servis
Ako je konfiguracija ispravna, primenite je sa
sudo systemctl reload sshd(na Debian/Ubuntu:sudo systemctl reload ssh). Reload je bezbedniji od restarta jer ne prekida postojeće sesije. Zatim probajte prijavu iz novog terminala, ne zatvarajući stari. - 8
Rešite SELinux kontekst ako je uključen
Na sistemima sa SELinuxom pokrenite
sudo restorecon -Rv /home/korisnik/.ssh. Provera statusa jegetenforce. Ako je problem i dalje tu, u logu/var/log/secureili/var/log/auth.logtražite poruke o odbijanju ključa. Ne isključujte SELinux trajno.
Ako ništa ne pomogne: pristup preko konzole i rezervni nalog
Kada ključ ne prolazi ni posle svih provera, koristite konzolu provajdera ili KVM pristup serveru i prijavite se lozinkom ili preko recovery moda. Tada iz /var/log/auth.log ili /var/log/secure pročitajte tačan razlog odbijanja, jer sshd tamo ispiše da li je problem dozvola, vlasnika ili konfiguracije. Dobra praksa je da uvek imate drugi administratorski nalog sa ključem i da PasswordAuthentication ne isključujete dok ne potvrdite da ključ radi. Ako je server u oblaku, proverite i da li je javni ključ vezan za instancu u kontrolnoj tabli provajdera, jer se pri rekreiranju instance ponekad izgubi.
Kako da sprečite da se ponovi
- Držite rezervni administratorski nalog sa važećim ključem
- Posle svake izmene sshd_config proverite sintaksu sa `sudo sshd -t` pre reload-a
- Koristite `ssh-copy-id` i ne kopirajte fajlove ručno bez podešavanja dozvola
- Povremeno proverite da se ključ u agentu poklapa sa onim na serveru
Kada je bolje pozvati stručnjaka
Ako nemate konzolu, rezervni nalog ni važeći ključ, a server je produkcioni, bolje je da se javite IT podršci nego da eksperimentišete sa sshd_config i rizikujete potpuni gubitak pristupa.
Održavanje IT infrastrukture · Serveri, mreže, backup, bezbednost i helpdeskČesta pitanja
Da li je greška publickey povezana sa lozinkom?
Ne. Poruka Permission denied (publickey) znači da je server odbio ključ, a ne lozinku. Lozinka se uopšte ne proverava ako je prijava ključem jedini dozvoljen metod.
Zašto ključ radi za root, a ne za običnog korisnika?
Zato što se authorized_keys čita iz home direktorijuma prijavljenog korisnika. Ključ dodat u rootov home direktorijum ne važi za drugi nalog, a dozvole i vlasništvo se proveravaju posebno za svakog korisnika.
Mogu li da vratim prijavu lozinkom dok ne rešim ključ?
Možete, ako imate pristup konzoli i ako je lozinka postavljena. Privremeno uključite `PasswordAuthentication yes` u sshd_config, uradite reload i odmah posle rešavanja ključa vratite tu opciju na `no`. To je bezbednosno rizično, pa koristite jaku lozinku i po mogućstvu ograničite pristup firewall-om.