SSH Sertleştirme: Anahtar, İki Faktörlü Doğrulama ve fail2ban

Kısa cevap: SSH sertleştirme, uzak erişimi parola tahminine kapatıp kimlik doğrulamayı anahtara ve denetlenebilir bir yetki modeline bağlama işlemidir. Çekirdeği üç maddedir: PasswordAuthentication no, Ed25519 anahtar zorunluluğu, PermitRootLogin no. Üstüne katman olarak iki faktörlü doğrulama, kaynak IP kısıtı, sıçrama sunucusu ve on sunucuyu geçen ortamlarda SSH sertifika otoritesi gelir.

SSH saldırıları pratikte nasıl görünüyor?

Sertleştirmeye karar vermeden önce tehdidin gerçek şeklini bilmek gerekir. İşlettiğim honeypot ağında SSH’a gelen trafik neredeyse tamamen otomatiktir ve üç kalıba oturur:

• Kullanıcı adı sözlüğü: root ezici çoğunlukla ilk denenen addır; ardından admin, ubuntu, test, oracle, postgres, git gibi servis adları gelir. Kişiye özel kullanıcı adları neredeyse hiç denenmez.
• Parola sözlüğü: Sızdırılmış parola listelerinden beslenen kısa denemeler. Aynı IP genellikle birkaç deneme yapıp başka bir IP’ye devreder; bu, klasik “aynı IP’den bin deneme” kalıbının artık istisna olduğu anlamına gelir.
• Dağıtık deneme: Denemeler yüzlerce farklı IP’ye yayılır. Tek IP başına deneme sayısı düşük kaldığı için eşik tabanlı engelleme kolayca ıskalar.

Buradan iki sonuç çıkar. Birincisi, eşik tabanlı engelleme (fail2ban) tek başına yeterli bir savunma değildir; dağıtık denemeyi yakalamaz. İkincisi, parola girişi kapalıysa bu trafiğin tamamı anlamsızlaşır: denenecek bir parola kalmaz. Bu yüzden sıralamada anahtar tabanlı kimlik doğrulama her zaman birinci, engelleme araçları ikincidir.

SSH anahtarı nasıl üretilir ve nasıl saklanır?

Anahtar çifti kendi makinenizde üretilir; özel anahtar hiçbir koşulda sunucuya kopyalanmaz, e-postayla gönderilmez, depoya işlenmez.

# Önerilen: Ed25519 (kısa, hızlı, güçlü)
ssh-keygen -t ed25519 -C "erdem@laptop-2026"

# Eski sistemlerle uyumluluk gerekiyorsa RSA 4096
ssh-keygen -t rsa -b 4096 -C "erdem@laptop-2026"

Üç kural:

1. Özel anahtara mutlaka bir parola koyun. Anahtar dosyası çalındığında tek savunma budur. Parola girmeyi her seferinde tekrarlamamak için ssh-agent kullanılır; macOS’ta anahtar Keychain’e eklenebilir.
2. Her cihaz için ayrı anahtar üretin. Dizüstü, iş masaüstü ve CI sunucusu farklı anahtarlar kullanmalıdır; bir cihaz kaybolduğunda yalnız o anahtarı iptal edersiniz.
3. Yoruma anlamlı bir etiket yazın (-C parametresi). authorized_keys dosyasında altı ay sonra hangi satırın kime ait olduğunu yalnız bu etiket söyler.

Anahtarı sunucuya taşımanın en güvenli yolu ssh-copy-id, çünkü izinleri de doğru ayarlar:

ssh-copy-id -i ~/.ssh/id_ed25519.pub erdem@sunucu

İzinler yanlışsa OpenSSH anahtarı sessizce reddeder ve parola sormaya devam eder. Doğru izinler: ~/.ssh dizini 700, authorized_keys dosyası 600, ev dizini başkalarına yazılabilir olmamalı.

sshd_config nasıl sertleştirilir?

Aşağıdaki blok, üretim sunucularında kullandığım çekirdek yapılandırmadır. Modern dağıtımlarda ana dosyayı düzenlemek yerine /etc/ssh/sshd_config.d/99-hardening.conf gibi ayrı bir dosya oluşturmak daha temizdir.

# Kimlik doğrulama
PermitRootLogin no
PasswordAuthentication no
KbdInteractiveAuthentication no
PubkeyAuthentication yes
PermitEmptyPasswords no

# Kim girebilir (yalnız listedeki kullanıcılar)
AllowUsers erdem deploy

# Oturum sınırları
MaxAuthTries 3
LoginGraceTime 30
ClientAliveInterval 300
ClientAliveCountMax 2

# Gereksiz özellikleri kapat
X11Forwarding no
AllowAgentForwarding no
PermitTunnel no

Birkaç ayrıntı açıklamayı hak ediyor:

• AllowUsers beyaz liste kurar: listede olmayan hiçbir kullanıcı, anahtarı doğru olsa bile giremez. Yeni bir kullanıcı eklediğinizde bu satırı güncellemeyi unutmak, “anahtarı koydum ama giremiyorum” sorununun sık sebebidir.
• AllowAgentForwarding no önemlidir: agent yönlendirme, bağlandığınız sunucunun root’unun sizin anahtar agent’ınızı kullanabilmesi anlamına gelir. Güvenmediğiniz bir sunucuya agent yönlendirmeyle bağlanmak, anahtarınızı ödünç vermektir. Sıçrama gerekiyorsa yönlendirme yerine ProxyJump kullanın.
• MaxAuthTries 3 tek bağlantıda denenecek kimlik sayısını sınırlar. Çok sayıda anahtarınız varsa istemci tarafında yanlış anahtarları denemeyi engellemek için IdentitiesOnly yes kullanın.

Uygulamadan önce sözdizimini test edin, sonra efektif yapılandırmayı doğrulayın:

sudo sshd -t                 # sözdizimi hatası var mı
sudo systemctl reload ssh

# Dosyada ne yazdığı değil, sunucunun ne uyguladığı:
sudo sshd -T | grep -Ei "permitrootlogin|passwordauth|allowusers|maxauthtries"

sshd -T alışkanlığı bu yazının en pratik tavsiyesidir. Bulut sağlayıcıları sıklıkla /etc/ssh/sshd_config.d/ altına kendi dosyalarını koyar ve bunlar sizin ayarınızı ezebilir; dosyayı düzenleyip “kapattım” sanmak yaygın bir yanılgıdır.

Kaynak kısıtı: erişimi nereden kabul ediyorsunuz?

Anahtar zorunluluğunun üstüne eklenecek en etkili katman, SSH portunu herkese açık bırakmamaktır. Üç seçenek var, güçten zayıfa:

Yöntem	Güç	Maliyet	Uygun olduğu yer
SSH yalnız VPN üzerinden	En yüksek	VPN altyapısı gerekir	Üretim, çok sunuculu ortam
Firewall’da kaynak IP kısıtı	Yüksek	Sabit IP gerekir	Ofis veya sabit IP’li yönetici
Sıçrama sunucusu (bastion)	Yüksek	Bir ek sunucu	Ekip erişimi, denetim gereksinimi
Port değiştirme	Düşük (gürültü azaltır)	Sıfır	Her yerde, ek olarak

VPN yolu tercih ediliyorsa ağ tarafındaki kurulum için WireGuard site-to-site veya CGNAT arkasındaysanız ZeroTier ile uzak erişim yazılarına bakın. Firewall tarafındaki kural yazımı Linux firewall rehberinde, sunucu ilk kurulumundaki yeri ise VPS ilk 30 dakika listesinde.

Port değiştirmeyi küçümsemeyin ama abartmayın: güvenlik katmanı değildir, log temizleyicidir. 22 dışındaki bir porta taşındığında başarısız giriş kayıtları pratikte sıfıra iner ve geriye kalan tek tük deneme gerçekten dikkat edilmesi gereken şeydir. Gürültünün içinde sinyali görmek, güvenliğin gözden kaçan yarısıdır.

İki faktörlü doğrulama: ne zaman gerçekten gerekli?

Anahtar tabanlı giriş, çalınmış bir anahtar karşısında savunmasızdır. İkinci faktör tam olarak bu senaryoyu kapatır: anahtar dosyasını ele geçiren biri, telefonunuzdaki tek kullanımlık kodu üretemez.

Gerçekten gerekli olduğu yerler: ortak kullanılan sıçrama sunucuları, müşteri verisi barındıran üretim sunucuları, denetime tabi ortamlar ve birden fazla kişinin yönetici erişimi olduğu her sistem. Tek kişilik kişisel bir sunucuda, parola korumalı bir anahtar çoğu durumda yeterlidir; ikinci faktör burada güvenlikten çok sürtünme ekler.

Kurulum (Debian/Ubuntu, TOTP tabanlı):

sudo apt install libpam-google-authenticator

# Erişecek her kullanıcı KENDİ oturumunda çalıştırır:
google-authenticator

Komut bir QR kod ve yedek kodlar üretir. Yedek kodları mutlaka güvenli bir yere kaydedin; telefon kaybolduğunda tek giriş yolunuz onlardır.

PAM tarafında /etc/pam.d/sshd dosyasına ekleyin:

auth required pam_google_authenticator.so

sshd tarafında iki faktörü zorunlu kılın:

KbdInteractiveAuthentication yes
AuthenticationMethods publickey,keyboard-interactive

AuthenticationMethods satırındaki virgül “ve” anlamına gelir: hem anahtar hem kod istenir. Boşlukla ayırmak “veya” olurdu ve amacı bozardı; bu ayrım en sık yapılan yapılandırma hatasıdır.

Kilitlenme sigortası: bu değişikliği yaparken açık bir oturumu kapatmayın, ikinci terminalden giriş yapabildiğinizi doğrulayın ve konsol erişiminizin çalıştığından emin olun. Otomatik dağıtım yapan servis hesaplarını (CI/CD kullanıcıları) ikinci faktörden muaf tutmanız gerekir; bunu Match User deploy bloğuyla yaparsınız:

Match User deploy
    AuthenticationMethods publickey

fail2ban: ne yapar, ne yapmaz?

fail2ban logları izler, eşiği aşan kaynak IP’yi geçici olarak firewall’da engeller. Parola girişi kapalı bir sunucuda SSH açısından koruyucu değeri sınırlıdır, çünkü kırılacak bir parola yoktur. Buna rağmen kurmaya değer: log gürültüsünü azaltır ve parola kabul eden diğer servisleri korur (web uygulaması giriş formları, posta sunucusu, VPN).

/etc/fail2ban/jail.local:

[DEFAULT]
bantime  = 1h
findtime = 10m
maxretry = 5
# Kendinizi engellememek için yönetim IP'lerinizi muaf tutun
ignoreip = 127.0.0.1/8 203.0.113.10

[sshd]
enabled = true

Doğrulama ve gözlem:

sudo fail2ban-client status sshd

Sınırını bilin: dağıtık denemelerde her IP eşiğin altında kaldığı için fail2ban devreye girmez. Bu bir kusur değil, aracın tasarımıdır. Gerçek koruma anahtar zorunluluğu ve kaynak kısıtından gelir; fail2ban onların yerine değil, yanına konur.

Çok sayıda sunucuda SSH erişimi nasıl yönetilir?

Birkaç sunucuda authorized_keys dosyalarını elle yönetmek sorun değildir. Sunucu sayısı arttığında iki gerçek problem çıkar: yeni bir yönetici eklemek her makineye dokunmayı gerektirir ve ayrılan bir çalışanın anahtarını her yerden silmek kolayca eksik yapılır.

İki ölçeklenebilir çözüm var:

Sıçrama sunucusu (bastion): Tüm SSH trafiği tek bir sertleştirilmiş sunucudan geçer; arkadaki makineler yalnız o sunucudan bağlantı kabul eder. Erişim iptali tek noktadan yapılır ve tüm oturumlar tek yerde denetlenir. İstemci tarafında ~/.ssh/config ile şeffaflaşır:

Host bastion
    HostName bastion.ornek.com
    User erdem

Host ic-*
    ProxyJump bastion
    User erdem

Bundan sonra ssh ic-web01 komutu otomatik olarak sıçrama sunucusu üzerinden geçer. ProxyJump, agent yönlendirmeye göre çok daha güvenlidir: anahtarınız aradaki sunucuya hiç uğramaz.

SSH sertifika otoritesi: Bir imzalama anahtarı oluşturur, kullanıcı anahtarlarını kısa ömürlü sertifikalarla imzalarsınız. Sunucularda tek bir ayar bulunur: bu otoriteye güven.

# Otorite anahtarını üret (çok iyi korunmalı, tercihen çevrimdışı)
ssh-keygen -t ed25519 -f ssh_user_ca -C "SSH kullanici CA"

# Kullanıcı anahtarını 8 saatlik sertifikayla imzala
ssh-keygen -s ssh_user_ca -I "erdem-2026-07-25" -n erdem -V +8h ~/.ssh/id_ed25519.pub

Sunucu tarafında sshd_config içinde:

TrustedUserCAKeys /etc/ssh/ssh_user_ca.pub

Bu modelin en büyük getirisi şudur: erişimi iptal etmek için hiçbir sunucuya dokunmanız gerekmez. Sertifikanın süresi dolar ve erişim kendiliğinden kapanır; ayrılan çalışan için yeni sertifika imzalamazsınız, bu kadar. On sunucuyu geçen her ortamda bu yapıya geçmeye değer.

Sertleştirme kontrol listesi

• Ed25519 anahtar üretildi, özel anahtar parola korumalı
• Her cihaz için ayrı anahtar, -C ile etiketlenmiş
• authorized_keys izinleri 700/600, ev dizini grup yazılabilir değil
• PermitRootLogin no, PasswordAuthentication no (sshd -T ile doğrulandı)
• AllowUsers beyaz listesi tanımlı
• AllowAgentForwarding no, sıçrama için ProxyJump kullanılıyor
• SSH erişimi VPN, kaynak IP kısıtı veya bastion arkasında
• Yönetici erişimlerinde ikinci faktör (paylaşımlı/üretim sunucularında)
• TOTP yedek kodları güvenli yerde saklanıyor
• fail2ban kurulu, ignoreip yönetim IP’lerini içeriyor
• İkinci erişim yolu (konsol/IPMI veya ikinci yönetici anahtarı) doğrulandı
• On sunucuyu geçen ortamda sertifika otoritesi veya bastion modeli kurulu

Bu liste kapandığında SSH katmanı, çoğu kurulumun ihtiyacının üzerinde bir seviyeye gelir. Bir sonraki katman ağ tarafıdır: Linux firewall rehberi ile hangi trafiğin sunucuya ulaşacağını, sunucu izleme ile de olağandışı erişim denemelerinden nasıl haberdar olacağınızı belirlersiniz. Tüm katmanların sırası ve birbirine bağlanışı Linux sunucu yönetimi yol haritasında.

Erişim yönetimini kurumsal ölçekte denetlenebilir kurmak gerekiyorsa siber güvenlik hizmetleri sayfasında bu işi nasıl yürüttüğümü anlattım.

Kaynaklar

• sshd_config manual page (AuthenticationMethods, Match blokları, TrustedUserCAKeys)
• ssh-keygen manual page (anahtar üretimi ve sertifika imzalama)
• RFC 8032: EdDSA (Ed25519 imza algoritması tanımı)