SSH key ile giriş: Şifre tabanlı erişimi devre dışı bırakma

Sunuculara uzaktan erişimde en sık yapılan hata, SSH tarafında şifre girişini açık bırakmaktır. Şifre tabanlı giriş, brute force (kaba kuvvet) denemelerine daha açıktır; saldırgan yalnızca parolaları tahmin ederek hedefe ulaşmaya çalışır. Bu rehberde, SSH key (anahtar) ile giriş kurulumunu tamamladıktan sonra şifre tabanlı erişimi devre dışı bırakmanın net adımlarını öğreneceksiniz. Ayrıca kopma riskini azaltmak için test ve geri dönüş planı da verilecektir.

Mantık: Şifre girişini kapatmak neyi değiştirir?

SSH’de iki temel kimlik doğrulama yöntemi vardır:

• PasswordAuthentication (şifre ile giriş)
• Public key authentication (SSH key ile giriş)

Şifre girişi kapatıldığında sunucu, yalnızca istemcinize tanımlı public key’i kabul eder. Böylece saldırganın ihtiyacı şifre tahmini yerine, özel anahtarın ele geçirilmesi olur. Bu da pratikte çok daha zor ve izlenebilir bir saldırıya dönüşür.

Net hedef şudur: Public key ile doğrulama çalışsın, şifre ile doğrulama tamamen bitsin.

Adım 1: SSH key üretin (özel anahtar sizde kalır)

Yeni bir anahtar çifti oluşturmak için istemcinizde (kendi bilgisayarınızda veya yönetim bastion’unuzda) şu komutu kullanın:

• Linux/macOS:

• ssh-keygen -t ed25519 -a 64

• Windows (PowerShell):

• ssh-keygen -t ed25519 -a 64

Burada önemli noktalar:

• ed25519 anahtar tipi, güncel ve verimlidir.
• Parola (passphrase) kullanmanız kesin gereklilik değildir; ancak anahtar dosyanız sızarsa bile ek bir koruma sağlar.
• Çıktı dosyaları genellikle ~/.ssh/id_ed25519 (private) ve ~/.ssh/id_ed25519.pub (public) olur.

Public dosyanızın içeriğini eklemek için okumanız gerekir:

• cat ~/.ssh/id_ed25519.pub

Bu çıktıyı bir sonraki adımda kullanacağız.

Anahtar izinleri (permission) kritik

Public key’i sunucuya kopyalamadan önce istemcide ve sunucuda izinler doğru olmalıdır. Yanlış izinler, SSH’nin key’i reddetmesine sebep olur.

Genel kural:

• Private key: sadece siz okuyabilirsiniz (600)
• .ssh dizini: sadece siz erişirsiniz (700)
• authorized_keys: sadece gerekli izinlerle okunur (600)

Adım 2: Public key’i sunucuya tanımlayın

Sunucuda hedef kullanıcı için authorized_keys dosyasına public key eklenir.

En temiz yöntem: ssh-copy-id

Bu araç varsa kullanın:

• ssh-copy-id -i ~/.ssh/id_ed25519 user@sunucu-ip

Ardından ilk giriş için şifre gerekebilir; çünkü key henüz doğrulanmamıştır.

El ile ekleme (her ortamda çalışır)

Sunucuda ilgili kullanıcı ile giriş yapın (ilk adımda şifre girişi açık olmalı):

1. .ssh dizini yoksa oluşturun: - mkdir -p ~/.ssh
2. Dosyayı açıp ekleyin: - nano ~/.ssh/authorized_keys
3. id_ed25519.pub içeriğini tek satır halinde yapıştırın.
4. İzinleri düzeltin: - chmod 700 ~/.ssh - chmod 600 ~/.ssh/authorized_keys

Eklediğiniz key’in satır sonunda boşluk/karakter hatası olmamalıdır.

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

Şifre tabanlı girişi kapatmadan önce net test yapın. Testin amacı şudur: Şifre kapansa bile key ile bağlanabiliyor musunuz?

Test komutu

İstemcinizde:

• ssh -i ~/.ssh/id_ed25519 user@sunucu-ip

Bu deneme şu çıktıyı vermelidir:

• Yetkilendirme gerçekleşir ve shell’e düşersiniz.
• “Permission denied (publickey)” gibi hata görmemelisiniz.

Net kontrol listesi

Şunlardan biri varsa şifreyi kapatmayın:

• Yanlış kullanıcı adı ile bağlanıyorsunuz
• Key doğru kullanıcının authorized_keys dosyasında değil
• .ssh izinleri sıkı değil (özellikle chmod adımları)
• Sunucuda ilgili yetkilendirme modülü/konfigürasyonu key’i reddediyor

Adım 4: SSH konfigürasyonunda şifre girişini kapatın

SSH ayarları genellikle /etc/ssh/sshd_config dosyasında tutulur.

Düzenleme

Sunucuda dosyayı açın:

• sudo nano /etc/ssh/sshd_config

Aşağıdaki satırları bulun ve şu şekilde ayarlayın:

• PasswordAuthentication no
• KbdInteractiveAuthentication no
• (Varsa) ChallengeResponseAuthentication no

Not: Bazı sistemlerde satırlar yorumludur (başında # olur). Yorumluysa aktif hale getirmek için # işaretini kaldırın.

Saltanat kuralı: Port değiştiyse dikkat

Eğer SSH portunu farklı bir porttan yönetiyorsanız (örneğin 22 yerine 2222), test ettiğiniz bağlantı ile kapatacağınız yapı aynı olmalıdır. Aksi halde “key çalışıyor gibi” görünüp yanlış portta sorun yaşayabilirsiniz.

Adım 5: Uygulamadan önce test edin ve servisi yeniden başlatın

Konfigürasyonu kaydettikten sonra SSH daemon’unuzun doğru yüklenip yüklenmediğini test edin.

Konfigürasyon doğrulama

• sudo sshd -t

Herhangi bir hata vermezse bir sonraki adıma geçebilirsiniz.

Yeniden başlatma

• Debian/Ubuntu:
• sudo systemctl restart ssh
• RHEL/CentOS:
• sudo systemctl restart sshd

Ardından yeni bir terminalden tekrar key ile bağlanın:

• ssh -i ~/.ssh/id_ed25519 user@sunucu-ip

Şifre sorusu gelmemelidir. Bağlanabiliyorsanız başarıdır.

Adım 6: Geri dönüş planı (kopma riskine karşı)

Şifre girişini kapatmak “hemen kalıcı” bir adımdır. Bu yüzden geri dönüş planı net olmalıdır.

En güvenli yöntem: İkinci bir yönetim kanalı

Mümkünse şunlardan birini kullanın:

• Sunucu üzerinde bir konsole erişimi (panel / KVM / rescue mode)
• İkinci bir yetkili kullanıcı için key tanımlama
• En azından güncelleme öncesi aktif bir terminal oturumu açık kalsın

İkinci anahtar stratejisi

Şu iki key’i ayrı ayrı tanımlayın:

• Bir anahtar: ana bilgisayarınız
• Bir anahtar: yönetim bastion’unuz ya da yedek yönetim cihazınız

Böylece key dosyanız bozulsa bile erişim devam eder.

Hata olursa: en hızlı düzeltme

Şifre kapatıldıktan sonra key ile bağlanamıyorsanız:

1. Konsole erişimi varsa sshd_config içindeki PasswordAuthentication değerini yes yapın.
2. Değişikliği doğrulayıp SSH’yi restart edin.
3. Sonra tekrar PasswordAuthentication no adımına dönmeden önce key’in gerçekten kabul edildiğini doğrulayın.

Net karşılaştırma: Hangisini ne zaman kullanın?

Aşağıdaki tablo, hangi doğrulama yönteminin ne tür risk oluşturduğunu pratik bir şekilde özetler.

Net öneri: Şifre girişi kapalı, key ile giriş açık, mümkünse key’lerde passphrase kullanımı ve en az 2 yönetim key’i.

Adım 7: Ek hardening (şifre kapatmanın tamamlayıcısı)

Şifre tabanlı girişi kapatmak kritik bir adım olsa da tek başına yeterli değildir. Aşağıdaki ayarlar, brute force ve gereksiz yüzey alanını daha da azaltır.

1) Root login’i kapatın (varsa)

sshd_config içinde:

• PermitRootLogin no

Bu sayede direkt root ile giriş denemeleri engellenir.

2) Boşta kalan oturumları sınırlayın

Bağlandıktan sonra oturumun sonsuza kadar açık kalmaması için:

• ClientAliveInterval 300
• ClientAliveCountMax 2

Değerleri ihtiyaçlarınıza göre güncelleyebilirsiniz; burada net amaç sessiz kopmaları yakalamaktır.

3) Fail2ban (opsiyonel ama yaygın)

Brute force denemelerinde IP bazlı engelleme yapmak için fail2ban kullanılır. Bu, SSH portuna yoğun deneme geldiğinde saldırıyı hızla düşürür.

Not: Bu rehberin odağı SSH key olduğu için fail2ban konfigürasyon detayına girmiyorum; ancak şifre kapatma sonrası da log temizliği ve isabetli engelleme için değerli bir tamamlayıcıdır.

Ortak sorunlar: “Key kabul edilmiyor” hatası nasıl çözülür?

Aşağıdaki hatalar sık görülür ve doğrudan konfigürasyon/izin kaynaklıdır.

• Permission denied (publickey)
• Yanlış kullanıcı
• authorized_keys içine yanlış key kopyalama
• İzinler bozuk (~/.ssh veya authorized_keys)

İzinleri hızlı kontrol edin

Sunucuda:

• ls -ld ~/.ssh
• ls -l ~/.ssh/authorized_keys

Hedef:

• .ssh → drwx------
• authorized_keys → -rw-------

SSH key’i yönetin: yaşam döngüsü ve güvenlik

Şifreyi kapatmak tek seferlik bir işlem değildir; key yaşam döngüsünü yönetmek gerekir.

Key değişimi

• Bir çalışan ayrıldığında veya cihazınız kaybolduğunda key’i sunucudan kaldırın.
• Bir key dosyası sızdıysa derhal yeni key üretin.

Yedek (backup) yaklaşımı

Key dosyalarını şifreli saklayın. Private key’in kendisi aynı kalır; public key ise sunucuda kalabilir. Yedeklerinizi şifreleyerek saklamak, saldırgan eline geçse bile kullanımını zorlaştırır.

Sonuç: Şifre girişini kapatın ama önce key’i kesin çalıştırın

SSH key ile giriş kurup sonra PasswordAuthentication no adımını uygulamak, sunucunuzun erişim güvenliğini doğrudan artırır. En kritik kural şudur: Şifre kapatmadan önce yeni bir terminalden key ile giriş yaptığınızı net olarak doğrulayın ve mümkünse ikinci bir yönetim kanalı/ikinci key hazır bulundurun. Bu sırayı uygularsanız kopma riski azalır; kalıcı, test edilmiş bir erişim modeli elde edersiniz.

İsterseniz NetKıyas üzerinde bulunduğunuz sunucu türüne (VPS, VDS, dedicated) göre en uygun erişim yönetimi senaryosunu da birlikte netleştirebilirsiniz: panel erişimi, konsol/restore imkânı ve log izleme pratikleri bu kararda belirleyicidir.