SSH key ile giriş: şifre tabanlı girişi devre dışı bırakma

SSH üzerinden sunucuya erişim, çoğu altyapıda tek bir kapı gibidir: doğru kurulduğunda güvenliği ciddi artırır, yanlış kurulduğunda ise kilitlenmeye kadar giden kesinti yaratabilir. Bu rehberde hedef, SSH key (public key) ile giriş yapmak ve password-based authentication (şifre ile kimlik doğrulama) yöntemini devre dışı bırakmaktır. Ayrıca geçiş sırasında erişiminizi kaybetmemeniz için adım adım doğrulama yapacağız.

Bu yazıyı okuduktan sonra: (1) Anahtar oluşturma ve yetkilendirme, (2) sshd_config üzerinden güvenli ayar, (3) test ve geri dönüş planı, (4) loglardan tarama/deneme takibi netleşecek.

Neden şifre yerine SSH key? (ve neden tek seferde kesmeyelim)

SSH, brute-force (kaba kuvvet) denemelerine maruz kalabilen bir porttur. Şifre tabanlı giriş açıkken saldırganlar parola tahmini yapar; başarı oranı zayıf parola ve uzun maruz kalma ile hızla artar. Anahtar tabanlı erişimde ise kimlik doğrulama, istemcinin özel anahtarına (private key) ve sunucunun kabul ettiği public key’e dayanır.

Şifre girişini kapatmanın güvenlik faydası yüksektir; ancak yanlış sırayla yapılırsa erişim kilidi oluşur. Bu yüzden işlem sırası “önce key ile doğrula, sonra şifreyi kapat” şeklinde ilerlemelidir.

Hedef senaryo

• Mevcut kullanıcı hesabınız sunucuya erişiyor.
• İstemcinizde bir veya daha fazla SSH key mevcut veya oluşturulacak.
• sshd yeniden başlatıldığında key ile giriş sorunsuz devam edecek.

Adım 1: Yerelde SSH key üretin (ed25519 önerilir)

Key üretimi yerel makinenizde yapılır. Sunucu tarafında beklenen, public key’in yetkilendirilmesidir.

Yeni key üretme

Linux/macOS/WSL veya Windows (PowerShell) ortamında aşağıdaki yaklaşım yaygındır. Önerilen algoritma ed25519’dir.

ssh-keygen -t ed25519 -a 64 -f ~/.ssh/netkyas_access -C "server-access" 

Bu komut: - Özel anahtar: ~/.ssh/netkyas_access - Public key: ~/.ssh/netkyas_access.pub

çıkarır.

Parola (passphrase) kullanımı

Key dosyanıza passphrase koymak, özel anahtar ele geçirilse bile saldırganın doğrudan giriş yapmasını zorlaştırır. En pratik yaklaşım, passphrase’i kullanmak ve günlük kullanımda agent ile yönetmektir (ör. ssh-agent).

Adım 2: Public key’i sunucuya yetkilendirin

Sunucuda hedef, ilgili kullanıcı için ~/.ssh/authorized_keys dosyasına public key’i eklemektir.

Dizin ve yetkiler kritik

Sunucuda SSH’nin düzgün okuyabilmesi için izinler doğru olmalıdır. - ~/.ssh dizini: genelde 700 - authorized_keys: genelde 600

Bu izinleri yanlış ayarlamak, key ile girişin reddedilmesine yol açar.

En güvenli yöntem: ssh-copy-id (varsa)

ssh-copy-id -i ~/.ssh/netkyas_access.pub kullanici@sunucu_ip

authorized_keys elle ekleme

authorized_keys dosyası yoksa oluşturun; public key satırını dosyaya ekleyin.

Sunucuda tipik adımlar: - mkdir -p ~/.ssh - chmod 700 ~/.ssh - nano ~/.ssh/authorized_keys ve içeriği ekle - chmod 600 ~/.ssh/authorized_keys

Adım 3: Key ile girişin çalıştığını doğrulayın

Şifreyi kapatmadan önce key doğrulaması mutlaka denenmelidir. Bu aşama, “kilitlenme riskini” sıfıra yaklaştırır.

Doğrulama komutu

İstemciden özellikle key dosyanızı belirterek deneyin:

ssh -i ~/.ssh/netkyas_access kullanici@sunucu_ip

Başarılıysa bir sonraki adım olan SSH ayarına geçebilirsiniz.

Hata durumunda tipik kök nedenler

• authorized_keys yanlış dosyaya eklenmiştir (başka kullanıcıya gidilmiştir).
• ~/.ssh veya authorized_keys izinleri yanlış bırakılmıştır.
• Eklenen key doğru ama kullanıcı farklıdır.
• Sunucuda hâlâ farklı bir sshd_config aktif olabilir.

Adım 4: sshd_config üzerinden şifre tabanlı girişi kapatın

SSH ayarlarının yeri dağıtımdan dağıtıma değişebilir; çoğu sistemde sshd_config şu dosyalardadır: - /etc/ssh/sshd_config - Bazı sistemlerde /etc/ssh/sshd_config.d/*.conf parçaları da dahil olur.

Yapılacak temel ayarlar

Şifre tabanlı kimlik doğrulamayı devre dışı bırakmak için en azından şunları kapatın: - PasswordAuthentication no - (Bazı senaryolarda) KbdInteractiveAuthentication no

Önerilen güvenli başlangıç kombinasyonu (dağıtımınıza göre kontrol edin):

PasswordAuthentication no
KbdInteractiveAuthentication no
PubkeyAuthentication yes

Not: Zorunlu değildir ama PubkeyAuthentication yes anahtar tabanlı yöntemi netleştirir.

Dosyayı düzenleme ve test etme

Önce sshd ayarlarının sözdizimini kontrol edin:

sudo sshd -t

Sonra sshd yeniden yükleyin (tam restart yerine reload bazı sistemlerde daha kontrollüdür):

sudo systemctl reload sshd

Dağıtımınız Debian/Ubuntu ise servis adı genellikle ssh olur:

sudo systemctl reload ssh

Değişiklik sonrası test (kritik)

Yeni bir terminalden, yine key ile giriş yapın:

ssh -i ~/.ssh/netkyas_access kullanici@sunucu_ip

Ardından aynı kullanıcı ile şifre girişi denemesi yapın (key istemeden):

ssh kullanici@sunucu_ip

Beklenen davranış: “password” istemi çıkmadan ya da şifreyle giriş reddedilerek key zorunlu hale gelmesi.

Adım 5: VDS/VPS/Dedicated ortamında ekstra güvenlik katmanları

SSH’yi key’e bağlamak tek başına güçlüdür; fakat genellikle aynı hedefe hizmet eden tamamlayıcı ayarlar da aynı dosyada ele alınabilir. Aşağıdaki adımlar güvenliğin “tek noktada” kalmasını önler.

Root ile doğrudan giriş yerine kısıt

Kullanıcıyı ayrı tutmak, yetki kapsamını azaltır. - PermitRootLogin no (mevcut politika ve gereksinime göre)

Varsayılan port yerine rastgele port (isteğe bağlı)

Bu işlem güvenlikte “tek başına” çözüm değildir ama otomatik taramaları azaltır. - Port 2222 gibi bir değer

Port değiştirirken mevcut bağlantılarınız kesintiye uğramasın diye sırayı koruyun: önce key test edin, sonra portu değiştirin.

Fail2ban gibi brute-force engelleyiciler

Key giriş aktifken fail2ban gereksizleşebilir; ancak yanlış konfigürasyon veya başka servisler için yine de değerlidir. - Fail2ban, başarısız deneme sayısını izleyip IP’yi geçici engeller.

Adım 6: Sunucu loglarından deneme hareketlerini takip edin

Şifre girişini kapattıktan sonra loglarda şu tür sinyaller görmeye başlarsınız: - Şifre denemeleri “denied” veya “authentication failure” olarak - Key doğrulamaları başarılı “Accepted publickey” olarak

Dağıtıma göre log konumları değişebilir: - /var/log/auth.log (Debian/Ubuntu) - /var/log/secure (RHEL/CentOS/Amazon Linux)

Pratik kontrol komutları

tail -n 200 /var/log/auth.log

Arama için:

grep -i "publickey\|authentication failure\|password\|sshd" /var/log/auth.log | tail -n 200

Güvenilirlik göstergesi

• Key ile giriş başarılı mı?
• Şifre giriş denemeleri gerçekten reddediliyor mu?
• Ulaşılma denemeleri artıyor ama başarılı olmuyor mu?

Bu üç sorunun cevabı “evet” olduğunda geçiş tamamlanmış sayılır.

SSH key’leri yönetirken sık yapılan hatalar

Aşağıdaki hatalar, “konfigürasyon doğru ama çalışmıyor” sorunlarının büyük kısmını oluşturur.

1) authorized_keys satır sonu/format

Public key tek satır olmalı ve gereksiz boşluklar/satır kırılmaları olmamalıdır. Dosyaya yanlışlıkla çok satırlı veya eksik kopyalama yapılması reddedilmeye sebep olur.

2) Yanlış kullanıcıya ekleme

Key’i kullaniciA için ekleyip kullaniciB ile bağlanırsanız reddedilir. Key dosyası doğru home dizininde mi kontrol edin.

3) İzinler (permissions)

chmod ile doğru izinleri sağlamazsanız SSH “güvenli değil” diyerek key’i kabul etmeyebilir.

4) Birden fazla sshd_config etkisi

Bazı sistemlerde Include veya sshd_config.d kullanılır. Ana dosyada doğru ayar var ama parçalı config farklı davranıyorsa sonuç şaşırtır. Bu yüzden sshd -t ve gerçek bağlantı testi zorunludur.

Hızlı kontrol listesi (uygulamadan önce/sonra)

Aşağıdaki kontrol listesi, geçişi “tekrar ve doğrulama” düzeninde yönetir.

Uygulama öncesi

• [ ] İstemcide en az bir geçerli SSH key var
• [ ] Key ile sunucuya giriş denendi ve çalışıyor
• [ ] Sunucuda authorized_keys doğru kullanıcıya eklendi
• [ ] sshd -t testi sorunsuz

Uygulama sonrası

• [ ] ssh kullanici@ip şifre istemi olmadan reddediyor
• [ ] ssh -i keyfile kullanici@ip başarılı
• [ ] Loglarda Accepted publickey görünüyor

Geri dönüş planı: kilitlenmeden önce plan yapın

Bu geçişte en kötü senaryo, şifreyi kapatıp key ile de giriş yapamamanızdır. Bunu engellemek için iki pratik yaklaşım kullanılır:

1) Aynı oturumda çalışın ve ikinci bir test pencere açın

Şifreyi kapatmadan önce key ile giriş doğrulanmalı. Değişikliği yaptıktan sonra aynı anda iki pencerede test yapın.

2) Provider’ın konsol/rekombin erişimi varsa hazır tutun

VDS/VPS sağlayıcılarda web panel üzerinden “serial console” veya “rescue console” gibi mekanizmalar bulunabilir. Bu mekanizmayı geçişten önce kontrol edin.

Sonuç: Anahtar tabanlı girişe geçin, şifre kapatmayı kontrollü yapın

Şifre tabanlı SSH girişi kapatıldığında otomatik saldırı yüzeyi azalır; key tabanlı erişim ise kimlik doğrulamayı belirgin şekilde güçlendirir. En doğru yol, önce SSH key ile girişin çalıştığını test etmek, ardından sshd_config üzerinden PasswordAuthentication no ayarını devreye alıp gerçek bağlantı denemesini tekrarlamaktır.

Aksiyon önerisi: Bugün mevcut erişiminizi koruyarak anahtarla giriş doğrulayın, sshd -t ile konfigürasyonu kontrol edin ve şifre girişini kapattıktan sonra loglardan reddedilen denemeleri doğrulayın. Bu adımlar tamamlandığında geçiş “kanıtlı” hale gelir ve güvenliğini sürdürülebilir biçimde artırmış olursunuz.