SSH Permission Denied (publickey) Hatası Nasıl Çözülür?

Permission denied (publickey), sunucunun bu kullanıcı için yalnız anahtarla girişe izin verdiğini ve gönderdiğiniz anahtarların hiçbirini kabul etmediğini söyler. Parantezde password da görünüyorsa parolayla giriş açıktır ama o da başarısız olmuştur. Çözüm iki taraflıdır. İstemcide doğru kullanıcıyla, doğru anahtarı ve sunucunun kabul ettiği imza algoritmasını kullanıp kullanmadığınızı ssh -v ile görün. Sunucuda ~/.ssh klasörünün 700, authorized_keys dosyasının 600 olduğunu, ev dizininin başkalarına yazılabilir olmadığını ve sshd_config.d altındaki ayarları kontrol edin. Sunucu günlüğü reddin nedenini çoğu zaman tek satırda yazar.

Parantezin içi ne anlatıyor?

Hata satırı kullanici@203.0.113.10: Permission denied (publickey). biçimindedir. Parantezdeki liste, sunucunun o noktada hâlâ kabul ettiği kimlik doğrulama yöntemleridir. Bu liste, sorunun hangi tarafta aranacağını büyük ölçüde daraltır.

Parola yazdıktan sonra gelen Permission denied, please try again. ise başka bir durumdur: parola yöntemi açıktır ama girilen parola, kullanıcı ya da kullanıcı için konmuş kısıt uymamıştır.

ssh -v çıktısında neye bakılır?

Tahmin etmek yerine istemciye ne yaptığını anlattırın. Varsayımsal senaryo: kullanici hesabına anahtarla bağlanmaya çalışıyorsunuz ve reddediliyorsunuz.

ssh -v kullanici@203.0.113.10

debug1: Authenticating to 203.0.113.10:22 as 'kullanici'
debug1: Will attempt key: /home/ali/.ssh/id_ed25519 ED25519 SHA256:...
debug1: Authentications that can continue: publickey
debug1: Next authentication method: publickey
debug1: Offering public key: /home/ali/.ssh/id_ed25519 ED25519 SHA256:...
debug1: Authentications that can continue: publickey
debug1: No more authentication methods to try.
kullanici@203.0.113.10: Permission denied (publickey).

Satırları sırayla okuyun. as 'kullanici', sunucuya hangi kullanıcı adıyla gittiğinizi gösterir. Komutta kullanıcı yazmazsanız istemci kendi bilgisayarınızdaki kullanıcı adını kullanır. Bu ayrıntı kolayca gözden kaçar. Will attempt key satırları istemcinin denemeye aday gördüğü anahtarlardır. Beklediğiniz anahtar listede yoksa istemci onu hiç bilmiyordur.

Offering public key satırından hemen sonra yeniden Authentications that can continue geliyorsa sunucu o anahtarı reddetmiştir. Ya anahtar o kullanıcının authorized_keys dosyasında yoktur ya da sunucu dosyayı izin veya etiket sorunu yüzünden okumamıştır. Server accepts key satırı görünüyorsa anahtar kabul edilmiştir, sorun sonrasındadır: parolalı anahtarın açılamaması ya da imzanın gönderilememesi gibi.

Daha fazla ayrıntı için -vvv kullanabilirsiniz. OpenSSH 10.5 ve sonrası istemcilerde ssh -Z seçeneği, açık anahtar doğrulamasında denenecek anahtarları deneme sırasıyla listeler. Daha eski sürümlerde aynı bilgiyi Will attempt key satırlarından çıkarırsınız.

İstemci tarafında kontrol edilecekler

Doğru kullanıcıyla mı bağlanıyorsunuz?

Sağlayıcının ilettiği erişim bilgilerinde hangi kullanıcı yazıyorsa onunla başlayın. Hazır bulut imajlarında root yerine imaja özgü bir kullanıcı tanımlıdır ve ad imaja göre değişir. AWS belgesine göre AWS'deki Ubuntu imajlarında ubuntu, Amazon Linux'ta ec2-user, Debian imajlarında admin kullanılır. Başka bir sağlayıcıda aynı dağıtımın adı farklı olabilir, o yüzden ezberlemek yerine teslim bilgisine bakın.

Root ile anahtarsız giriş deniyorsanız da reddedilmeniz normaldir. OpenSSH'ın PermitRootLogin varsayılanı prohibit-password'dur: root anahtarla girebilir, parolayla giremez. RHEL 9 ailesinde kurulum sırasında "Allow root SSH login with password" seçeneği işaretlenmediyse bu varsayılan geçerli kalır. Red Hat'in belgesi, bu izni /etc/ssh/sshd_config.d/01-permitrootlogin.conf dosyasına yazarak açmayı gösteriyor.

Sunulan anahtar doğru anahtar mı?

Birden çok anahtarınız varsa istemciye hangisini kullanacağını açıkça söyleyin:

ssh -i ~/.ssh/proje_ed25519 -o IdentitiesOnly=yes kullanici@203.0.113.10

IdentitiesOnly=yes, istemcinin ajandaki (ssh-agent) bütün anahtarları sırayla denemesini engeller ve yalnız belirttiğiniz anahtarı kullandırır. Ajanda çok anahtar varsa sunucunun deneme sınırı (MaxAuthTries, varsayılan 6) doğru anahtara sıra gelmeden dolabilir. Ajanda hangi anahtarların durduğunu ssh-add -l gösterir.

Özel anahtarın sunucudaki açık anahtarla gerçekten eşleştiğinden emin olmak için parmak izlerini karşılaştırın:

# kendi bilgisayarınızda: özel anahtardan açık anahtarı üretip parmak izini alın
ssh-keygen -y -f ~/.ssh/proje_ed25519 > /tmp/kontrol.pub
ssh-keygen -lf /tmp/kontrol.pub

# sunucuda: authorized_keys içindeki her anahtarın parmak izi
ssh-keygen -lf /home/kullanici/.ssh/authorized_keys

İki listede aynı SHA256: değeri yoksa sunucuya yanlış anahtar eklenmiştir. PuTTY ile üretilmiş .ppk uzantılı bir anahtarı OpenSSH istemcisi okuyamaz. Böyle bir dosyayı PuTTYgen ile OpenSSH biçimine dönüştürmeniz gerekir.

Eski RSA ve DSA anahtarları

OpenSSH 8.8 (26 Eylül 2021), SHA-1 özetli RSA imzalarını (ssh-rsa) varsayılan olarak kapattı. RSA anahtarları kullanılmaya devam eder ama imza rsa-sha2-256 ya da rsa-sha2-512 ile atılır. Sorun, bu algoritmaları bilmeyen eski bir sunucuya ya da cihaza yeni bir istemciyle bağlanırken çıkar. -v çıktısında send_pubkey_test: no mutual signature algorithm satırını görürsünüz. Sürüm notları, gerekiyorsa eski algoritmanın yalnız o sunucu için seçici olarak açılmasını öneriyor:

Host eski-sunucu
    HostName 203.0.113.20
    HostkeyAlgorithms +ssh-rsa
    PubkeyAcceptedAlgorithms +ssh-rsa

Bu blok kendi bilgisayarınızdaki ~/.ssh/config dosyasına girer ve geçici bir köprüdür. Kalıcı çözüm, sunucuyu güncellemek ve ssh-keygen -t ed25519 ile yeni bir anahtara geçmektir. PubkeyAcceptedAlgorithms adı OpenSSH 8.5'te geldi, daha eski istemcilerde aynı ayar PubkeyAcceptedKeyTypes adını taşır. DSA anahtarlarında köprü de yok: OpenSSH 10.0 (9 Nisan 2025) DSA desteğini tamamen kaldırdı. id_dsa ile giriş yapıyorsanız yeni bir anahtar üretmekten başka yol kalmadı.

Anahtar dosyasının izinleri

OpenSSH istemcisi, başkalarının okuyabildiği bir özel anahtarı kullanmayı reddeder ve ekrana WARNING: UNPROTECTED PRIVATE KEY FILE! uyarısını, ardından This private key will be ignored. satırını basar. Linux ve macOS'ta çözüm tek komuttur:

chmod 600 ~/.ssh/proje_ed25519

Windows'ta aynı denetim dosyanın erişim listesine (ACL) bakar. İndirilenler klasöründen ya da bir paylaşımdan kopyalanan anahtar, üst klasörün izinlerini devralır ve başka kullanıcılara da açık kalır. Komut isteminde devralınan izinleri kaldırıp yalnız kendinize okuma hakkı verin:

icacls %USERPROFILE%\.ssh\proje_ed25519 /inheritance:r
icacls %USERPROFILE%\.ssh\proje_ed25519 /grant:r "%USERNAME%:R"

/inheritance:r devralınan girdileri siler, /grant:r ise kullanıcıya verilmiş açık izinleri verdiğiniz izinle değiştirir.

Sunucu tarafında kontrol edilecekler

Bu adımlar için sunucuya bir şekilde girmeniz gerekir: hâlâ çalışan başka bir oturum, parolayla giriş, panelin web terminali ya da sağlayıcınız sunuyorsa sanal konsol.

Ev dizini, .ssh ve authorized_keys izinleri

sshd'nin StrictModes ayarı varsayılan olarak açıktır ve girişi kabul etmeden önce kullanıcının dosyalarının ve ev dizininin izinlerini ve sahipliğini denetler. man sayfasına göre authorized_keys, ~/.ssh klasörü ya da ev dizini başka kullanıcılara yazılabilir durumdaysa dosya kullanılmaz. Önce yolun her basamağına bakın:

namei -l /home/kullanici/.ssh/authorized_keys

Çıktı, yolun her parçasının sahibini ve izinlerini alt alta gösterir. Ardından olması gereken hâle getirin:

chmod go-w /home/kullanici
chmod 700 /home/kullanici/.ssh
chmod 600 /home/kullanici/.ssh/authorized_keys
chown -R kullanici: /home/kullanici/.ssh

chown komutundaki kullanıcı adından sonra gelen iki nokta, grubu o kullanıcının giriş grubuna ayarlar. Root olarak mkdir ya da cp ile oluşturulan klasörler root'a ait kalır, bu da gözden kaçması kolay bir nedendir. Anahtar dosyada tek satır olmalı. Kopyala-yapıştır sırasında ikiye bölünen bir satır anahtarı geçersiz kılar.

SELinux bağlamı (RHEL ailesi)

AlmaLinux, Rocky Linux ve RHEL'de izinler doğru olduğu hâlde anahtar reddediliyorsa SELinux etiketine bakın. Elle oluşturulan ya da başka bir yerden mv ile taşınan .ssh klasörü yanlış bağlamla kalabilir ve sshd dosyayı okuyamaz:

ls -Z /home/kullanici/.ssh/authorized_keys
restorecon -Rv /home/kullanici/.ssh

İlk komutun çıktısında ssh_home_t görmeniz beklenir. restorecon, klasördeki dosyaların etiketini politikada tanımlı varsayılana döndürür ve neyi değiştirdiğini yazar. Engellemeyi doğrulamak için ausearch -m avc -ts recent son on dakikadaki SELinux retlerini listeler.

sshd_config ve sshd_config.d

Ana dosya /etc/ssh/sshd_config'tir. Güncel dağıtımların çoğu bu dosyanın başında Include /etc/ssh/sshd_config.d/*.conf satırıyla bir klasörü de okur. Burada bilinmesi gereken kural şu: sshd her ayar için okuduğu ilk değeri kullanır. Klasördeki dosyalar ana dosyanın başında okunduğu için ana dosyada sonradan yazdığınız satırı geçersiz kılar. Klasör içinde de alfabetik olarak önce gelen dosya kazanır. Ubuntu'nun resmî bulut imajlarında /etc/ssh/sshd_config.d/60-cloudimg-settings.conf dosyasının PasswordAuthentication no içerdiği, Canonical'ın cloud-images hata kaydında (LP #2049860) geçiyor. Ana dosyada parolayı açmanızın işe yaramamasının nedeni bu tür bir dosya olabilir.

Dosyaları tek tek okumak yerine sshd'ye etkin yapılandırmayı sorun:

sshd -T | grep -i -E 'permitrootlogin|passwordauthentication|pubkeyauthentication|authorizedkeysfile|allowusers|allowgroups|denyusers|strictmodes'

-T yapılandırmayı denetler ve etkin değerleri yazar. Match blokları bağlantıya göre değiştiği için belirli bir bağlantıyı da canlandırabilirsiniz:

sshd -T -C user=kullanici,host=ornek.com.tr,addr=203.0.113.5 \
  | grep -i -E 'passwordauthentication|authorizedkeysfile|permitrootlogin'

Bakılacak ayarlar şunlar. PubkeyAuthentication anahtarla girişin açık olup olmadığını söyler. AuthorizedKeysFile varsayılan olarak .ssh/authorized_keys .ssh/authorized_keys2'dir. Biri bunu /etc/ssh/authorized_keys/%u gibi merkezi bir yola çevirdiyse ev dizinine eklediğiniz anahtar hiç okunmaz. AllowUsers ya da AllowGroups tanımlıysa listede olmayan kullanıcı, anahtarı doğru olsa bile giremez.

Match bloklarında sık yapılan bir hata var. Bir Match satırından sonraki ayarlar, bir sonraki Match satırına ya da dosyanın sonuna kadar o bloğa aittir. Dosyanın en sonunda bir Match bloğu varken altına eklediğiniz PasswordAuthentication yes satırı genel ayar olmaz, yalnız o bloğa uyan bağlantılara uygulanır.

Windows Server'daki OpenSSH

Windows'ta OpenSSH sunucusu çalıştırıyorsanız bir ayrıntı daha var. Microsoft belgesine göre Administrators grubundaki kullanıcılar için anahtar, kullanıcı profilindeki .ssh\authorized_keys dosyasından değil C:\ProgramData\ssh\administrators_authorized_keys dosyasından okunur. Bu dosyada yalnız SYSTEM ve Administrators için izin girdisi bulunmalıdır. Anahtarı profil klasörüne eklediğiniz yönetici hesabının reddedilmesi bu yüzdendir. Windows sunucularda uzak masaüstü erişimini de güvene almak isterseniz RDP erişimini kısıtlama ve NLA ayarlarını anlattığımız yazıya bakın.

Sunucu günlüğü reddin nedenini söyler

İstemci tarafı sadece "reddedildin" der. Nedeni sunucu yazar:

# Debian ve Ubuntu
journalctl -u ssh --since "10 min ago"
# RHEL, AlmaLinux, Rocky Linux
journalctl -u sshd --since "10 min ago"

rsyslog kullanan sistemlerde aynı satırlar Debian ve Ubuntu'da /var/log/auth.log, RHEL ailesinde /var/log/secure dosyasındadır. Sık karşılaşılan satırlar ve anlamları:

Satırlar yetmiyorsa ikinci bir sshd'yi hata ayıklama modunda başka bir portta açabilirsiniz: /usr/sbin/sshd -d -p 2222. Bu kip tek bağlantıyı işler, her adımı ekrana yazar ve bağlantı bitince kapanır. 2222 portunun güvenlik duvarında geçici olarak açık olması gerekir, iş bitince kapatmayı unutmayın.

Değişiklik yaparken kendinizi kilitlemeyin

SSH ayarını uzaktan değiştirmek, oturduğunuz dalı kesmeye benzer. Şu sırayı bozmayın:

1. Değiştirmeden önce yedek alın: cp -a /etc/ssh/sshd_config /etc/ssh/sshd_config.yedek-$(date +%F). sshd_config.d altındaki dosyaya dokunacaksanız onun da kopyasını alın.
2. Açık oturumunuzu kapatmayın. Bütün denemeleri ikinci bir terminalden yapın.
3. Kaydettikten sonra sshd -t çalıştırın. Komut yalnız yapılandırmanın geçerliliğini ve anahtarların sağlamlığını denetler, hata yoksa hiçbir şey yazmaz.
4. Servisi yeniden yükleyin: Debian ve Ubuntu'da systemctl reload ssh, RHEL ailesinde systemctl reload sshd. Yeniden yükleme açık oturumları düşürmez. Ubuntu 22.10'dan beri sshd systemd soket etkinleştirmesiyle çalışır, 24.04 sürüm notlarına göre de port ve adres ayarları sshd_config'ten soket birimine bir systemd üreteciyle aktarılır. Port ya da ListenAddress değiştirdiyseniz systemctl daemon-reload ve ardından systemctl restart ssh.socket çalıştırın.
5. Yeni terminalden bağlanmayı deneyin. Başarısızsa ilk terminalde yedeği geri kopyalayıp yeniden yükleyin.

Bütün oturumları kaybettiyseniz kurtarma yolu sağlayıcının sanal konsolu ya da destek ekibidir. Anahtar tabanlı girişe ilk geçişin güvenli sırasını VPS'e SSH ile bağlanma ve anahtara geçiş rehberinde, root girişini ve parolayı kapatma adımlarını Linux sunucuda ilk kurulum ve güvenlik yazısında anlattık. Sunucu yedekten geri yüklendiyse ~/.ssh içeriği yedeğin alındığı anki hâline döner ve sonradan eklenen anahtar orada olmayabilir. Erişim anahtarlarını yedekten geri yükleme tatbikatlarının kontrol listesine eklemek bu sürprizi önler.

Düzeldiğini nasıl doğrularsınız?

Yeni bir terminalden, istemciyi yalnız anahtar kullanmaya zorlayarak bağlanın:

ssh -v -o PreferredAuthentications=publickey -o PasswordAuthentication=no \
  -i ~/.ssh/proje_ed25519 kullanici@203.0.113.10

Çıktıda önce Server accepts key, ardından Authenticated to 203.0.113.10 ([203.0.113.10]:22) using "publickey". satırını görmelisiniz. Sunucu günlüğünde de Accepted publickey for kullanici from ... ile başlayan bir satır belirir. Teşhis sırasında parolalı girişi geçici olarak açtıysanız şimdi kapatın ve sshd -T | grep -i passwordauthentication ile etkin değerin yeniden no olduğunu kontrol edin. Bağlantı kuruluyor ama komutlar ağır yanıt veriyorsa sorun artık kimlik doğrulamada değildir. O durumda sunucu yükünü steal, iowait ve load average değerlerinden okumak gerekir.

Destek talebine neler yazılmalı?

Sunucuya hiçbir yoldan giremiyorsanız Netx müşteri panelinden destek talebi açın ve şunları ekleyin: sunucunun IP adresi, bağlanmaya çalıştığınız kullanıcı adı, denemenin saati ve kendi IP adresiniz, ssh -v çıktısı ve son yaptığınız yapılandırma değişikliği. Özel anahtarınızı ya da parolanızı hiçbir koşulda talebe eklemeyin. -v çıktısında yalnız açık anahtarın parmak izi görünür, paylaşmasında sakınca yoktur.

Netx VPS paketleri KVM tabanlıdır ve root erişimiyle gelir. Root erişimi sizde olduğu için SSH ayarlarını, kullanıcıları ve anahtarları kendiniz düzenleyebilirsiniz. Erişim düzenini ve değişiklik kaydını bir ekibe bırakmak isterseniz sunucu yönetimi hizmetinin kapsamını teklif aşamasında yazılı olarak netleştirebilirsiniz.