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

Yeni bir VDS aldınız, panelden anahtarınızı eklediniz, terminale komutu yazdınız ve tek satır cevap aldınız: Permission denied (publickey). SSH permission denied publickey hatası, sunucunun sizi tanımadığını değil, sunduğunuz kimliklerin hiçbirini kabul etmediğini söyler. Parola sorulmadan doğrudan reddedilmeniz de bunun kanıtıdır: sunucu yalnızca anahtar tabanlı girişe izin veriyordur ve elinizdeki anahtar ya yanlış, ya yanlış kullanıcıya ait, ya da doğru yerde ama yanlış izinlerle duruyordur.

Bu hatanın can sıkıcı tarafı, sunucunun size neden reddettiğini söylememesidir. Bu kasıtlıdır; aksi hâlde saldırgan hangi kullanıcının var olduğunu deneme yanılmayla öğrenirdi. İyi haber şu ki sunucu susarken istemci konuşur: ssh -vvv çıktısı, hangi anahtarların denendiğini, sunucunun hangi yöntemleri kabul ettiğini ve nerede kesildiğini satır satır gösterir. Bu yazıda önce doğru kullanıcı adını (root mu, ubuntu mu, almalinux mi), sonra ~/.ssh dizininin 700 ve authorized_keys dosyasının 600 olması kuralının neden sessiz redde yol açtığını, ardından da verbose çıktıda tam olarak hangi satırların okunacağını ele alacağız.

Permission Denied (publickey) Tam Olarak Ne Demek#

Mesajın parantez içindeki kısmı, sunucunun denemenize izin verdiği yöntemleri listeler. Aradaki fark önemlidir:

Sadece (publickey) görüyorsanız PasswordAuthentication no ayarlıdır. Bu, çoğu modern sunucu görüntüsünün varsayılanıdır ve düzgün bir kurulumdur; parolayla girmeye çalışmanın anlamı yoktur.

Sürecin nasıl işlediğini bilmek teşhisi hızlandırır: istemci elindeki anahtarları sırayla sunar, sunucu her biri için ilgili kullanıcının ~/.ssh/authorized_keys dosyasında eşleşme arar, bulursa bir sınama gönderir ve istemci onu özel anahtarla imzalar. Bu zincirin herhangi bir halkasında kopma aynı tek satırlık hatayı üretir. Anahtar mimarisinin bütününe hâkim değilseniz ssh bağlantısı ve güvenliği yazısı iyi bir temel sağlar.

Önce Doğru Kullanıcı Adı: Dağıtıma Göre Değişir#

Yeni sunucu alan kullanıcıların en sık kaybettiği zaman burada. Bulut ve VDS görüntülerinin çoğu root ile doğrudan girişi kapatır ve anahtarınızı dağıtıma özel varsayılan bir kullanıcıya yerleştirir. Yanlış kullanıcı adıyla bağlanmaya çalışırsanız, anahtarınız kusursuz olsa bile aynı hatayı alırsınız — çünkü sunucu /root/.ssh/authorized_keys dosyasına bakıyordur ve anahtar /home/ubuntu/.ssh/authorized_keys içindedir.

Doğru olanı bulmanın en hızlı yolu sırayla denemektir. Yanlış kullanıcı adında sunucu hemen reddeder, bu yüzden deneme ucuzdur:

for k in root ubuntu debian almalinux rocky centos admin; do
  echo "--- $k ---"
  ssh -o BatchMode=yes -o ConnectTimeout=5 "[email protected]" 'id' 2>&1 | tail -1
done

Doğru kullanıcıda uid=1000(ubuntu) gid=1000(ubuntu) gibi bir çıktı görürsünüz. Yeni bir sunucuda ilk yapılacakların tam listesi için vds satın alma sonrası ilk adımlar yazısı ayrıca yardımcı olur.

Bir ipucu daha: bazı imajlar root ile bağlanmayı denediğinizde nazik bir uyarı basar. Şunu görüyorsanız kullanıcı adınız yanlış demektir ve doğrusu mesajın içindedir:

Please login as the user "almalinux" rather than the user "root".

ssh -vvv Çıktısında Hangi Satırları Okuyacaksınız#

Verbose çıktı uzundur ve insanların çoğu ona bakıp vazgeçer. Oysa işe yarayan satır sayısı beştir. Komutu çalıştırın:

ssh -vvv -o IdentitiesOnly=yes -i ~/.ssh/id_ed25519 [email protected]

1. Sunucunun kabul ettiği yöntemler. Şu satırı arayın:

debug1: Authentications that can continue: publickey,keyboard-interactive

Listede password yoksa parola denemek zaman kaybıdır.

2. Hangi anahtar dosyalarının denendiği.

debug1: Will attempt key: /home/kullanici/.ssh/id_ed25519 ED25519 SHA256:xY9... explicit
debug1: Will attempt key: /home/kullanici/.ssh/id_rsa RSA SHA256:aB3... agent

Beklediğiniz anahtar bu listede hiç yoksa sorun sunucuda değil, istemcide: yol yanlıştır ya da -i parametresi göz ardı edilmiştir.

3. Anahtarın sunucuya sunulması ve sonucu.

debug1: Offering public key: /home/kullanici/.ssh/id_ed25519 ED25519 SHA256:xY9...
debug1: Authentications that can continue: publickey

Offering public key satırından sonra yine Authentications that can continue geliyorsa, o anahtar sunucu tarafından reddedilmiştir — yani authorized_keys içinde yok ya da dosya okunamıyor. Buna karşılık:

debug1: Server accepts key: /home/kullanici/.ssh/id_ed25519 ED25519 SHA256:xY9...

satırını görüp yine de reddediliyorsanız, açık anahtar eşleşmiş ama imza doğrulanamamıştır: elinizdeki özel anahtar o açık anahtarın çifti değildir.

4. Çok fazla anahtar sunulması. Ajanınızda beş anahtar varsa istemci hepsini sırayla dener ve sunucu MaxAuthTries (varsayılan 6) sınırına takılıp bağlantıyı keser — doğru anahtar sıranın sonundaysa hiç denenmez bile. Çözüm, sadece istediğiniz anahtarı sunmaktır:

ssh -o IdentitiesOnly=yes -i ~/.ssh/dogru_anahtar kullanici@sunucu

Ajanda biriken anahtarları yönetmek için ssh agent ve anahtar yönetimi yazısındaki yaklaşımı öneririm.

5. Sunucu tarafındaki gerçek sebep. Konsol erişiminiz varsa (sağlayıcı panelindeki VNC/konsol) asıl cevap sunucu günlüğündedir:

sudo journalctl -u ssh -n 50 --no-pager        # Debian/Ubuntu
sudo journalctl -u sshd -n 50 --no-pager       # AlmaLinux/Rocky
sudo tail -n 50 /var/log/auth.log
sudo tail -n 50 /var/log/secure

Aradığınız satırlar şunlardır:

Authentication refused: bad ownership or modes for directory /home/ubuntu/.ssh
Authentication refused: bad ownership or modes for file /home/ubuntu/.ssh/authorized_keys
User ubuntu from 198.51.100.5 not allowed because not listed in AllowUsers
Invalid user deploy from 198.51.100.5

Bu satırlardan biri varsa teşhis bitmiştir.

İzinler: 700 ve 600 Kuralı, Sessiz Reddin Baş Sorumlusu#

OpenSSH, ev dizininizdeki anahtar dosyalarının başkaları tarafından okunabilir ya da yazılabilir olmasını güvenlik açığı sayar ve o dosyayı hiç okumaz. Kritik nokta şudur: size bunu söylemez. İstemci tarafında tek satır Permission denied (publickey) görürsünüz, sebep yalnızca sunucu günlüğünde yazar. Yıllardır gördüğüm en yaygın SSH sorunu budur ve genelde dosyaları FTP ile kopyalayan ya da authorized_keys dosyasını root olarak oluşturan kişilerde çıkar.

Doğru izin ve sahiplik şu şekildedir:

# Sunucuda, hedef kullanıcı olarak çalıştırın
chmod 700 ~/.ssh
chmod 600 ~/.ssh/authorized_keys
chmod 644 ~/.ssh/known_hosts
chown -R "$USER:$USER" ~/.ssh

# Ev dizininin kendisi de gruba/dünyaya YAZILABİLİR olmamalı
chmod 750 ~
ls -ld ~ ~/.ssh ~/.ssh/authorized_keys

Beklenen çıktı:

drwxr-x---  ubuntu ubuntu  /home/ubuntu
drwx------  ubuntu ubuntu  /home/ubuntu/.ssh
-rw-------  ubuntu ubuntu  /home/ubuntu/.ssh/authorized_keys

Sık atlanan üç ayrıntı:

• Ev dizini drwxrwxr-x ise reddedilirsiniz. .ssh içi kusursuz olsa bile üst dizin gruba yazılabilirse OpenSSH güvenmez. Ekip kurulumlarında chmod g+w /home/deploy yapıldıktan sonra girişin bozulması klasik senaryodur.
• Sahiplik yanlışsa izinler doğru olsa bile olmaz. sudo ile oluşturulan authorized_keys dosyası root:root olur ve kullanıcı kendi dosyasını okuyamaz. ls -l çıktısında sahibi mutlaka kontrol edin.
• İstemci tarafındaki özel anahtar da 600 olmalıdır. Aksi hâlde istemci anahtarı kullanmayı reddeder ve şu uyarıyı basar:

Permissions 0644 for '/home/kullanici/.ssh/id_ed25519' are too open.
This private key will be ignored.

chmod 600 ~/.ssh/id_ed25519

Linux izin modelinin bütününe hâkim değilseniz linux dosya izinleri yazısı bu sayıların ne anlama geldiğini net biçimde anlatıyor.

Anahtar Gerçekten Sunucuda mı#

İzinler doğruysa sıradaki soru, anahtarın karşı tarafta bulunup bulunmadığıdır. Önce istemcideki anahtarın parmak izini alın:

ssh-keygen -lf ~/.ssh/id_ed25519.pub
# 256 SHA256:xY9k3... kullanici@makine (ED25519)

Sonra sunucudaki dosyada aynı parmak izini arayın:

ssh-keygen -lf ~/.ssh/authorized_keys
wc -l ~/.ssh/authorized_keys
cat -A ~/.ssh/authorized_keys | head -3

cat -A çıktısı özellikle önemlidir. Anahtarı Windows'tan kopyala-yapıştır yapan kullanıcılarda satır sonlarına ^M (CRLF) girer ve OpenSSH satırı geçersiz sayar. Aynı şekilde açık anahtarın tek satır olması gerekir; e-posta veya panel üzerinden aktarılırken araya giren satır sonu anahtarı bozar. Temizlemek için:

sed -i 's/\r$//' ~/.ssh/authorized_keys

Anahtarı doğru biçimde eklemenin en güvenli yolu elle düzenlemek değil, aracı kullanmaktır:

# İstemciden — parola girişi hâlâ açıkken
ssh-copy-id -i ~/.ssh/id_ed25519.pub [email protected]

# Parola kapalıysa ve konsoldan giriyorsanız
mkdir -p ~/.ssh && chmod 700 ~/.ssh
echo "ssh-ed25519 AAAAC3NzaC1... kullanici@makine" >> ~/.ssh/authorized_keys
chmod 600 ~/.ssh/authorized_keys

⚠️ > yerine >> kullanmaya dikkat edin; tek > mevcut tüm anahtarları siler ve o an bağlı olan herkesin erişimini keser.

Sunucu Yapılandırması: sshd_config#

Anahtar yerinde, izinler doğru ve hâlâ reddediliyorsanız sıra sunucu ayarındadır. Konsoldan bağlanıp etkin yapılandırmayı okuyun — sshd -T çıktısı, dosyalara dağılmış tüm parçaların birleşmiş hâlini verir ve bu yüzden tek doğru kaynaktır:

sudo sshd -T | grep -Ei 'pubkeyauthentication|authorizedkeysfile|permitrootlogin|allowusers|allowgroups|denyusers|maxauthtries|passwordauthentication'

Beklenen değerler:

pubkeyauthentication yes
authorizedkeysfile .ssh/authorized_keys
permitrootlogin prohibit-password
maxauthtries 6
passwordauthentication no

Dikkat edilecek noktalar:

• AllowUsers / AllowGroups varsa liste dışındaki herkes reddedilir. Yeni açtığınız deploy kullanıcısını listeye eklemeyi unutmak, kusursuz bir anahtarla bile giriş yapamamanın en sık sebebidir.
• PermitRootLogin prohibit-password root'a yalnızca anahtarla izin verir; no ise anahtarla bile giremezsiniz.
• AuthorizedKeysFile değiştirilmiş olabilir. Bazı sertleştirme betikleri bunu /etc/ssh/authorized_keys/%u gibi merkezi bir yola alır; siz ev dizinine anahtar koyduğunuz sürece hiçbir şey değişmez.
• Match blokları en sona bakılır. Dosyanın altındaki bir Match User deploy bloğu, üstteki genel ayarları o kullanıcı için ezer.

Bir değişiklik yaptıysanız önce sözdizimini test edin, sonra yeniden yükleyin — ve mevcut oturumunuzu kapatmadan ikinci bir terminalle doğrulayın:

sudo sshd -t && sudo systemctl reload ssh

sshd -t hata verirse servisi yeniden başlatmayın; bozuk yapılandırmayla başlatılan SSH sizi tamamen dışarıda bırakır.

Sessiz Katiller: SELinux, Şifreli Ev Dizini, Fail2ban#

Her şey doğru göründüğü hâlde reddediliyorsanız sırada bunlar var.

SELinux etiketleri. AlmaLinux ve Rocky'de .ssh dizinini elle oluşturmak ya da başka yerden kopyalamak dosya bağlamını bozar; SELinux zorlayıcı moddayken sshd dosyayı okuyamaz ve neden okuyamadığını istemciye söylemez.

sudo restorecon -R -v /home/ubuntu/.ssh
sudo ausearch -m avc -ts recent | tail -20

SELinux davranışının bütünü için selinux temelleri ve yönetimi yazısına bakabilirsiniz.

Şifreli ev dizini. Kullanıcının ev dizini oturum açıldığında çözülüyorsa, sshd giriş anında authorized_keys dosyasını göremez — dosya henüz şifreli hâldedir. Çözüm, anahtarı /etc/ssh/authorized_keys/%u gibi şifresiz bir yola taşımaktır.

Fail2ban veya güvenlik duvarı. Art arda başarısız denemeden sonra IP'niz engellenmiş olabilir. Bu durumda genelde Permission denied değil Connection timed out alırsınız, ama karışık senaryolarda ikisi birlikte görülür:

sudo fail2ban-client status sshd
sudo fail2ban-client set sshd unbanip 198.51.100.5

Kurulum ve kural ayarları için fail2ban kurulumu yazısı yeterli ayrıntıyı veriyor.

Disk dolu. /home bölümü doluysa oturum açma başarısız olabilir. df -h ile kontrol edin; %100 dolu bir bölüm, açıklanamayan pek çok hatanın sessiz sebebidir.

Adım Adım Teşhis Sırası#

Panik yapmadan izlenecek sıra şudur:

1. Sunucuya ağ düzeyinde ulaşabiliyor musunuz: nc -vz 203.0.113.10 22
2. Doğru kullanıcı adını kullanıyor musunuz: yukarıdaki döngüyle deneyin.
3. ssh -vvv çıktısında anahtarınız sunuluyor mu: Offering public key satırını arayın.
4. Sunucuda izinler doğru mu: ls -ld ~ ~/.ssh ~/.ssh/authorized_keys
5. Parmak izleri eşleşiyor mu: ssh-keygen -lf ile iki tarafı karşılaştırın.
6. sshd -T çıktısında AllowUsers ya da PubkeyAuthentication no var mı.
7. Sunucu günlüğünde Authentication refused satırı var mı.

Bu yedi adım, karşılaştığım vakaların neredeyse tamamını kapsıyor. Adım 4'e gelmeden çözülen vaka sayısı da hiç az değil.

Kendinizi Kilitlemeden Test Etme#

SSH ayarlarıyla oynarken en tehlikeli an, açık oturumunuzu kapattığınız andır. Kuralı basit tutun: mevcut oturumu asla kapatmayın, değişikliği ikinci bir terminalden test edin. Ek olarak birkaç güvenlik ağı:

# Değişiklikten önce yapılandırmayı yedekleyin
sudo cp /etc/ssh/sshd_config /etc/ssh/sshd_config.$(date +%F)

# 10 dakika sonra otomatik geri alma (test başarılıysa iptal edin)
sudo bash -c 'sleep 600 && cp /etc/ssh/sshd_config.$(date +%F) /etc/ssh/sshd_config && systemctl reload ssh' &

Sağlayıcı panelindeki VNC/konsol erişiminin nasıl açıldığını sorun çıkmadan önce öğrenin. SSH'ı tamamen kaybettiğinizde tek kurtarıcınız odur; Clou.TR panelinde sunucu detay sayfasındaki konsol düğmesi bu işi görür ve anahtar tamiri için yeterlidir.

Sıkça Sorulan Sorular#

Permission denied publickey hatası parolamın yanlış olduğu anlamına mı gelir#

Hayır, tam tersine parolanız hiç sorulmamıştır. Parantez içinde yalnızca publickey yazması, sunucunun parola ile girişi tamamen kapattığını ve sadece anahtar kabul ettiğini gösterir. Bu durumda parola denemenin hiçbir faydası yoktur; sorun anahtarın sunucuda bulunamaması, yanlış kullanıcıya ait olması ya da dosya izinlerinin hatalı olmasıdır. Parantezde password da geçiyorsa parola yolu açıktır ve o zaman kimlik bilgilerinizi kontrol etmek anlamlıdır.

Anahtarım sunucuda duruyor ama yine reddediliyorum#

En olası sebep dosya izinleridir. OpenSSH, ~/.ssh dizini 700'den, authorized_keys dosyası 600'den geniş izinlere sahipse ya da dosyanın sahibi ilgili kullanıcı değilse anahtarı hiç okumaz ve bunu istemciye bildirmez. Ev dizininin kendisi de gruba yazılabilir olmamalıdır. Sunucuda ls -ld ~ ~/.ssh ~/.ssh/authorized_keys çıktısını kontrol edin ve /var/log/auth.log içinde "bad ownership or modes" satırını arayın; o satır varsa teşhis kesindir.

Hangi kullanıcı adıyla bağlanmam gerektiğini nasıl bulurum#

Kullanılan işletim sistemi imajına bağlıdır: Ubuntu bulut imajlarında ubuntu, AlmaLinux'ta almalinux, Rocky Linux'ta rocky, Debian'da debian, sağlayıcı panelinden ISO ile kurduğunuz sunucularda genelde root olur. Yanlış kullanıcıda sunucu anında reddeder, bu yüzden birkaçını sırayla denemek güvenlidir. Bazı imajlar root denemesinde "Please login as the user ... rather than the user root" uyarısı basar ve doğru adı doğrudan size söyler.

ssh -vvv çıktısında neye bakmalıyım#

Beş satır yeterlidir: sunucunun kabul ettiği yöntemleri gösteren "Authentications that can continue", denenecek anahtarları listeleyen "Will attempt key", sunulan anahtarı gösteren "Offering public key", kabul durumunu bildiren "Server accepts key" ve varsa "Too many authentication failures". Anahtarınız "Will attempt key" listesinde hiç yoksa sorun istemcidedir. "Offering public key" satırından sonra bağlantı yine kesiliyorsa anahtar sunucuda bulunamamıştır.

Çok fazla anahtarım var, sunucu bağlantıyı kesiyor#

SSH istemcisi ajandaki tüm anahtarları sırayla dener ve sunucunun MaxAuthTries sınırı (varsayılan 6) dolduğunda bağlantı "Too many authentication failures" ile kesilir. Doğru anahtar sıranın sonundaysa hiç denenmeden reddedilirsiniz. Çözüm ssh -o IdentitiesOnly=yes -i ~/.ssh/dogru_anahtar kullanici@sunucu biçiminde yalnızca tek anahtar sunmaktır. Kalıcı çözüm için ~/.ssh/config dosyasında her sunucu için IdentityFile ve IdentitiesOnly yes tanımlamak en temiz yoldur.

authorized_keys dosyasına anahtarı elle yapıştırdım ama çalışmıyor#

Büyük olasılıkla satır sonu ya da satır bölünmesi sorunu vardır. Açık anahtar tek satır olmak zorundadır; kopyalama sırasında araya giren satır sonu anahtarı geçersiz kılar. Windows'tan yapıştırılan içerikte CRLF satır sonları oluşur ve OpenSSH satırı okuyamaz. cat -A ~/.ssh/authorized_keys çıktısında ^M görüyorsanız sed -i 's/\r$//' ~/.ssh/authorized_keys komutuyla temizleyin; mümkünse elle yapıştırmak yerine ssh-copy-id kullanın.

AlmaLinux sunucumda her şey doğru ama giriş yapamıyorum#

SELinux dosya bağlamı bozulmuş olabilir. .ssh dizinini elle oluşturduğunuzda ya da başka bir yerden kopyaladığınızda etiketler yanlış kalır ve SELinux zorlayıcı moddayken sshd dosyayı okuyamaz. sudo restorecon -R -v /home/kullanici/.ssh komutu etiketleri düzeltir. Sorunun SELinux kaynaklı olduğunu sudo ausearch -m avc -ts recent çıktısındaki reddedilme kayıtlarından doğrulayabilirsiniz.

SSH erişimimi tamamen kaybettim, ne yapmalıyım#

Sağlayıcı panelindeki konsol veya VNC erişimini kullanın; bu bağlantı SSH servisinden bağımsızdır ve yapılandırmayı bozduğunuzda tek giriş yolunuz odur. Konsoldan bağlanıp sudo sshd -t ile yapılandırma hatasını görün, authorized_keys izinlerini düzeltin ve gerekiyorsa yedeklediğiniz sshd_config dosyasını geri yükleyin. Bu yüzden SSH ayarlarıyla oynamadan önce konsol erişiminin nasıl açıldığını öğrenmek ve açık bir oturumu kapatmadan test etmek altın kuraldır.

Kapanış#

Permission denied (publickey) hatası tek bir sebebin değil, bir zincirin çıktısıdır ve doğru sırayla ilerlerseniz neredeyse her zaman on dakikada çözülür. Önce doğru kullanıcı adını kesinleştirin — Ubuntu'da ubuntu, AlmaLinux'ta almalinux, elle kurulan sunucularda root. Sonra ssh -vvv çıktısında anahtarınızın gerçekten sunulup sunulmadığına bakın. Ardından sunucuda ~/.ssh dizininin 700, authorized_keys dosyasının 600 ve ikisinin de doğru kullanıcıya ait olduğunu doğrulayın; bu üç sayı, sessiz reddin en yaygın kaynağıdır ve sebebi yalnızca /var/log/auth.log içindeki "bad ownership or modes" satırında yazar. Son olarak sshd -T çıktısında AllowUsers ve PubkeyAuthentication değerlerini kontrol edin.

SSH ayarlarını kendiniz yönetmek istiyorsanız kök erişimi ve konsol imkânı sunan VDS sunucu ya da hızlı ölçeklenen projeler için bulut sunucu paketleri bu iş için doğru zemindir; ikisinde de panel üzerinden konsola bağlanıp kendinizi kilitlediğiniz bir durumdan çıkabilirsiniz. Sunucu sertleştirme, anahtar yönetimi ve erişim politikalarını kendiniz kurmak istemiyorsanız sunucu yönetimi hizmeti bu sorumluluğu üstlenir. Anahtar üretmek için güçlü bir parola gerekiyorsa şifre üretici aracını kullanabilirsiniz.