Kısa cevap
Permission denied publickey hatası, parola doğru olsa bile sunucunun genel anahtarınızı kabul etmediği anlamına gelir. En yaygın nedenler istemcide yanlış anahtar, ~/.ssh ve authorized_keys üzerinde yanlış izinler veya sshd_config ayarıdır. Sırayla kontrol edin, yeniden kurulum yapmadan erişim geri gelir.
Sorun nasıl anlaşılır
- SSH ile giriş Permission denied (publickey) mesajıyla başarısız oluyor
- Parola sorulmuyor veya sunucu hemen reddediyor
- Aynı anahtar dün çalışıyordu, bugün çalışmıyor
- Bir bilgisayardan giriş çalışıyor, diğerinden çalışmıyor
- Kullanıcı değişikliği veya sunucu yeniden kurulumundan sonra anahtar reddediliyor
En yaygın nedenler
Yanlış veya eksik özel anahtar
SSH istemcisi sunucunun tanımadığı bir anahtarla giriş yapmaya çalışıyor veya anahtar agent'a yüklenmemiş. Sunucuya gerçekte hangi anahtarın sunulduğunu kontrol edin.
.ssh ve authorized_keys üzerinde yanlış izinler
Home dizini, ~/.ssh veya authorized_keys çok geniş izinlere sahipse sshd güvenlik nedeniyle bunları reddeder. Dosyaları elle kopyaladıktan sonra en sık görülen nedendir.
Anahtar o kullanıcının authorized_keys dosyasında değil
Anahtar yanlış hesaba eklenmiş, örneğin deploy yerine root'a, veya dosya eklenmek yerine üzerine yazılmış. Sunucunun karşılaştıracak bir şeyi kalmaz.
sshd_config anahtarla girişe izin vermiyor
PubkeyAuthentication, AuthorizedKeysFile veya AllowUsers gibi seçenekler anahtarı veya kullanıcıyı devre dışı bırakabilir. Yapılandırma değiştirildikten sonra servisin yeniden yüklenmesi gerekir.
SELinux veya yanlış bağlamlı home dizini
SELinux etkin sistemlerde izinler doğru olsa bile dosya yanlış güvenlik bağlamına sahip olabilir. Restorecon genellikle sorunu çözer.
Adım adım çözüm
- 1
Tam mesajı ve kullanıcıyı okuyun
Ayrıntıları görmek için girişi
-vile çalıştırın:ssh -v kullanici@sunucu. Çıktıda istemcinin hangi anahtarları sunduğunu ve sunucunun hepsini reddedip etmediğini arayın. Doğru kullanıcıda ve portta olduğunuzu da kontrol edin, çünkü hata genellikle yalnızca bir hesap için görülür. - 2
İstemcinin hangi anahtarı kullandığını kontrol edin
İstemcide
ssh-add -lçalıştırarak agent'taki anahtarları görün. Başka bir anahtar gerekiyorsa açıkça belirtin:ssh -i ~/.ssh/id_ed25519 kullanici@sunucu.~/.ssh/configdosyasında host içinIdentityFileveIdentitiesOnly yesekleyerek istemcinin yanlış anahtarlar sunmasını engelleyebilirsiniz. - 3
Anahtar parmak izini sunucuyla karşılaştırın
İstemcide parmak izini hesaplayın:
ssh-keygen -lf ~/.ssh/id_ed25519.pub. Sunucuda başka bir erişiminiz varsassh-keygen -lf ~/.ssh/authorized_keysile kontrol edin. Parmak izleri eşleşmelidir; eşleşmiyorsa anahtar eklenmemiş veya yanlış kullanıcıya eklenmiştir. - 4
Sunucudaki izinleri düzeltin
Konsol veya başka bir hesapla giriş yapın ve çalıştırın (
kullaniciyerine gerçek adı,/home/kullaniciyerine gerçek home dizini yolunu koyun; root değilsenizsudoekleyin):chmod 700 /home/kullanici/.ssh,chmod 600 /home/kullanici/.ssh/authorized_keys,chmod go-w /home/kullanicivechown -R kullanici:kullanici /home/kullanici/.ssh..sshveauthorized_keyssahibi o kullanıcı olmalıdır. Mevcut izinlerden emin değilseniz öncestat -c '%a %U:%G' /home/kullanici /home/kullanici/.ssh /home/kullanici/.ssh/authorized_keysile kaydedin. Bu, elle kopyalamadan sonraki çoğu durumu çözer. - 5
Genel anahtarı doğru yere ekleyin
id_ed25519.pubdosyasının içeriğini o kullanıcının/home/kullanici/.ssh/authorized_keysdosyasına, mevcutları silmeden yeni bir satır olarak ekleyin.ssh-copy-idkullanıyorsanız hedef kullanıcının doğru olduğunu kontrol edin. Değişiklikten sonra önceki adımdaki izinleri yeniden kontrol edin. - 6
sshd_config dosyasını kontrol edin
/etc/ssh/sshd_config(veyasshd_config.diçindeki bir dosya) içindePubkeyAuthentication yes,AuthorizedKeysFile .ssh/authorized_keysolduğunu veAllowUsersveyaDenyUserstarafından engellenmediğinizi kontrol edin. Değişiklikten önce dosyanın yedeğini alın. Değişiklikten sonra sözdizimi kontrolü içinsudo sshd -tçalıştırın. - 7
SSH servisini yeniden yükleyin
Yapılandırma doğruysa
sudo systemctl reload sshd(Debian/Ubuntu'da:sudo systemctl reload ssh) ile uygulayın. Reload, mevcut oturumları kesmediği için restart'tan daha güvenlidir. Ardından eski terminali kapatmadan yeni bir terminalden giriş deneyin. - 8
SELinux etkinse bağlamı düzeltin
SELinux etkin sistemlerde
sudo restorecon -Rv /home/kullanici/.sshçalıştırın. Durum kontrolügetenforceile yapılır. Sorun devam ederse/var/log/secureveya/var/log/auth.loggünlüğünde anahtar reddi mesajlarını arayın. SELinux'u kalıcı olarak kapatmayın.
Hiçbir şey işe yaramazsa: konsol ve yedek hesap üzerinden erişim
Tüm kontrollerden sonra anahtar hala geçmiyorsa sağlayıcının konsolunu veya sunucuya KVM erişimini kullanın ve parola ya da kurtarma modu ile giriş yapın. Ardından /var/log/auth.log veya /var/log/secure dosyasından reddin tam nedenini okuyun, çünkü sshd orada sorunun izin, sahiplik veya yapılandırma kaynaklı olup olmadığını yazar. İyi bir uygulama, her zaman anahtarlı ikinci bir yönetici hesabınız olması ve anahtarın çalıştığını doğrulamadan PasswordAuthentication seçeneğini kapatmamanızdır. Sunucu buluttaysa, sağlayıcının kontrol panelinde genel anahtarın örneğe bağlı olup olmadığını da kontrol edin, çünkü örnek yeniden oluşturulduğunda bazen kaybolur.
Tekrarlanmaması için
- Geçerli anahtara sahip yedek bir yönetici hesabı bulundurun
- Her sshd_config değişikliğinden sonra reload öncesi `sudo sshd -t` ile sözdizimini kontrol edin
- `ssh-copy-id` kullanın ve izinleri ayarlamadan dosyaları elle kopyalamayın
- Ara sıra agent'taki anahtarın sunucudakiyle eşleştiğini kontrol edin
Ne zaman uzmana başvurmalı
Konsolunuz, yedek hesabınız veya geçerli anahtarınız yoksa ve sunucu üretim ortamındaysa, sshd_config ile denemeler yapıp tamamen erişim kaybı riskini almak yerine BT desteğine başvurmanız daha iyidir.
BT altyapı bakımı · Sunucular, ağlar, yedekleme, güvenlik ve yardım masasıSık sorulan sorular
Publickey hatası parolayla ilgili mi?
Hayır. Permission denied (publickey) mesajı sunucunun anahtarı reddettiği anlamına gelir, parolayı değil. Anahtarla giriş tek izin verilen yöntemse parola hiç kontrol edilmez.
Anahtar root için çalışıyor ama normal kullanıcı için çalışmıyor, neden?
Çünkü authorized_keys, giriş yapan kullanıcının home dizininden okunur. Root'un home dizinine eklenen anahtar başka bir hesap için geçerli değildir ve izinler ile sahiplik her kullanıcı için ayrı kontrol edilir.
Anahtarı çözene kadar parolayla girişi geri açabilir miyim?
Konsol erişiminiz varsa ve parola ayarlıysa açabilirsiniz. sshd_config içinde geçici olarak `PasswordAuthentication yes` etkinleştirin, reload yapın ve anahtar sorununu çözdükten hemen sonra bu seçeneği `no` olarak geri alın. Bu güvenlik açısından risklidir, bu nedenle güçlü bir parola kullanın ve mümkünse erişimi güvenlik duvarıyla sınırlayın.