Кратак одговор
Грешка permission дениед publickey значи да server није прихватио ваш јавни кључ, иако је лозинка можда исправна. Најчешћи кривци су погрешан кључ на клијенту, погрешне дозволе на ~/.ssh и аутхоризед_keys или подешавање у sshd_цонфиг. Проверите их редом и приступ се враћа без реинсталације.
Како се проблем препознаје
- Пријава преко SSH-a пада са поруком Permission дениед (publickey)
- Лозинка се не тражи или је server одмах одбија
- Исти кључ је радио јуче, данас више не
- Пријава ради са једног рачунара, а са другог не
- Након промене корисника или реинсталације сервера кључ се одбија
Најчешћи узроци
Погрешан или непостојећи приватни кључ
SSH клијент покушава да се пријави кључем који server не познаје или кључ није учитан у агента. Проверите који кључ се заиста нуди серверу.
Погрешне дозволе на .ssh и аутхоризед_keys
Ако хоме директоријум, ~/.ssh или аутхоризед_keys имају прешироке дозволе, sshd их одбија из безбедносних разлога. То је најчешћи узрок након ручног копирања фајлова.
Кључ није у аутхоризед_keys за тог корисника
Кључ је додат погрешном налогу, на пример root уместо deploy, или је фајл преписан уместо дописан. Server тада нема шта да упореди.
sshd_цонфиг не дозвољава пријаву кључем
Опције попут PubkeyAuthentication, AuthorizedKeysFile или AllowUsers могу искључити кључ или корисника. После измене конфигурације сервис мора да се учита поново.
SELinux или хоме директоријум са погрешним контекстом
На системима са SELinuxom фајл може имати погрешан безбедносни контекст иако су дозволе исправне. Ресторецон обично решава проблем.
Решење корак по корак
- 1
Прочитајте тачну поруку и корисника
Покрените пријаву са
-vда видите детаље:ssh -v korisnik@server. У излазу тражите које кључеве клијент нуди и да ли server одбија све. Проверите и да ли сте на правом кориснику и порту, јер се грешка често јавља само за један налог. - 2
Проверите који кључ клијент користи
На клијенту покрените
ssh-add -lда видите кључеве у агенту. Ако је потребан други кључ, наведите га експлицитно:ssh -i ~/.ssh/id_ed25519 korisnik@server. У~/.ssh/configможете за хост додатиIdentityFileиIdentitiesOnly yesда клијент не нуди погрешне кључеве. - 3
Упоредите отисак кључа са сервером
На клијенту израчунајте отисак:
ssh-keygen -lf ~/.ssh/id_ed25519.pub. На серверу, ако имате други приступ, проверитеssh-keygen -lf ~/.ssh/authorized_keys. Отисци морају да се поклопе; ако не, кључ није додат или је додат погрешном кориснику. - 4
Исправите дозволе на серверу
Пријавите се преко конзоле или другог налога и покрените (замените
korisnikстварним именом, а/home/korisnikстварном путањом до хоме директоријума; ако нисте root, додајтеsudo):chmod 700 /home/korisnik/.ssh,chmod 600 /home/korisnik/.ssh/authorized_keys,chmod go-w /home/korisnikиchown -R korisnik:korisnik /home/korisnik/.ssh. Власник.sshиauthorized_keysтреба да буде тај корисник. Ако нисте сигурни у постојеће дозволе, прво их забележите саstat -c '%a %U:%G' /home/korisnik /home/korisnik/.ssh /home/korisnik/.ssh/authorized_keys. Ово решава већину случајева након ручног копирања. - 5
Додајте јавни кључ на право место
Садржај фајла
id_ed25519.pubдодајте у/home/korisnik/.ssh/authorized_keysтог корисника, у нови ред, без брисања постојећих. Ако користитеssh-copy-id, проверите да ли је циљани корисник тачан. После измене поново проверите дозволе из претходног корака. - 6
Проверите sshd_цонфиг
У
/etc/ssh/sshd_config(или фајлу уsshd_config.d) проверитеPubkeyAuthentication yes,AuthorizedKeysFile .ssh/authorized_keysи да вас не блокираAllowUsersилиDenyUsers. Пре измене направите копију фајла. После измене урадитеsudo sshd -tза проверу синтаксе. - 7
Поново учитајте SSH сервис
Ако је конфигурација исправна, примените је са
sudo systemctl reload sshd(на Дебиан/Убунту:sudo systemctl reload ssh). Релоад је безбеднији од рестарта јер не прекида постојеће сесије. Затим пробајте пријаву из новог терминала, не затварајући стари. - 8
Решите SELinux контекст ако је укључен
На системима са SELinuxom покрените
sudo restorecon -Rv /home/korisnik/.ssh. Провера статуса јеgetenforce. Ако је проблем и даље ту, у логу/var/log/secureили/var/log/auth.logтражите поруке о одбијању кључа. Не искључујте SELinux трајно.
Ако ништа не помогне: приступ преко конзоле и резервни налог
Када кључ не пролази ни после свих провера, користите конзолу провајдера или KVM приступ серверу и пријавите се лозинком или преко recovery мода. Тада из /var/log/auth.log или /var/log/secure прочитајте тачан разлог одбијања, јер sshd тамо испише да ли је проблем дозвола, власника или конфигурације. Добра пракса је да увек имате други администраторски налог са кључем и да PasswordAuthentication не искључујете док не потврдите да кључ ради. Ако је server у облаку, проверите и да ли је јавни кључ везан за инстанцу у контролној табли провајдера, јер се при рекреирању инстанце понекад изгуби.
Како да спречите да се понови
- Држите резервни администраторски налог са важећим кључем
- После сваке измене sshd_цонфиг проверите синтаксу са `sudo sshd -t` пре релоад-а
- Користите `ssh-copy-id` и не копирајте фајлове ручно без подешавања дозвола
- Повремено проверите да се кључ у агенту поклапа са оним на серверу
Када је боље позвати стручњака
Ако немате конзолу, резервни налог ни важећи кључ, а server је продукциони, боље је да се јавите IT подршци него да експериментишете са sshd_цонфиг и ризикујете потпуни губитак приступа.
Одржавање IT инфраструктуре · Сервери, мреже, backup, безбедност и хелпдескЧеста питања
Да ли је грешка publickey повезана са лозинком?
Не. Порука Permission дениед (publickey) значи да је server одбио кључ, а не лозинку. Лозинка се уопште не проверава ако је пријава кључем једини дозвољен метод.
Зашто кључ ради за root, а не за обичног корисника?
Зато што се аутхоризед_keys чита из хоме директоријума пријављеног корисника. Кључ додат у rootov хоме директоријум не важи за други налог, а дозволе и власништво се проверавају посебно за сваког корисника.
Могу ли да вратим пријаву лозинком док не решим кључ?
Можете, ако имате приступ конзоли и ако је лозинка постављена. Привремено укључите `PasswordAuthentication yes` у sshd_цонфиг, урадите релоад и одмах после решавања кључа вратите ту опцију на `no`. То је безбедносно ризично, па користите јаку лозинку и по могућству ограничите приступ firewall-om.