SSH hardening, uzaktan yönetim hizmetinin yalnızca gerekli kullanıcı, ağ ve kimlik doğrulama yöntemlerine açık tutulması; zayıf varsayımların kaldırılması; yapılandırmanın test edilmesi ve olayların izlenmesi sürecidir. OpenSSH güvenliği tek bir “güvenli sshd_config” dosyasından ibaret değildir: anahtar yaşam döngüsü, ayrıcalık ayrımı, güvenlik duvarı, MFA, günlükler ve geri dönüş planı birlikte çalışmalıdır.

Bu rehber Linux sunuculardaki OpenSSH sunucu bileşenine odaklanır. Örnekler dağıtıma göre küçük farklılıklar gösterebilir. Her değişiklikten önce mevcut oturumu açık tutun, ikinci bir yönetim oturumuyla test edin ve sshd -t doğrulaması başarısızken hizmeti yeniden yüklemeyin.

SSH saldırı yüzeyi nasıl oluşur?

İnternete açık TCP/22 servisi birkaç dakika içinde parola denemeleri, kullanıcı adı taraması ve bilinen istemci/sunucu açıklarını hedefleyen otomatik trafik almaya başlayabilir. Risk yalnızca brute force değildir:


  • Zayıf, yeniden kullanılmış veya sızmış parolalar
  • Korumasız özel anahtarlar ve paylaşılan yönetici anahtarları
  • Gereksiz root girişi ve geniş sudo yetkileri
  • Eski algoritmalar veya güncellenmeyen OpenSSH paketleri
  • Agent forwarding üzerinden anahtar aracısının kötüye kullanılması
  • TCP, Unix socket veya X11 yönlendirmesiyle iç ağa sıçrama
  • Yanlış Match blokları ve etkisiz kaldığı fark edilmeyen sshd_config satırları
  • Aşırı bağlantı ve kimlik doğrulama denemeleriyle kaynak tüketimi



SSH portunu 22'den farklı bir değere taşımak otomatik tarama gürültüsünü azaltabilir; ancak kimlik doğrulama açığını kapatmaz, güçlü erişim kontrolü sağlamaz ve hardening yerine geçmez.

Önce etkin yapılandırmayı görün

OpenSSH bir ana yapılandırma dosyası ile Include üzerinden eklenen drop-in dosyalarını birlikte okuyabilir. Dağıtıma bağlı olarak ana yol /etc/ssh/sshd_config, ek dosyalar ise /etc/ssh/sshd_config.d/*.conf olabilir.

CODE TERMINAL
sudo sshd -t
sudo sshd -T | less
sudo sshd -T -C user=admin,host=sunucu.example,addr=198.51.100.20


sshd -t sözdizimi ve anahtar dosyaları gibi temel hataları denetler. sshd -T etkin yapılandırmayı yazar. -C ile kullanıcı, hedef host ve kaynak adres koşulu verilerek Match blokları sonrasında hangi ayarların uygulanacağı görülebilir.

OpenSSH birçok anahtar sözcük için elde ettiği ilk değeri kullanır. Include sırası ve dağıtımın sağladığı varsayılan dosyalar bu nedenle önemlidir. Yalnızca eklediğiniz satırı görmek, etkin değerin değiştiğini kanıtlamaz; sshd -T çıktısını doğrulayın.

Anahtar tabanlı kimlik doğrulama

Modern istemcilerde Ed25519 anahtarı üretmek için:

CODE TERMINAL
ssh-keygen -t ed25519 -a 64 -f ~/.ssh/id_ed25519 -C "admin@sunucu-2026"


-a seçeneği, özel anahtar parolasının kaba kuvvetle çözülmesini zorlaştıran KDF tur sayısını yükseltir. Özel anahtar için güçlü ve benzersiz parola kullanın. Otomasyon anahtarlarında parola kullanılamıyorsa anahtarı yalnızca gerekli komut, kaynak ağ ve hedef hesapla sınırlandırın; dosya erişimini servis hesabına özel tutun.

Genel anahtarı güvenli bir mevcut kanal üzerinden sunucuya ekleyin:

CODE TERMINAL
ssh-copy-id -i ~/.ssh/id_ed25519.pub [email protected]


Elle kurulumda ~/.ssh dizini genellikle 700, authorized_keys dosyası 600 izinli ve her ikisi de ilgili kullanıcıya ait olmalıdır:

CODE TERMINAL
chmod 700 ~/.ssh
chmod 600 ~/.ssh/authorized_keys
chown -R "$USER:$USER" ~/.ssh


Dosya izinleri dağıtım, dosya sistemi ACL'leri ve SELinux bağlamıyla birlikte değerlendirilmelidir. SELinux kullanılan sistemlerde yanlış bağlamı düzeltmek için dağıtımın restorecon mekanizmasını kullanın; güvenlik denetimini kapatmayın.

authorized_keys seçenekleriyle anahtarı sınırlandırma

Bir anahtarın başına seçenek ekleyerek kullanım alanını daraltabilirsiniz:

CODE TERMINAL
from="198.51.100.0/24",restrict,command="/usr/local/sbin/yedek-al" ssh-ed25519 AAAAC3... backup@job


from= yalnızca belirtilen kaynak adreslerden erişime izin verir. restrict PTY, forwarding ve benzeri yetenekleri topluca sınırlar. command= istemci hangi komutu isterse istesin belirlenen komutu çalıştırır. Yedekleme, dağıtım ve izleme anahtarları için bu kısıtlar, anahtar sızdığında yatay hareket alanını ciddi biçimde azaltır.

Kaynak IP kısıtında NAT, VPN çıkışı, IPv6 ve felaket kurtarma yollarını hesaba katın. Yanlış from kuralı acil erişimi kesebilir; değişikliği ikinci oturumdan doğrulayın.

Önerilen sshd hardening drop-in dosyası

Aşağıdaki başlangıç profili her ortama körlemesine kopyalanmamalıdır. Önce anahtar erişimini ve acil geri dönüş kanalını doğrulayın:

CODE TERMINAL
# /etc/ssh/sshd_config.d/60-hardening.conf
PermitRootLogin no
PubkeyAuthentication yes
PasswordAuthentication no
KbdInteractiveAuthentication no
PermitEmptyPasswords no

AllowGroups ssh-admins
MaxAuthTries 3
LoginGraceTime 30
MaxSessions 3
MaxStartups 10:30:60

X11Forwarding no
AllowAgentForwarding no
AllowTcpForwarding no
PermitTunnel no
GatewayPorts no
PermitUserEnvironment no

LogLevel VERBOSE
ClientAliveInterval 300
ClientAliveCountMax 2


PermitRootLogin no, doğrudan root oturumunu kapatır. Yöneticiler kişisel hesapla giriş yapıp denetlenebilir sudo kullanmalıdır. Bazı kurtarma veya otomasyon düzenlerinde root anahtarına ihtiyaç varsa prohibit-password ve authorized_keys kısıtları değerlendirilir; genel internet erişiminde doğrudan root girişi yine en aza indirilmelidir.

PasswordAuthentication no yalnızca bütün gerekli kullanıcıların çalışan anahtarı, MFA yolu veya bant dışı konsolu doğrulandıktan sonra etkinleştirilmelidir. KbdInteractiveAuthentication no klavye etkileşimli parola/PAM akışlarını kapatabilir. MFA bu yöntem üzerinden uygulanıyorsa kapatmak yerine AuthenticationMethods ile doğru kombinasyonu kurun.

Kullanıcı ve grup erişimini sınırlandırma

SSH hizmetine bütün yerel hesapların bağlanması gerekmez. Ayrı bir grup kullanın:

CODE TERMINAL
sudo groupadd --system ssh-admins
sudo usermod -aG ssh-admins admin


Ardından AllowGroups ssh-admins ile yalnızca grup üyelerine izin verin. AllowUsers, DenyUsers ve DenyGroups daha ayrıntılı kurallar sağlar; ancak karmaşık allow/deny birleşimleri yönetim hatasına açıktır. Yetki kaynağını tek bir grup, merkezi dizin veya erişim aracında tutmak denetimi kolaylaştırır.

Paylaşılan “admin” hesapları yerine kişisel hesap kullanın. sudo kurallarını görev bazında sınırlandırın ve oturum açan kimlik ile ayrıcalıklı komutu günlüklerde ilişkilendirin.

MFA ve AuthenticationMethods

Yüksek riskli yönetim sistemlerinde yalnızca anahtar sahipliği yeterli olmayabilir. OpenSSH, birden çok yöntemi zorunlu kılmak için AuthenticationMethods kullanabilir:

CODE TERMINAL
AuthenticationMethods publickey,keyboard-interactive:pam


Bu örnek önce geçerli genel anahtar, sonra PAM üzerinden ikinci doğrulama ister. Yapılandırma, kullanılan MFA modülüne ve dağıtıma bağlıdır. KbdInteractiveAuthentication ile UsePAM ayarlarını MFA sağlayıcısının belgesiyle eşleştirin.

MFA devreye alınırken acil erişim hesapları, saat senkronizasyonu, MFA hizmeti kesintisi ve kurtarma kodları için yazılı prosedür oluşturun. Acil hesapları gündelik kullanımda kapalı veya kasada tutun; her kullanımı alarm üretmeli ve sonrasında kimlik bilgisi döndürülmelidir.

Forwarding özelliklerini kapatmak neden önemlidir?

SSH yalnızca kabuk erişimi değil, güçlü bir tünelleme aracıdır. Bir sunucu ele geçirildiğinde forwarding özellikleri saldırgana iç servisleri dışarı taşıma veya güvenilen ağlara sıçrama imkânı verebilir.

AyarRiskYaklaşım
AllowAgentForwardingUzak root veya süreç, açık oturum süresince aracıyı kullanabilirGerekmiyorsa no; sıçrama sunucusunda kısa ömürlü anahtar/sertifika tercih edin
AllowTcpForwardingİç TCP servislerine tünel açılabilirGerekmiyorsa no; gerekiyorsa kullanıcı/Match bloğuyla local veya remote sınırı
GatewayPortsUzak yönlendirme başka ağlardan erişilebilir hâle gelebilirVarsayılan no değerini koruyun
X11ForwardingGrafik protokolü ve istemci yüzeyi açılırSunucularda genellikle no
PermitTunnelTUN cihazıyla ağ katmanı tüneli kurulabilirGerekmiyorsa no
PermitOpen / PermitListenForwarding hedefi geniş kalabilirİzinli host:port listesini açıkça tanımlayın


Bazı geliştirici ve bastion iş akışları forwarding gerektirir. Global olarak açmak yerine Match User veya Match Group bloklarıyla yalnızca gerekli hesap ve hedeflere izin verin.

Match bloklarıyla rol bazlı politika

Örneğin yedekleme hesabını yalnızca belirli kaynaktan ve zorunlu komutla sınırlandırabilirsiniz:

CODE TERMINAL
Match User backup Address 198.51.100.0/24
    AuthenticationMethods publickey
    ForceCommand /usr/local/sbin/yedek-al
    DisableForwarding yes
    PermitTTY no


Match bloğu dosyanın kalanına etki eder. Sonraki genel ayarlara dönmek için desteklenen sürümlerde Match all kullanın veya blokları dosyanın sonunda tutun. Etkin sonucu sshd -T -C ile test etmeden yeniden yüklemeyin.

Algoritma ve kriptografi ayarları

Güncel OpenSSH sürümleri güvenli varsayılanları düzenli olarak yeniler. İnternetten alınmış uzun bir Ciphers, MACs veya KexAlgorithms listesi zamanla desteklenmeyen, zayıf ya da gereksiz bir sabit yapılandırmaya dönüşebilir. Öncelik:

[OLIST]
[*]Dağıtımın desteklenen OpenSSH paketini güncel tutmak.
[*]
CODE TERMINAL
sshd -T | grep -E 'ciphers|macs|kexalgorithms|hostkeyalgorithms'
ile etkin kümeyi görmek.
[*]Eski istemci bağımlılığını envanterlemek ve düzeltmek.
[*]Yalnızca belgelenmiş uyumluluk veya politika gereksinimi varsa algoritma listesini daraltmak.
[/OLIST]

Yeni anahtarlarda Ed25519 yaygın ve güçlü bir tercihtir. Kurumsal uyumluluk veya FIPS gereksinimi Ed25519 kullanımını sınırlayabilir; bu durumda modern RSA anahtarı ve rsa-sha2-256/rsa-sha2-512 imza algoritmaları değerlendirilir. Eski ssh-rsa adı SHA-1 imzasını ifade eder; RSA anahtar türünün tamamını değil.

Ağ katmanında erişim azaltma

SSH'yi mümkünse doğrudan internete açmak yerine kurumsal VPN, Zero Trust erişim aracısı veya sıkı yönetilen bastion üzerinden sunun. Güvenlik duvarında yalnızca yönetim ağlarına izin verin. Bulut güvenlik grubu, yerel nftables/firewalld ve kenar güvenlik duvarındaki kuralların birbirini gerçekten daralttığını doğrulayın.

Fail2ban veya benzeri hız sınırlama araçları parola denemesi ve günlük gürültüsünü azaltabilir; fakat sızmış anahtarı, yanlış yetkiyi veya OpenSSH açığını engellemez. Ana savunma; güncel paket, anahtar/MFA, allowlist ve en az ayrıcalıktır.

Bağlantı ve kaynak tüketimi sınırları

LoginGraceTime kimlik doğrulaması tamamlanmamış bağlantının ne kadar açık kalacağını, MaxAuthTries oturum başına deneme sayısını, MaxStartups ise eş zamanlı doğrulanmamış bağlantıların olasılıklı olarak düşürülmesini yönetir. Değerleri çok sert belirlemek NAT arkasındaki meşru yönetici veya otomasyonları etkileyebilir.

Yeni OpenSSH sürümlerinde bulunan PerSourceMaxStartups ve PerSourcePenalties gibi kaynak başına kontroller, dağıtımınız destekliyorsa kötü davranan kaynakları sınırlamaya yardımcı olabilir. Kullanılabilir seçenekleri kurulu sürümün sshd_config(5) man sayfasından doğrulayın.

Günlükleme ve tehdit avcılığı

LogLevel VERBOSE, başarılı genel anahtar girişlerinde anahtar parmak izi gibi olay incelemesinde yararlı ayrıntılar sağlar. DEBUG düzeyi ise yüksek hacim ve hassas ayrıntı riski nedeniyle sürekli üretim kullanımı için uygun değildir.

Dağıtıma göre günlükleri inceleyin:

CODE TERMINAL
sudo journalctl -u ssh --since "24 hours ago"
sudo journalctl -u sshd --since "24 hours ago"
sudo tail -f /var/log/auth.log
sudo tail -f /var/log/secure


Şu davranışları merkezi SIEM'de alarm ve korelasyon kuralına bağlayın:


  • Daha önce görülmeyen ülke, ASN, kaynak IP veya saat diliminden başarılı giriş
  • Aynı hesaba kısa sürede çok sayıda başarısız deneme ve ardından başarı
  • Root veya hizmet hesabıyla etkileşimli oturum
  • Yeni authorized_keys satırı, değişen dosya sahibi veya izin
  • sshd_config, drop-in dosyaları, PAM modülleri ya da sudoers değişikliği
  • Yeni SSH host anahtarı veya beklenmeyen host key parmak izi
  • Uzun süre açık kalan tünel, forwarding ve olağan dışı iç hedef bağlantıları
  • Başarılı girişten hemen sonra ayrıcalık yükseltme, arşivleme veya dış bağlantı



authorized_keys ve sshd yapılandırma dosyalarını dosya bütünlüğü izlemesine alın. Günlükleri aynı sunucuda bırakmak yerine merkezi, erişimi sınırlı ve değiştirilemez depoya aktarın.

Güvenli değişiklik ve geri dönüş planı

[OLIST]
[*]Bulut konsolu, KVM/IPMI veya fiziksel konsol gibi bant dışı erişimi doğrulayın.
[*]Mevcut yönetici oturumunu kapatmayın.
[*]Yeni anahtarı ikinci terminalde test edin.
[*]Drop-in dosyasını oluşturun; ana dosyayı gereksiz yere değiştirmeyin.
[*]
CODE TERMINAL
sudo sshd -t
ile sözdizimini doğrulayın.
[*]
CODE TERMINAL
sudo sshd -T -C user=admin,host=sunucu.example,addr=YONETIM_IP
ile etkin politikayı inceleyin.
[*]Hizmeti dağıtıma göre reload edin; çalışan bağlantıları sonlandıran restart işlemini yalnızca gerektiğinde kullanın.
[*]İkinci terminalden anahtar/MFA, sudo ve gerekli forwarding işlevlerini sınayın.
[*]Başarısız ve başarılı denemelerin merkezi günlüğe ulaştığını doğrulayın.
[*]Ancak tüm kontrollerden sonra parola girişini kapatın.
[/OLIST]

Yapılandırma yönetimi kullanıyorsanız önce küçük bir canary sunucu grubuna dağıtın. Otomatik işin sshd -t başarısızlığında dosyayı etkinleştirmemesini ve geri dönüş paketini hazır tutmasını sağlayın.

Sık yapılan hatalar


  • Anahtar girişini test etmeden PasswordAuthentication no yapmak
  • Tek bir paylaşılan özel anahtarı bütün yöneticilere ve sunuculara kopyalamak
  • Özel anahtarı parolasız biçimde dizüstü bilgisayar veya CI günlüğünde bırakmak
  • Yalnızca SSH portunu değiştirip servisi güvenli sanmak
  • AllowAgentForwarding ve AllowTcpForwarding'i ihtiyaç analizi olmadan açık bırakmak
  • Eski istemci için tüm sunucuda zayıf algoritma etkinleştirmek
  • MFA kullanırken KbdInteractiveAuthentication veya PAM akışını yanlışlıkla kapatmak
  • Match bloğunun dosyanın geri kalanına etkisini gözden kaçırmak
  • sshd -t başarılı olduğu hâlde etkin Match politikasını sshd -T -C ile doğrulamamak
  • EDR veya SIEM olmadan yalnızca fail2ban'a güvenmek



Sonuç

Güvenli OpenSSH sunucusu; çalışan anahtar tabanlı erişim, kapalı parola ve doğrudan root girişi, kullanıcı/grup allowlist'i, ihtiyaç dışı forwarding özelliklerinin devre dışı olması, güncel kriptografik varsayımlar ve merkezi günlükleme üzerine kurulmalıdır. Yüksek riskli sistemlerde anahtara MFA, VPN/Zero Trust erişimi ve kısa ömürlü SSH sertifikaları eklenmelidir.

En kritik adım, hardening değişikliğini güvenli biçimde uygulamaktır: bant dışı erişim hazır olmalı, mevcut oturum açık tutulmalı, sshd -t ve sshd -T -C sonuçları kontrol edilmeli, ikinci oturum doğrulanmalı ve parola ancak bundan sonra kapatılmalıdır.

Kaynaklar

TR Siber Ekibi Yazar · X
Kaynak bağlantısı ← Ana sayfaya dön