Selamlar,
Tor çıkış rölelerinin SSH'yi yönlendirdiği Ekim 2026 olayında kurbanların gördüğü ilk şey klasik OpenSSH uyarısıydı: REMOTE HOST IDENTIFICATION HAS CHANGED. Birçok kişi bu uyarıyı "sunucu yeniden kurulmuş olmalı" diye yok sayıyor. Bu yazıda uyarının ne anlama geldiğini, OpenSSH yapılandırma seçeneklerini ve kendi labınızda güvenli bir alışkanlık nasıl kurulacağını anlatıyorum.
Konuda anlatılacaklar
- Uyarı teknik olarak ne diyor?
- StrictHostKeyChecking seçenekleri
- Meşru değişim ile MITM'i ayırt etmek
- Lab alıştırması
Uyarı ne diyor?
OpenSSH, bağlandığınız sunucunun sunduğu host anahtarını ~/.ssh/known_hosts (ve sistem genelindeki known_hosts) ile karşılaştırır. Anahtar değiştiyse iki olasılık vardır: sunucu gerçekten yeniden kurulmuş / anahtar döndürülmüştür, ya da aradaki biri size başka bir sunucu sunuyordur (MITM). Tor olayında ikinci senaryo gerçekleşiyordu: çıkış rölesi sizi saldırganın ara sunucusuna yönlendiriyordu ve o sunucu farklı bir host anahtarı sunuyordu.
StrictHostKeyChecking
OpenBSD ssh_config kılavuzuna göre:
- yes: Yeni host anahtarlarını otomatik eklemez; değişen anahtarlara bağlanmayı reddeder. En yüksek MITM koruması.
- accept-new: Yeni anahtarları otomatik ekler ama değişen anahtarlara izin vermez.
- ask (varsayılan): Yeni anahtarları kullanıcı onayından sonra ekler; değişen anahtarlara bağlanmayı reddeder.
- no / off: Yeni anahtarları otomatik ekler ve değişen anahtarlara da (bazı kısıtlarla) izin verir. Kolaydır, tehlikelidir.
Meşru değişim ile MITM'i ayırt etmek
- Uyarıyı görünce bağlantıyı kesin; "yes" yazmayın.
- Sunucu sahibine / panelinize / out-of-band bir kanala sorun: Anahtar yakın zamanda döndürüldü mü?
- Beklenen parmak izini güvenli bir kaynaktan alın (bulut konsolu, önceki yedek, fiziksel konsol).
- Eşleşiyorsa known_hosts'taki eski satırı güncelleyin. Eşleşmiyorsa MITM veya yanlış sunucu varsayın.
Kod:
# Parmak izi hesaplama (kendi makinenizden)
ssh-keyscan -t ed25519,ecdsa,rsa hedef.ornek 2>/dev/null | ssh-keygen -lf -
# known_hosts'tan eski kaydi silmek (yalnizca meşru degisim dogrulandiktan sonra)
ssh-keygen -R hedef.ornek
# Guvenli istemci varsayilanlari
cat >> ~/.ssh/config <<'E'
Host *
StrictHostKeyChecking accept-new
UpdateHostKeys yes
PasswordAuthentication no
HashKnownHosts yes
ELab alıştırması
İki VM'niz varsa: B'nin host anahtarını yeniden oluşturun (ssh-keygen -A), A'dan bağlanın, uyarıyı görün, B'nin gerçek parmak izini konsoldan doğrulayın, sonra known_hosts'u güncelleyin. Bu alıştırmayı bir kez bilinçli yapmak, üretimde uyarıyı refleksle yok saymayı azaltır.
Sizin ekipte host anahtarı değişince prosedür nedir? Yazılı bir runbook'unuz var mı?
Yasal uyarı
Bu yazı bilgilendirme ve savunma amaçlıdır. Anlatılan kontrolleri yalnızca kendi sistemlerinizde veya yazılı izinle yapın. İzinsiz erişim, tarama ve sömürü girişimleri TCK 243-245 kapsamında suçtur. TurkTeam white-hat bir topluluktur; çalıntı veri, hesap, combo/log paylaşımı ve hack hizmeti talepleri forum kurallarına aykırıdır.
Kaynaklar