SSH key ile şifre girişini kapatın: Güvenli erişim rehberi

Güvenli bir sunucu erişimi, yalnızca “giriş yapmak” değil; yanlış kimlik doğrulama yöntemlerini devre dışı bırakmak ve saldırı yüzeyini küçültmek demektir. SSH tarafında şifreyle giriş (password authentication) açık kaldığında, saldırganların brute force denemeleri için net bir hedef oluşur. Bu rehberde SSH key (anahtar) kullanarak kimlik doğrulamayı kuracak, ardından şifre tabanlı girişi devre dışı bırakacaksınız. En kritik risk olan “anahtarı eklemeden şifreyi kapatıp kendinizi kilitleme” durumunu adım adım önleyeceksiniz.

1) Hedef: SSH’de şifreyi kapatırken kendinizi kilitlememek

Şifre tabanlı SSH oturumlarında iki problem bir araya gelir: - Saldırganlar otomasyonla çok sayıda deneme yapabilir (brute force). - Şifrelerin tekrar kullanımı veya zayıf tahmin edilebilirlik riski vardır.

SSH key tarafında ise sunucu, kullanıcının elindeki özel anahtarla (private key) doğrulama yapar. Bu yaklaşımda “tahmin edilecek bir parola” bırakmazsınız.

Bu değişiklikte tek büyük risk vardır: Anahtarı sunucuya eklemeden PasswordAuthentication no gibi bir ayarı hemen devreye almak.

Kural: Önce key doğrulamasını test edin, sonra şifreyi kapatın.

Hızlı kontrol listesi (başlamadan)

• Sunucu üzerinde ~/.ssh/authorized_keys dosyası doğru izinlerle çalışıyor.
• Kendi anahtarınız (public key) sunucuya ekli.
• Mümkünse yeni ayarları uygulamadan önce ayrı bir terminal/oturumdan test yapıyorsunuz.

2) SSH key üretimi: Sunucuya özel değil, kullanıcıya ait olun

Key üretimi yerel makinede yapılır. Linux/macOS’ta genellikle şu komut kullanılır:

ssh-keygen -t ed25519 -a 64

Windows tarafında (PowerShell) OpenSSH ile benzer şekilde ssh-keygen kullanılır. Komut sonunda iki dosya üretirsiniz: - id_ed25519 (private key): Kesinlikle paylaşılmaz. - id_ed25519.pub (public key): Sunucuya eklenecek kısımdır.

Önemli: Key dosyalarınızın izinleri hatalı olursa SSH key doğrulaması reddedebilir. Private key dosyası için sadece kendi kullanıcı yetkisine sahip olun.

3) Public key’i sunucuya ekleyin (AuthorizedKeys aşaması)

Sunucuya bağlandıktan sonra (şimdilik şifre ile bağlanabiliyor olsanız bile) public key’i doğru yere ekleyin.

Mevcut kullanıcı için authorized_keys ekleme

Sunucuda hedef kullanıcı adına şu adımları izleyin:

1) .ssh dizini yoksa oluşturun: - mkdir -p ~/.ssh

2) İzinleri doğru verin: - chmod 700 ~/.ssh

3) Public key’i authorized_keys dosyasına ekleyin: - nano ~/.ssh/authorized_keys (veya cat >>) ile satırı ekleyin - Satır sonunda yeni satır kalması sorun çıkarmaz

4) Dosya izinlerini doğru verin: - chmod 600 ~/.ssh/authorized_keys

Anahtar ekledikten sonra test (kilitlenmeyi önleyen adım)

Şifreyi henüz kapatmayın. Önce şu testi yapın:

1) Yeni bir terminal/sekmede yeniden bağlanmayı deneyin. 2) SSH istemcisinde key kullanımı otomatik ise test tamam. 3) İsterseniz key’i açıkça belirtin:

ssh -i ~/.ssh/id_ed25519 kullanıcı@sunucu_ip

Başarılı bağlandıysanız, artık şifre tabanlı girişi kapatmaya hazırsınız.

4) Şifre tabanlı SSH girişini devre dışı bırakın

Sunucuda SSH daemon ayar dosyası genellikle /etc/ssh/sshd_config içindedir.

Değişiklik yapmadan önce yedek alın

• Dosyayı kopyalayın: /etc/ssh/sshd_config → bir kopya

sshd_config üzerinde net ayarlar

En kritik satırlar şunlardır:

• PasswordAuthentication no
• ChallengeResponseAuthentication no

Gerekli/önerilen ek ayarlar (senaryoya göre): - PubkeyAuthentication yes - PermitRootLogin no (root ile doğrudan giriş kapalı olmalı) - KbdInteractiveAuthentication no

Not: Bazı sistemlerde sshd_config içinde Include yönergeleri bulunur. Ayarların hangi dosyada yazıldığı önemli; değişiklik yaptıktan sonra etkin ayarları doğrulamak gerekir.

SSH servisini yeniden yükleme

Tam yeniden başlatmak yerine yapılandırmayı reload etmek çoğu sistemde yeterlidir:

• sudo systemctl reload sshd

Bazı dağıtımlarda servis adı ssh olabilir: - sudo systemctl reload ssh

Ayarların yürürlükte olduğunu doğrulayın

Şunları kontrol edin (örnek komutlar): - sudo sshd -T | grep -E 'passwordauthentication|pubkeyauthentication|challengeresponseauthentication'

Aşağıdaki mantık doğru olmalı: - PasswordAuthentication: no - PubkeyAuthentication: yes

5) Brute force riskini düşürmek için tamamlayıcı güvenlik adımları

Şifre girişini kapatmak tek başına güçlü bir adımdır. Ancak SSH’ye yönelik saldırı yüzeyini daha da küçültmek için aşağıdaki ayarlar doğrudan pratik fayda sağlar.

Uygulanabilir güvenlik ayarları

Aşağıdaki ayarlar çoğu sunucuda uygulanabilir:

• Port değişimi: Varsayılan 22 yerine farklı port (gürültü azaltır, güvenlik kanıtı değildir).
• Kullanıcı kısıtı: Belirli kullanıcıların SSH ile girişini izin verin.
• Fail2ban / benzeri koruma: Çok sayıda başarısız denemeyi otomatik engelleyin.
• 2FA (Mümkünse): SSH üzerinden donanım/uygulama tabanlı 2FA ekleyin.

“Password kapandı ama yine de deneme yapılıyor” durumu

Şifre kapalı olsa bile saldırganlar portu yoklar ve bağlantı kurmaya çalışabilir. Bu normaldir. Asıl ölçüm şudur: - Başarısız deneme loglarında Accepted password gibi kayıtlar görünmemeli. - Kimlik doğrulama yolu “publickey” üzerinden gerçekleşmeli.

6) Net kontrol listesi: Doğru uygulayıp doğru doğrulayın

Aşağıdaki listeyi sırasıyla tamamlayın. Her madde, “beklenen sonucu” doğrular.

Uygulama kontrolü

• [ ] Kendi public key’in sunucunun ~/.ssh/authorized_keys dosyasında.
• [ ] ~/.ssh dizini 700, authorized_keys dosyası 600 izinlerinde.
• [ ] Anahtar ile (key ile) yeni oturum açılabiliyor.
• [ ] PasswordAuthentication no etkin.
• [ ] PubkeyAuthentication yes etkin.
• [ ] Root ile doğrudan giriş kapalı (örn. PermitRootLogin no).

Log doğrulaması (özellikle ilk saatler)

• [ ] Sunucu loglarında “şifre ile giriş kabul edildi” kayıtları yok.
• [ ] Başarılı oturumlarda kimlik doğrulama yöntemi “publickey”.

İleri seviye: Çoklu anahtar ve erişim yedekleme

• [ ] Aynı kullanıcıya ikinci bir admin key ekleyin (yedeği elinizde olsun).
• [ ] Key geri dönüş planı oluşturun: Anahtar iptali gerektiğinde hangisini sileceğinizi bilin.
• [ ] Daima en az iki bağımsız erişim yöntemi planlayın (ör. ayrı kullanıcı + ayrı key).

7) Hosting/kurulum bağımsız pratik senaryolar

Net bir şekilde ayırmak gerekir: Bu rehber VDS/VPS gibi Linux tabanlı sunucularda çalışır. Managed ortamlar (sağlayıcının sunduğu kontrollü erişim) için farklı arayüzler olabilir; ancak anahtar mantığı aynıdır.

Sağlayıcı panelinde SSH erişimi varsa

Bazı sağlayıcı panelleri “authorized key” eklemenize izin verir. Bu durumda: - Panel üzerinden eklediğiniz key gerçekten sunucudaki doğru kullanıcıya gidiyor mu kontrol edin. - Yine de sshd_config tarafında şifreyi kapatma adımını tamamlayın.

Dedicated sunucuda otomasyon varsa

Ansible, Cloud-init veya otomasyonla authorized_keys dağıtımı yapılıyorsa: - sshd_config değişikliği otomasyonla eziliyor mu kontrol edin. - Değişiklikten sonra doğrulama komutuyla etkin ayarı teyit edin.

Sonuç: Bugün uygulayın, ilk saatlerde doğrulayın

Şifre tabanlı SSH girişini devre dışı bırakmak, saldırı yüzeyini doğrudan azaltan net bir güvenlik iyileştirmesidir. Doğru sırayı izleyin: önce SSH key ile erişimi test edin, sonra PasswordAuthentication no ayarını devreye alın ve etkin ayarları loglarla doğrulayın. Aksiyon önerim: Bu değişikliği bir yönetim penceresi açıp canlı bağlantınızı kesmeden, iki ayrı oturum/terminal kullanarak aynı gün içinde tamamlayın; ilk 1-2 saat sunucu loglarını kontrol edin.