Linux SSH Güvenliği: Tehdit Modeli, Sertleştirme ve Fail2Ban

Linux SSH Güvenliği: Tehdit Modeli, sshd_config Sertleştirmesi ve Fail2Ban Derinlemesine

Yeni VDS'inizin public IP'si tahsis edildiği dakikadan itibaren saatte ortalama 200-1500 SSH bağlantı denemesi alır. Çoğu otomatik botnet, küçük bir kısmı hedefli credential stuffing, çok küçük bir kısmı ise ileri tehdit aktörlerinin yavaş tarayıcı oturumlarıdır. SSH güvenliği bu yüzden tek bir komutla bitmez; tehdit modelini anlamak, sshd_config'i sertleştirmek, fail2ban gibi reaktif savunmayı doğru kalibre etmek ve defense-in-depth zincirini tamamlamak gerekir. Bu rehber, Buyukweb VDS müşterilerine yönelik Linux SSH güvenliğini katman katman ele alır.

Buyukweb perspektifi: VDS paketleri Bursa Pendc Tier 3 datacenter'da unmanaged teslim edilir ve KVM konsol erişimi garantidir. SSH güvenlik yapılandırmasında kendinizi kilitlerseniz panel üzerinden KVM konsola düşüp /etc/ssh/sshd_config düzenleyerek geri dönebilirsiniz. Paylaşımlı cPanel hosting'te ise SSH chroot kafesi ve kısıtlı kabuk uygulanır; bu rehberin sertleştirme adımlarının çoğu paylaşımlı paketlerde gereksizdir, çünkü hosting yöneticisi bu katmanı sizin için yapılandırmıştır.

İlgili rehberlerimiz: SSH bağlantı kurma temelleri, Linux SSH komutları, SSH anahtar tabanlı kimlik doğrulama. Bu yazı bunlardan ayrı odak taşır: tehdit modeli + sertleştirme + reaktif savunma.

SSH Tehdit Modeli: Neye Karşı Savunuyoruz?

Sertleştirme kararları tehditleri sınıflandırınca anlam kazanır. Public-facing Linux sunucusunda SSH'a yönelen tehditleri beş gruba ayırabiliriz:

1. Botnet Brute-Force ve Credential Stuffing

En yaygın saldırı sınıfı. Mirai, Gafgyt ve son dönemde IoT cihazlarından örülmüş yeni varyantlar internetin tamamını sürekli tarar. Hedef belirli bir sunucu değil, "açık 22 + zayıf parola" eşleşmesidir. Credential stuffing ise daha akıllıca: önceki sızıntılarda yayılmış e-posta/parola çiftlerini SSH üzerinde dener. root:root, root:123456, admin:admin, ubuntu:ubuntu denemeleri bu sınıfa girer. Çözüm: parola girişini kapatmak ve botnetlerin saatte 1000+ girişimle devam etmesini fail2ban ile yavaşlatmak.

2. Hedefli Saldırı (Targeted Reconnaissance)

Şirketinizi tanıyan saldırgan public bilgi kaynaklarından (Shodan, Censys, GitHub leak, LinkedIn) sunucu IP'lerini, kullanıcı isimlerini ve potansiyel parolaları toplar. Hedefli saldırı, yavaş ve dağıtık IP'lerden gelir; klasik fail2ban filter'ları kolayca yakalayamaz çünkü tek IP başına 2-3 deneme yapılır. Çözüm: recidive jail (uzun süreli ban), GeoIP kısıtlama, AllowGroups ile beyaz liste.

3. Supply-Chain ve Anahtar Sızıntısı

Geliştiricinin laptop'undan çalınan SSH key, GitHub'a yanlışlıkla commit edilen private key, zayıf passphrase ile bırakılmış id_rsa dosyaları. 2024 sonunda XZ Utils backdoor (CVE-2024-3094) olayında olduğu gibi tedarik zinciri kompromisleri OpenSSH'ı dolaylı tehdit eder. Çözüm: ssh-agent ile passphrase rotasyonu, authorized_keys denetimi (from= ve command= kısıtları), kısa ömürlü sertifika tabanlı kimlik doğrulama (SSH CA).

4. Zero-Day ve Kernel-Level Açıklar

OpenSSH'ın geçmişinde Roaming bug (CVE-2016-0777) ve regreSSHion (CVE-2024-6387) gibi uzaktan kod çalıştırma açıkları görüldü. Bu sınıf saldırılara karşı yapılacak en güçlü adım: paket yöneticisinden günlük güncelleme alışkanlığı (unattended-upgrades, dnf-automatic) ve LoginGraceTime gibi pencereleri daraltmak.

5. İçeriden Tehdit (Insider Threat)

Eski ekip üyesi, taşeron, yetkisini aşan geliştirici. Çözüm: kullanıcı yönetimi disiplini (AllowUsers/AllowGroups), audit log (auditd), sudo log incelemesi, kısa ömürlü SSH sertifikaları, authorized_keys rotasyonu.

Bu beş sınıf birbirini tetikler: botnet saldırı zayıf parolayı bulur, parola yetkisiz erişime, yetkisiz erişim insider'a benzer kalıcı sızmaya dönüşür. Defense-in-depth her sınıfa farklı bir katmanla cevap verir.

SSH Protokol Mimarisi: Handshake ve KEX

SSH'ı sertleştirmek için üzerinde durduğunuz protokolü tanımak şart. Bağlantı şu aşamalardan geçer:

1. Sürüm değişimi — istemci ve sunucu SSH-2.0-OpenSSH_9.6p1 benzeri başlıkla anlaşır. SSHv1 protokolü 2006'dan beri terk edildi; modern OpenSSH yalnızca SSHv2 destekler.
2. Algoritma müzakeresi (KEX) — Anahtar değişim algoritması (Curve25519, ECDH, DH), simetrik şifre (ChaCha20-Poly1305, AES-GCM), MAC algoritması (HMAC-SHA2-512-ETM) ve host key algoritması üzerinde anlaşılır. Sertleştirmenin temel yeri burası.
3. Host key doğrulama — Sunucunun /etc/ssh/ssh_host_*_key.pub ile imzalanan public host key'i istemci tarafında ~/.ssh/known_hosts ile karşılaştırılır. Uyumsuzluk WARNING: REMOTE HOST IDENTIFICATION HAS CHANGED mesajıdır ve MITM uyarısıdır.
4. Kullanıcı kimlik doğrulama — Parola, anahtar, GSSAPI, keyboard-interactive (TOTP/OTP), host-based seçeneklerinden biri veya kombinasyonu kullanılır.
5. Oturum açma ve kanal multiplekslemesi — Tek TCP bağlantısı üzerinde shell, port forwarding, X11, SCP/SFTP gibi kanallar açılır.

Sunucuda hangi algoritmaların aktif olduğunu görmek için:

sudo sshd -T | grep -E '(kexalgorithms|ciphers|macs|hostkeyalgorithms)'

Çıktı, mevcut müzakere listesini sıralı olarak gösterir. Eski algoritmalar (diffie-hellman-group1-sha1, hmac-md5) varsayılanda kapatılmıştır ama özel dağıtımlarda hâlâ açık olabilir.

Kullanıcı Yönetimi ve Kimlik Doğrulama Katmanları

SSH'a giriş üç yolla olur: parola, public key, etkileşimli (TOTP / Yubikey vb.). Detaylı anahtar üretimi rehberini SSH anahtar tabanlı kimlik doğrulama yazısında bulabilirsiniz; burada katmanların güvenlik anlamına odaklanıyoruz.

En Önemli Tek Karar: Parolayı Kapatın

PasswordAuthentication no satırı, sshd_config'in tek satırlık en büyük güvenlik kazancıdır. Bu satır eklendikten sonra:

• Botnet brute-force pratikte etkisiz kalır (sadece anahtar kabul edilir)
• Credential stuffing tamamen kesilir
• fail2ban yükü düşer (giriş hata sayısı azalır)

Parolayı kapatmadan önce mutlaka anahtar girişini test edin ve KVM konsol erişiminizi doğrulayın.

Anahtarın Yetersiz Olduğu Yerler: 2FA Ekleyin

Anahtar dosyası bir cihazdan çalınırsa SSH erişimi de çalınır. Yüksek değerli sunucularda iki faktörlü kimlik doğrulama TOTP (Google Authenticator, Authy, Aegis) veya FIDO2 (Yubikey) ile eklenir. Aşağıda PAM yapılandırması bölümünde adım adım anlattık.

authorized_keys'te Erişim Kısıtlama

authorized_keys satırına eklenebilecek opsiyonlar saldırı yüzeyini ciddi daraltır:

from="203.0.113.10,198.51.100.0/24",command="/usr/local/bin/backup.sh",no-port-forwarding,no-X11-forwarding,no-agent-forwarding,no-pty ssh-ed25519 AAAA... yedek@backup-runner

Anlam: bu anahtar sadece belirtilen IP'lerden gelir, bağlandığında sadece backup.sh çalıştırır, port forwarding/X11/agent forward yapamaz, interaktif shell açamaz. Otomasyon (cron, CI/CD) için ideal kalıp.

sshd_config Sertleştirme Katmanı

/etc/ssh/sshd_config dosyası SSH güvenliğinin kalbidir. Aşağıda Buyukweb VDS'leri için pratik test edilmiş örnek profil:

# /etc/ssh/sshd_config — Buyukweb sertlestirilmis profil

# Protokol ve port
Port 22
AddressFamily inet
ListenAddress 0.0.0.0
Protocol 2

# Host key tipleri
HostKey /etc/ssh/ssh_host_ed25519_key
HostKey /etc/ssh/ssh_host_rsa_key

# Modern KEX, cipher, MAC profili
KexAlgorithms [email protected],curve25519-sha256,diffie-hellman-group16-sha512
Ciphers [email protected],[email protected],[email protected]
MACs [email protected],[email protected],[email protected]
HostKeyAlgorithms ssh-ed25519,[email protected],rsa-sha2-512,rsa-sha2-256

# Kimlik dogrulama politikasi
PermitRootLogin no
PasswordAuthentication no
PermitEmptyPasswords no
PubkeyAuthentication yes
ChallengeResponseAuthentication no
UsePAM yes
AuthenticationMethods publickey
MaxAuthTries 3
MaxSessions 5
LoginGraceTime 30

# Kullanici/grup yonetimi
AllowGroups ssh-users
DenyUsers root admin test guest

# Forwarding ve kanal
X11Forwarding no
AllowTcpForwarding no
GatewayPorts no
PermitTunnel no
PermitUserEnvironment no

# Oturum izleme
ClientAliveInterval 300
ClientAliveCountMax 2
TCPKeepAlive yes

# Banner ve UI
Banner /etc/issue.net
PrintMotd yes
PrintLastLog yes
DebianBanner no

# Loglama
SyslogFacility AUTH
LogLevel VERBOSE

Bu profilin satır satır mantığı:

• MaxAuthTries 3: tek bağlantıda 3'ten fazla parola/anahtar denemesi yapılamaz; bağlantı düşer ve fail2ban tetiklenir.
• LoginGraceTime 30: kimlik doğrulama 30 saniyede tamamlanmazsa bağlantı düşer; yavaş tarayıcı saldırılarında kaynak tüketmesini engeller.
• ClientAliveInterval 300 + ClientAliveCountMax 2: 10 dakika idle oturum otomatik kapanır; unutulmuş tmux/screen oturumlarının saldırgana hazır kapı olmasını engeller.
• AllowGroups ssh-users: sadece bu grup üyeleri SSH'a girebilir. Beyaz liste yaklaşımı, yeni kullanıcı eklendiğinde otomatik erişim açılmasını engeller.
• LogLevel VERBOSE: kimlik doğrulama sırasında kullanılan public key fingerprint'i loglanır; audit ve adli analiz için kritik.
• Banner /etc/issue.net: bazı yargı bölgelerinde "yetkisiz erişim yasaktır" uyarısı yasal delil olarak gerekli.

Yapılandırmayı kaydedip uygulamadan mutlaka sözdizimi denetimi yapın:

sudo sshd -t   # Cikti yoksa config valid
sudo systemctl reload sshd

Reload sonrası mevcut oturumunuzu kapatmadan yeni bir terminal penceresi ile bağlanıp doğrulayın. Hata varsa KVM konsoldan dönün.

Port Değiştirme ve Firewall Katmanı

22 yerine 2222, 22022 gibi bir üst port kullanmak otomatik botnet trafiğini ciddi azaltır ama kararlı saldırgana karşı değildir; security-through-obscurity prensibinden öteye geçmez. Port değişikliği ek olarak yapılırsa fayda sağlar; tek başına yeterli değildir. UFW/firewalld kuralları için Linux UFW Firewall ve firewalld rehberi yazılarımıza bakın.

Pratik öneri: port'u değiştirin ama bunu yalnızca fail2ban + AllowGroups + key auth üzerine ek katman olarak görün, tek başına savunma sayman.

Fail2Ban Derinlemesine: Reaktif Savunma Katmanı

Fail2ban, log dosyalarını gerçek zamanlı izleyerek tanımlı pattern'lara uyan satırları gördüğünde IP'yi iptables/nftables üzerinde otomatik ban'lar. SSH için olmazsa olmaz katmandır.

Kurulum

# Debian/Ubuntu
sudo apt install fail2ban

# RHEL/Rocky/AlmaLinux
sudo dnf install epel-release
sudo dnf install fail2ban fail2ban-firewalld

Yapılandırma Hiyerarşisi

Fail2ban dosyaları üç katmandadır:

• /etc/fail2ban/jail.conf — paket varsayılanı, dokunmayın
• /etc/fail2ban/jail.d/*.conf — paket eklentileri
• /etc/fail2ban/jail.local — sizin override'larınız (en üst öncelik)

Tüm değişiklikleri jail.local içinde yapın; paket güncellendiğinde override'larınız korunur.

Pratik jail.local Profili

# /etc/fail2ban/jail.local

[DEFAULT]
# Beyaz liste — kendi IP'leriniz, ofis NAT, izlenen monitoring sunucusu
ignoreip = 127.0.0.1/8 ::1 203.0.113.0/24

# Ban suresi
bantime = 1h
findtime = 10m
maxretry = 4

# Banhost backend — modern Linux'ta nftables varsayilan
banaction = nftables-multiport
banaction_allports = nftables-allports

# Bildirim e-posta
destemail = [email protected]
sender = [email protected]
mta = sendmail
action = %(action_mwl)s

[sshd]
enabled = true
port = ssh
filter = sshd
logpath = /var/log/auth.log
backend = systemd
maxretry = 3
findtime = 10m
bantime = 24h
mode = aggressive

[recidive]
enabled = true
filter = recidive
logpath = /var/log/fail2ban.log
maxretry = 5
findtime = 1d
bantime = 1w
banaction = nftables-allports

Yapılandırmanın katman katman okunuşu:

• [DEFAULT] ignoreip: kendi IP'lerinizi beyaz listeye eklemeyi unutmayın; aksi halde fail2ban sizi de ban'layabilir.
• [sshd] mode = aggressive: yalnızca başarısız parola değil, geçersiz kullanıcı adı, kapatılan bağlantı gibi pattern'ları da yakalar.
• [recidive] jail: fail2ban kendi log'unu okur. Bir IP defalarca ban yedikten sonra recidive jail tarafından bir hafta allports üzerinde ban'lanır. Klasik tek seferlik banlardan çok daha etkili katman.

Filter Regex'i Anlamak

Filter dosyaları /etc/fail2ban/filter.d/ altındadır. SSH için sshd.conf filter'ı failregex direktifi ile auth.log satırlarını yakalar:

# /etc/fail2ban/filter.d/sshd.conf orneklerinden
failregex = ^%(__prefix_line)sFailed password for .+ from <HOST> port \d+ ssh2$
            ^%(__prefix_line)sInvalid user .+ from <HOST> port \d+$
            ^%(__prefix_line)sConnection closed by <HOST> port \d+ \[preauth\]$

<HOST> placeholder'ı IP'yi yakalar. Custom log formatınız varsa kendi filter'ınızı yazıp logpath ile bağlamak gerekir. Filter testini şöyle yaparsınız:

fail2ban-regex /var/log/auth.log /etc/fail2ban/filter.d/sshd.conf

Çıktı kaç eşleşme yakalandığını ve hangi pattern'ın eşleştiğini gösterir; yeni filter geliştirirken vazgeçilmez.

Action Dosyaları

/etc/fail2ban/action.d/ altında ban anında yapılacak işlemler tanımlıdır. nftables-multiport.conf, iptables-multiport.conf, firewallcmd-ipset.conf gibi seçenekler vardır. Distro modern (Debian 12, RHEL 9+) ise nftables'ı tercih edin; eski iptables-legacy yerine daha hızlı.

İsterseniz custom action ile ban anında Telegram/Slack alert gönderebilirsiniz. Örneğin /etc/fail2ban/action.d/telegram.conf:

[Definition]
actionban = curl -s -X POST "https://api.telegram.org/bot${TG_TOKEN}/sendMessage" -d chat_id=${CHAT_ID} -d text="fail2ban ban: <ip> jail=<name>"

Sonra jail.local içinde:

[sshd]
action = nftables-multiport[name=sshd]
         telegram

İzleme ve Yönetim Komutları

# Genel durum
sudo fail2ban-client status

# Belirli jail
sudo fail2ban-client status sshd

# Ban'lanan IP listesi
sudo fail2ban-client get sshd banip

# Manuel ban / unban
sudo fail2ban-client set sshd banip 203.0.113.99
sudo fail2ban-client set sshd unbanip 203.0.113.99

# Tum unbanlama (acil)
sudo fail2ban-client unban --all

GeoIP Filter ile Coğrafi Kısıtlama

Belli ülkelerden hiç bağlantı beklemiyorsanız MaxMind GeoIP veritabanı ile fail2ban'a custom filter yazılabilir. Daha temiz bir yol AllowGroups ile kullanıcı bazlı kısıt veya nftables'ta GeoIP set tabanlı bloklama. Bu tartışmaya VDS güvenlik genel rehberi yazısında giriyoruz.

TOTP 2FA: Google Authenticator + PAM

Yüksek değerli sunucularda anahtar girişine ek olarak TOTP iki faktörü zorunlu kılmak hem insider hem laptop hırsızlığı senaryolarında ciddi katman sağlar.

Kurulum

sudo apt install libpam-google-authenticator   # Debian/Ubuntu
sudo dnf install google-authenticator           # RHEL/Rocky

Kullanıcı Bazlı QR Kodu

Kullanıcı oturumunda google-authenticator komutunu çalıştırın. Sorulara verilecek cevaplar:

• Time-based tokens? y
• Update ~/.google_authenticator? y
• Disallow multiple uses? y
• Increase window from 30s to 4min? n (saldırı yüzeyi)
• Rate-limit (3 deneme/30sn)? y

Telefonunuzdaki Google Authenticator/Aegis/Authy QR kodu okuyup ekler.

PAM ve sshd_config Bağlantısı

/etc/pam.d/sshd dosyasının başına ekleyin:

auth required pam_google_authenticator.so nullok

nullok parametresi, henüz TOTP yapılandırmamış kullanıcıların kilitlenmemesini sağlar; tüm ekip ekledikten sonra kaldırın.

/etc/ssh/sshd_config içinde:

ChallengeResponseAuthentication yes
KbdInteractiveAuthentication yes
UsePAM yes
AuthenticationMethods publickey,keyboard-interactive

AuthenticationMethods publickey,keyboard-interactive satırı kritik: kullanıcı önce anahtarı doğrulamalı, sonra TOTP girmeli. Tek başına TOTP yetmez; iki faktör zorunlu.

sudo sshd -t && sudo systemctl reload sshd

Test etmeden önce yine yeni terminal penceresi ile bağlantı kurun.

Audit Logging: auditd ile SSH Olay İzleme

Linux auditd çekirdek seviyesi audit subsystem'i ile syscall/dosya/komut izlemeyi mümkün kılar. SSH güvenliği bağlamında auditd ile login olaylarını, sudo escalation'ları ve kritik dosya değişikliklerini izleyebilirsiniz.

sudo apt install auditd
sudo systemctl enable --now auditd

Pratik kurallar (/etc/audit/rules.d/ssh.rules):

# sshd_config degisiklikleri
-w /etc/ssh/sshd_config -p wa -k sshd-config

# authorized_keys izleme
-w /home -p wa -k authorized-keys
-w /root/.ssh/authorized_keys -p wa -k authorized-keys

# Login olaylari
-w /var/log/lastlog -p wa -k login-events
-w /var/log/btmp -p wa -k login-failures
-w /var/log/wtmp -p wa -k login-success

# sudo / su escalation
-w /usr/bin/sudo -p x -k sudo-exec
-w /usr/bin/su -p x -k su-exec

Yükleme: sudo augenrules --load. Sorgulama:

# sshd_config kim ne zaman degistirdi?
sudo ausearch -k sshd-config

# Son 24 saatteki basarisiz login
sudo aureport -au -i --start today --failed

# SSH login ozeti
sudo aureport --auth -i

Auditd log'u /var/log/audit/audit.log dosyasına yazılır; uzun vadede merkezi log topla (rsyslog, syslog-ng, Wazuh agent) ve alarmlandır. Kısa vadede logwatch paketi günlük e-posta özeti gönderebilir.

sudo apt install logwatch
sudo logwatch --service sshd --range today --detail high

Defense-in-Depth Kontrol Listesi

Linux SSH güvenliği için sağlayacağınız katman zinciri:

• OpenSSH güncel; unattended-upgrades veya dnf-automatic aktif
• Ed25519 (veya RSA 4096) anahtar çifti, passphrase ile korunmuş
• sshd_config: PasswordAuthentication no, PermitRootLogin no, MaxAuthTries 3, LoginGraceTime 30
• Modern KEX/Cipher/MAC profili uygulandı (curve25519-sha256, chacha20-poly1305, hmac-sha2-512-etm)
• AllowGroups ssh-users ile beyaz liste
• Banner /etc/issue.net yasal uyarı
• ClientAliveInterval 300 ile idle oturum kapama
• X11Forwarding no, AllowTcpForwarding no (gerek yoksa)
• fail2ban kurulu; [sshd] ve [recidive] jail aktif
• fail2ban ignoreip ile kendi IP'leriniz beyaz listede
• (Yüksek değer) TOTP 2FA + PAM + AuthenticationMethods publickey,keyboard-interactive
• auditd kuralları: sshd_config, authorized_keys, sudo izleme
• KVM konsol erişimi test edildi; kilitlenme senaryosu hazır
• authorized_keys rotasyon takvimi (3-6 ay)
• Cloudflare DNS önünde gerçek IP gizleniyor (origin gizleme)

Bu listenin ilk yarısı zorunlu; ikinci yarısı yüksek değerli sunucular için önerilir. Buyukweb VDS paketleri unmanaged geldiği için sertleştirme sorumluluğu sizdedir; KVM konsol garantisi yapılandırma hatasından dönüş güvencesini verir.

Sıkça Sorulan Sorular

fail2ban olmadan sadece sshd_config sertleştirme yeterli mi?

PasswordAuthentication kapalı + key auth + AllowGroups kombinasyonu büyük çoğunluğa karşı yeterlidir. Fail2ban, log dosyalarınızın spam'le dolmasını engellemek, recidive ile kararlı saldırganı uzun süreli ban'lamak ve nftables üzerinde resource tüketimini azaltmak için ek değer katar. Yüksek değerli sunucularda gereklidir, küçük blog VDS'inde opsiyonel.

MaxAuthTries 3 yeterli mi yoksa 1 mi yapsam?

MaxAuthTries tek SSH bağlantısı içindeki deneme limitidir; saldırgan her seferinde yeni bağlantı açabildiğinden MaxAuthTries 1 net bir koruma vermez, sadece kullanıcı deneyimini bozar (parmak hatası kabul etmez). 3 dengeli rakamdır; gerçek savunma fail2ban + key auth katmanlarıdır.

KexAlgorithms ve Ciphers listemi nasıl güncel tutarım?

Mozilla SSH Configuration Guidelines (Modern profili) ve OpenSSH release notları takip edilebilir. ssh-audit aracı (pip install ssh-audit) bağlantınızı tarayıp önerilen profili çıkarır:

ssh-audit sunucu_ip

Çıktıdaki (rec) etiketleri doğrudan sshd_config'e kopyalanabilir.

Port'u 22'den değiştirsem fail2ban'a ihtiyaç kalır mı?

Kalır. Port değişimi yalnızca otomatik botnet hacmini düşürür. Kararlı saldırgan port taraması ile yeni portu 30 saniyede bulur. Fail2ban + key auth + AllowGroups katmanı port değişikliğinden bağımsız olarak gereklidir.

Paylaşımlı cPanel hosting'te bu sertleştirme adımlarını yapmam gerekir mi?

Hayır. Paylaşımlı cPanel paketlerinde SSH yapılandırması Buyukweb sistem ekibi tarafından zaten sertleştirilmiştir; SSH erişiminiz JailShell altında kısıtlı kabukta çalışır. Bu rehber VDS ve Dedicated müşterilerine yöneliktir. Paylaşımlı paketlerden VDS'e geçiş düşünüyorsanız paket karşılaştırma sayfasından detayları inceleyin.

Sonuç

Linux SSH güvenliği tek satırlık çözüm değil, katman zinciridir: tehdit modelini sınıflandırmak, parola girişini kapatmak, sshd_config'i modern KEX/Cipher/MAC profilinde tutmak, fail2ban'ı recidive jail ile beslemek, yüksek değerli sunucularda TOTP 2FA eklemek ve auditd ile her değişikliği loglamak. Bu rehberdeki kontrol listesini uyguladığınızda Buyukweb VDS'iniz Linux SSH tarafında temel sertleştirmeye sahip olur. Yapılandırma sırasında bir adımı atlayıp kendinizi kilitlerseniz KVM konsol garantisi geri dönüş yolunu açık tutar.

Sorularınız için 7/24 Türkçe destek hattımız: 0850 302 60 70 veya iletişim sayfamız.

---

İlgili Büyükweb Hizmetleri

Linux SSH güvenliği uygulayacağınız altyapı için Türkiye lokasyonlu Büyükweb hizmetleri:

• VDS Sunucu — KVM, root erişim, KVM konsol
• E5-V4 VDS Sunucu
• Fiziksel Dedicated Sunucu — IPMI, tam donanım
• cPanel Web Hosting — sertleştirme dahil paylaşımlı paket
• Tüm Paket Karşılaştırma

Sorularınız için 0850 302 60 70 numaralı destek hattımıza veya iletişim sayfamıza yazabilirsiniz.