SSH Permission Denied Hatası Nasıl Çözülür? Şifre ve Public Key Sorunları

SSH Permission Denied hatası, SSH sunucusuna ulaşılabildiği ancak kimlik doğrulamanın başarısız olduğu anlamına gelir. Yanlış kullanıcı adı veya parola, hatalı SSH anahtarı, authorized_keys izinleri, root girişinin kapalı olması ya da sshd_config ayarları bu hataya neden olabilir.

Örneğin şu hata görülebilir:

Permission denied (publickey).

veya:

Permission denied (publickey,password).

Bu hata Connection Refused ile aynı değildir. Permission Denied görüyorsanız çoğu durumda SSH servisine ulaşılmış, fakat giriş kabul edilmemiştir.

İlk olarak kullanıcı adını kontrol edin

En basit nedenlerden biri yanlış kullanıcıyla bağlanmaya çalışmaktır.

Örneğin:

ssh root@SUNUCU_IP

yerine sunucu:

ubuntu

kullanıcısını bekliyor olabilir.

Bu durumda:

ssh ubuntu@SUNUCU_IP

gerekebilir.

Hosting veya VPS sağlayıcınızın size verdiği ilk SSH kullanıcı bilgisini kontrol edin.

SSH portunu kontrol edin

Sunucu standart 22 portu yerine farklı bir SSH portu kullanıyorsa:

ssh -p 2222 kullanici@SUNUCU_IP

şeklinde bağlanmanız gerekir.

Yanlış port genellikle Permission Denied yerine farklı bağlantı hatalarına yol açsa da bağlantı yaptığınız servisin ve portun doğru olduğunu doğrulamak önemlidir.

Şifreyle giriş yapıyorsanız

Şu komutla bağlanabilirsiniz:

ssh kullanici@SUNUCU_IP

Ardından parola istenir.

Linux terminalinde parola yazarken ekranda:

- Yıldız

- Nokta

- Karakter

görünmemesi normaldir.

Parolanızı yazıp Enter tuşuna basın.

Doğru şifreyi girdiğiniz halde Permission Denied alıyorsanız

Şunları kontrol edin:

- Kullanıcı adı doğru mu?

- Hesap aktif mi?

- Parola gerçekten bu kullanıcıya mı ait?

- SSH şifre girişine izin veriyor mu?

- Root ile giriş kapatılmış mı?

- IP adresiniz engellenmiş olabilir mi?

- Klavye düzeni nedeniyle parola yanlış giriliyor olabilir mi?

Özellikle karmaşık parolalarda Türkçe ve İngilizce klavye düzeni farkı sorun oluşturabilir.

PasswordAuthentication ayarını kontrol edin

Sunucuya başka bir yöntemle erişiminiz varsa SSH yapılandırmasını kontrol edebilirsiniz.

Dosya genellikle:

/etc/ssh/sshd_config

konumundadır.

İlgili ayarlardan biri:

PasswordAuthentication

olabilir.

Şifreyle giriş bilinçli olarak kapatılmışsa SSH yalnızca anahtar tabanlı kimlik doğrulamayı kabul edebilir.

Güvenlik amacıyla kapatılmış bir ayarı yalnızca kolaylık için açmadan önce riskleri değerlendirin.

SSH anahtarıyla bağlanma

Private key kullanıyorsanız örneğin:

ssh -i ~/.ssh/id_ed25519 kullanici@SUNUCU_IP

ile bağlantı kurulabilir.

Önemli nokta şudur:

Private key sizin cihazınızda kalır.

Sunucu tarafında ise bunun karşılığı olan public key kullanıcının authorized_keys dosyasında bulunur.

Private key dosyanızı sunucuya veya başka kişilere göndermeyin.

Permission denied publickey ne demek?

Şu hata:

Permission denied (publickey).

sunucunun public key authentication beklediğini ancak istemcinin sunduğu anahtarın kabul edilmediğini gösterir.

Olası nedenler:

- Yanlış private key kullanılıyor.

- Public key sunucuda kayıtlı değil.

- Yanlış kullanıcıyla bağlantı kuruluyor.

- authorized_keys yanlış kullanıcıya ait.

- Dosya izinleri hatalı.

- SSH istemcisi beklediğiniz anahtarı göndermiyor.

Hangi SSH anahtarının kullanıldığını nasıl görebilirsiniz?

Detaylı bağlantı çıktısı için:

ssh -v kullanici@SUNUCU_IP

kullanabilirsiniz.

Daha ayrıntılı çıktı gerekirse:

ssh -vv kullanici@SUNUCU_IP

veya:

ssh -vvv kullanici@SUNUCU_IP

kullanılabilir.

Bu çıktı hangi anahtarların denendiğini ve kimlik doğrulamanın hangi aşamada başarısız olduğunu anlamaya yardımcı olur.

Ancak debug çıktısını internette paylaşırken kullanıcı adları, IP adresleri ve diğer hassas bilgileri kontrol edin.

Belirli private key'i zorla kullanabilirsiniz

Birden fazla SSH anahtarınız varsa:

ssh -i ~/.ssh/id_ed25519 kullanici@SUNUCU_IP

kullanabilirsiniz.

Gerekirse yalnızca belirtilen kimliğin kullanılmasını sağlamak için:

ssh -o IdentitiesOnly=yes -i ~/.ssh/id_ed25519 kullanici@SUNUCU_IP

komutu yararlı olabilir.

Bu yöntem çok sayıda SSH anahtarı bulunan bilgisayarlarda hangi key'in gönderildiğini netleştirir.

authorized_keys nerede bulunur?

Kullanıcının public key kayıtları genellikle:

~/.ssh/authorized_keys

dosyasında bulunur.

Örneğin kullanıcı ubuntu ise dosya o kullanıcının home dizinindeki .ssh klasöründe olmalıdır.

Root kullanıcısının authorized_keys dosyası ile başka bir kullanıcının dosyası aynı değildir.

Bu nedenle anahtarı yanlış kullanıcının hesabına eklemek Permission Denied hatasına neden olabilir.

authorized_keys izinleri önemli mi?

Evet.

OpenSSH güvenlik nedeniyle aşırı geniş izinlere sahip SSH dosyalarını reddedebilir.

Yaygın olarak .ssh dizini için:

chmod 700 ~/.ssh

ve authorized_keys için:

chmod 600 ~/.ssh/authorized_keys

kullanılır.

Ayrıca dosyaların doğru kullanıcıya ait olduğundan emin olun.

Örneğin:

ls -la ~/.ssh

ile kontrol edebilirsiniz.

Private key izinleri nasıl olmalı?

Linux veya macOS üzerinde private key dosyasının izinleri fazla genişse SSH istemcisi anahtarı kullanmayı reddedebilir.

Örneğin:

chmod 600 ~/.ssh/id_ed25519

kullanılabilir.

Private key'in yalnızca sahibi tarafından erişilebilir olması güvenlik açısından önemlidir.

Root girişi neden reddedilebilir?

SSH sunucusu root ile doğrudan girişi kapatmış olabilir.

sshd_config içerisinde:

PermitRootLogin

ayarı bu davranış üzerinde etkilidir.

Bazı sunucularda önce normal kullanıcıyla giriş yapılır:

ssh ubuntu@SUNUCU_IP

ardından gerekli işlemler:

sudo

ile gerçekleştirilir.

Root girişini yalnızca Permission Denied hatasını kaldırmak amacıyla açmak doğru bir güvenlik yaklaşımı değildir.

sshd_config değiştirilirken dikkat

SSH yapılandırmasında değişiklik yaptıysanız önce syntax kontrolü yapın:

sudo sshd -t

Komut hata vermiyorsa yapılandırma geçerli olabilir.

Ardından dağıtıma göre SSH servisi reload edilebilir.

Örneğin:

sudo systemctl reload ssh

veya bazı sistemlerde:

sudo systemctl reload sshd

kullanılabilir.

Mevcut SSH oturumunu kapatmadan test edin.

Yeni ayarlarla ikinci bir terminalden giriş yapabildiğinizi doğruladıktan sonra mevcut bağlantıyı kapatmak, sunucunun dışında kalma riskini azaltır.

SSH logları nasıl kontrol edilir?

Ubuntu ve Debian sistemlerinde authentication kayıtları sıklıkla:

/var/log/auth.log

içerisinde bulunabilir.

Örneğin:

sudo tail -f /var/log/auth.log

kullanılabilir.

systemd journal kullanan sistemlerde:

sudo journalctl -u ssh

veya servisin adına göre:

sudo journalctl -u sshd

kullanılabilir.

Burada:

- Yanlış kullanıcı

- Hatalı parola

- Kabul edilmeyen public key

- Yetki problemi

- SSH yapılandırma problemi

hakkında daha ayrıntılı kayıt bulunabilir.

Fail2ban nedeniyle giriş engellenebilir mi?

Evet.

Çok sayıda başarısız SSH girişinden sonra Fail2ban gibi güvenlik araçları IP adresini geçici veya yapılandırmaya bağlı şekilde engelleyebilir.

Fail2ban kullanılıyorsa:

sudo fail2ban-client status

ile genel durum kontrol edilebilir.

SSH jail adı yapılandırmaya göre değişebileceği için doğrudan varsaymak yerine mevcut jail listesini inceleyin.

Kendi IP adresinizi engelden çıkarırken gerçekten size ait olduğundan emin olun.

SSH agent yanlış anahtar kullanıyor olabilir

Bilgisayarınızda birden fazla SSH anahtarı varsa SSH agent farklı anahtarları deneyebilir.

Yüklü anahtarları görmek için:

ssh-add -l

kullanılabilir.

Gerekirse doğru anahtar bağlantı komutunda -i ile açıkça belirtilebilir.

SSH config kullanmak bağlantıyı kolaylaştırır

Sürekli aynı sunucuya bağlanıyorsanız istemci tarafındaki:

~/.ssh/config

dosyasında sunucu bilgileri tanımlanabilir.

Örneğin yapılandırmada:

Host sunucum

HostName SUNUCU_IP

User kullanici

IdentityFile ~/.ssh/id_ed25519

gibi bilgiler bulunabilir.

Daha sonra:

ssh sunucum

ile bağlantı kurulabilir.

Bu aynı zamanda yanlış kullanıcı veya yanlış key kullanma ihtimalini azaltabilir.

Sunucuya hiç giriş yapamıyorsanız ne yapılmalı?

SSH ayarını yanlış değiştirdiyseniz ve hiçbir kullanıcıyla bağlanamıyorsanız VPS sağlayıcınızın sunduğu:

- Web console

- VNC console

- Serial console

- Rescue mode

gibi SSH'den bağımsız erişim yöntemlerini kullanmanız gerekebilir.

Bu nedenle SSH güvenlik ayarlarını değiştirirken aktif oturumu hemen kapatmamak önemlidir.

Permission Denied ile Connection Refused arasındaki fark

Connection refused

genellikle bağlantının SSH servisine kurulamadığını gösterir.

Olası nedenler:

- SSH servisi kapalı

- Yanlış port

- Port dinlenmiyor

- Firewall problemi

olabilir.

Permission denied

ise çoğunlukla sunucuya ulaşıldığını ancak kimlik doğrulamanın başarısız olduğunu gösterir.

Bu nedenle iki hata için uygulanacak teşhis adımları farklıdır.

SSH Permission Denied için hızlı kontrol sırası

Şu sırayla ilerleyebilirsiniz:

1. Sunucu IP adresini doğrulayın.

2. SSH portunu kontrol edin.

3. Kullanıcı adının doğru olduğundan emin olun.

4. Parola kullanıyorsanız doğru hesaba ait olduğunu kontrol edin.

5. Public key kullanıyorsanız doğru private key'i seçin.

6. ssh -v ile bağlantıyı debug edin.

7. authorized_keys dosyasını kontrol edin.

8. .ssh ve key dosyalarının izinlerini inceleyin.

9. Dosya sahipliğini doğrulayın.

10. PasswordAuthentication ve PermitRootLogin ayarlarını kontrol edin.

11. SSH authentication loglarını inceleyin.

12. Fail2ban veya benzeri güvenlik sistemlerini kontrol edin.

13. Değişiklik yaptıysanız mevcut oturumu kapatmadan yeni bağlantıyı test edin.

Sık yapılan hatalar

SSH Permission Denied çözülürken şu hatalardan kaçının:

- Yanlış kullanıcıyla sürekli şifre denemek

- Public key yerine private key'i sunucuya yüklemek

- Private key'i başkalarıyla paylaşmak

- .ssh dizinine gereksiz geniş izin vermek

- Her şeyi 777 yapmak

- Root girişini gereksiz yere açmak

- SSH loglarını kontrol etmemek

- sshd_config değişikliğini test etmeden uygulamak

- Çalışan SSH oturumunu yeni bağlantıyı doğrulamadan kapatmak

Özetle, SSH Permission Denied hatası çoğunlukla bağlantı probleminden değil kimlik doğrulama probleminden kaynaklanır. En önemli kontroller kullanıcı adı, parola veya SSH anahtarı, authorized_keys dosyası ve SSH sunucu yapılandırmasıdır.

Özellikle uzak VPS üzerinde değişiklik yaparken temel güvenlik kuralı şudur: Yeni SSH bağlantısının çalıştığını doğrulamadan mevcut çalışan SSH oturumunu kapatmayın.