SSH Anahtar Tabanlı Kimlik Doğrulama ve Güvenlik Sertleştirme

SSH Anahtar Tabanlı Kimlik Doğrulama: Güvenli Kurulum ve Sunucu Sertleştirme (2026)

VDS'inize gece 03:00'te 1.500 SSH brute-force denemesi geldi — fail2ban yok, anahtar yok, sadece root şifresi. Sabah panele bakıyorsunuz: şifre değiştirilmiş, arka kapı yüklenmiş. Bu senaryo 2026'da hâlâ gerçekleşiyor. PasswordAuthentication yes + PermitRootLogin yes kombinasyonu otomatik botnet taramalarına açık davetiye. Bu rehber, Buyukweb VDS müşterilerine yönelik SSH anahtar tabanlı kimlik doğrulamayı sıfırdan kurmayı ve sshd_config'i sertleştirmeyi adım adım anlatıyor.

Buyukweb perspektifi: VDS paketleri unmanaged teslim edilir; SSH güvenliği tamamen sizin sorumluluğunuzda. Sunucu, root şifresiyle KVM konsol üzerinden teslim edilir. KVM konsol erişimi kritik güvence: SSH yapılandırmasında yanlışlık yapıp kendinizi kilitlerseniz, konsol üzerinden sshd_config düzenleyip kurtarabilirsiniz. Bu yüzden her yapılandırma değişikliğinden önce KVM konsolunuzu test edin ve eski SSH oturumunu kapatmadan yeni terminal penceresiyle giriş başarısını doğrulayın.

SSH Şifre Girişi vs. Anahtar Tabanlı: Neden Anahtar?

Şifre girişinin temel zayıflığı: botlar saniyeler içinde binlerce kombinasyon deneyebilir. Anahtar tabanlı doğrulamada ise sunucu yalnızca eşleşen özel anahtarı (private key) kabul eder — brute-force ile kırılması pratikte imkânsız.

Özellik	Şifre Girişi	Anahtar Tabanlı
Brute-force riski	Yüksek	Yok (matematiksel olarak imkânsız)
Kimlik bilgisi sızması	Şifre ele geçirilirse erişim açık	Private key şifrelenmiş, tek cihazdadır
Otomasyon uyumluluğu	Zor (şifre kayıt gerekir)	Kolay (ssh-agent ile şifresiz otomasyon)
Yönetim kolaylığı	Şifre rotasyonu gerektir	authorized_keys'ten satır silince iptal
Kurulum karmaşıklığı	Hazır gelir	5 dakika, bir kez yapılır

Kural basit: şifre girişini kapatmadan önce mutlaka yeni bir terminal penceresi açıp anahtar girişini test edin. Doğrulama yapmadan eski oturumu kapatırsanız kendinizi dışarı atabilirsiniz (KVM konsol kurtaracak, ama gereksiz stres).

Ed25519 mi, RSA 4096 mü?

İki popüler algoritma arasında seçim yaparken şu tabloyu kullanın:

Özellik	Ed25519	RSA 4096
Güvenlik düzeyi (2026)	~128-bit eşdeğer	~140-bit eşdeğer
Anahtar boyutu	68 karakter (compact)	~750 karakter
İmza hızı	Çok hızlı	Yavaş (büyük key)
Eski sistem uyumu	OpenSSH 6.5+ (2014)	Her şeyle uyumlu
Önerilen kullanım	Yeni kurulumlar (varsayılan seçim)	10 yıl önceki sistem uyumu

Sonuç: Yeni VDS, modern işletim sistemi? Ed25519 seçin. 2014 öncesi OpenSSH'ı olan legacy sistem veya bazı donanım HSM'ler? RSA 4096 kullanın.

Anahtar Çifti Oluşturma

Linux / macOS

# Ed25519 (önerilen — modern, hızlı, güvenli)
ssh-keygen -t ed25519 -C "[email protected]"

# RSA 4096 (legacy uyum gerekiyorsa)
ssh-keygen -t rsa -b 4096 -C "[email protected]"

# Komut çalışınca:
# 1. Dosya yolu sorulur — Enter ile varsayılan (~/.ssh/id_ed25519) kabul edin
# 2. Passphrase sorulur — MUTLAKA girin (aşağıda açıklandı)

Oluşan dosyalar:

~/.ssh/id_ed25519       ← PRIVATE key (asla paylaşmayın, asla sunucuya kopyalamayın)
~/.ssh/id_ed25519.pub   ← PUBLIC key (sunucuya yüklenen)

Windows (PowerShell / Git Bash)

Windows 10/11'de OpenSSH istemci varsayılan gelir; yukarıdaki komutların aynısını PowerShell veya Git Bash'te çalıştırın.

PuTTY kullanıyorsanız: PuTTYgen → Ed25519 → Generate → Save private key (.ppk). Public key metni doğrudan kopyalayıp authorized_keys'e yapıştırın.

Passphrase + ssh-agent: Güvenlik ile Kolaylık Bir Arada

Private key'e passphrase koymak kritik güvenlik katmanı: key dosyası ele geçirilse bile passphrase olmadan kullanılamaz. Ama her bağlantıda passphrase yazmak yorucu. Çözüm: ssh-agent.

# ssh-agent başlat (terminal oturumu başına bir kez)
eval "$(ssh-agent -s)"
# Çıktı: Agent pid 12345

# Anahtarı agent'a ekle (bir kez passphrase ister, sonra hatırlar)
ssh-add ~/.ssh/id_ed25519

# Eklenen anahtarları listele
ssh-add -l

# Oturum kapatılınca agent otomatik temizlenir — passphrase güvende kalır

Linux masaüstü (GNOME/KDE) kullanıcıları için: ~/.ssh/config dosyasına AddKeysToAgent yes ekleyin; login'de otomatik yüklenir.

# ~/.ssh/config
Host buyukweb-vds
    HostName 1.2.3.4
    User deploy
    IdentityFile ~/.ssh/id_ed25519
    AddKeysToAgent yes
    ServerAliveInterval 60

Public Key'i Sunucuya Yükleme

Yöntem 1: ssh-copy-id (En Kolay)

# Henüz şifre girişi açıkken yükleyin
ssh-copy-id -i ~/.ssh/id_ed25519.pub deploy@SUNUCU_IP

# Özel port kullanıyorsanız
ssh-copy-id -i ~/.ssh/id_ed25519.pub -p 2222 deploy@SUNUCU_IP

Komut otomatik olarak: ~/.ssh dizinini oluşturur, authorized_keys'e ekler, izinleri ayarlar.

Yöntem 2: Manuel Yükleme

# Sunucuda oturum açıkken:
mkdir -p ~/.ssh
chmod 700 ~/.ssh

# Public key içeriğini ekle (yerel makinedeki .pub içeriğini kopyalayıp yapıştırın)
echo "ssh-ed25519 AAAA...pubkey_içeriği [email protected]" >> ~/.ssh/authorized_keys

# İzinleri kesinlikle ayarlayın — OpenSSH yanlış izinlerde anahtarı reddeder
chmod 600 ~/.ssh/authorized_keys

İzin Matrisi (.ssh dizin ve dosyaları)

Dosya/Dizin	Gerekli İzin	chmod Komutu	Yanlışsa ne olur?
~/.ssh/	700 (rwx------)	chmod 700 ~/.ssh	SSH anahtar girişi reddedilir
~/.ssh/authorized_keys	600 (rw-------)	chmod 600 ~/.ssh/authorized_keys	SSH anahtar girişi reddedilir
~/.ssh/id_ed25519 (private)	600 (rw-------)	chmod 600 ~/.ssh/id_ed25519	SSH "permissions too open" hatası
~/.ssh/id_ed25519.pub (public)	644 (rw-r--r--)	chmod 644 ~/.ssh/id_ed25519.pub	Sorun çıkmaz, ama 600 da kabul edilir
~/.ssh/config	600 (rw-------)	chmod 600 ~/.ssh/config	Yanlış izinde uyarı verilir

sshd_config Sertleştirme

Anahtar yüklendikten sonra sunucuda /etc/ssh/sshd_config dosyasını düzenleyin.

Dikkat: Değişiklik yapmadan önce yeni bir terminal penceresi açın ve anahtar girişini test edin. Doğrulama yapmadan şifre girişini kapatırsanız ve anahtarınızda sorun varsa kilitlenirsiniz.

# /etc/ssh/sshd_config — kritik direktifler

# Protokol version (OpenSSH modern sürümünde varsayılan 2, açıkça belirtmek iyi pratik)
# Protocol 2  ← OpenSSH 7.0+ için artık tek seçenek, satır gereksiz ama zararı yok

# Anahtar tabanlı kimlik doğrulama
PubkeyAuthentication yes
AuthorizedKeysFile %h/.ssh/authorized_keys

# Şifre girişini KAPAT (önce anahtar girişini test ettikten sonra)
PasswordAuthentication no
ChallengeResponseAuthentication no
KbdInteractiveAuthentication no

# Root ile doğrudan giriş
# "without-password" = root ile sadece anahtar tabanlı giriş (orta güvenlik)
# "no" = root ile hiç giriş yok (önerilen — sudo kullanın)
PermitRootLogin no

# Boş şifre hesaplarına izin verme
PermitEmptyPasswords no

# Maksimum kimlik doğrulama denemesi
MaxAuthTries 3

# Eş zamanlı bağlantı sayısı sınırı
MaxSessions 10

# Giriş zaman aşımı (saniye)
LoginGraceTime 30

# Bağlantı canlı tutma (inaktif oturumları 10 dakikada kapat)
ClientAliveInterval 300
ClientAliveCountMax 2

# X11 grafik yönlendirme (gerekmiyorsa kapat)
X11Forwarding no

# Ortam değişkeni geçişini kapat
PermitUserEnvironment no

# Yasal uyarı banner (isteğe bağlı)
# Banner /etc/issue.net

# Loglama seviyesi (anahtar girişlerini kayıt altına al)
LogLevel VERBOSE

Değişiklikleri uygulamadan önce config doğrulama yapın:

# Konfigürasyon hata var mı kontrol et
sudo sshd -t && echo "Config gecerli"

# Servisi yeniden başlat (aktif oturumlar kopmaz)
sudo systemctl restart sshd

# Servis durumunu kontrol et
sudo systemctl status sshd

Kritik sshd_config Direktifleri Özeti

Direktif	Güvenli Değer	Neden?
PermitRootLogin	no	Root hesabı hedef; sudo kullan
PasswordAuthentication	no	Brute-force'u engeller
PubkeyAuthentication	yes	Anahtar girişini aktif eder
MaxAuthTries	3	Deneme sayısını sınırlar
LoginGraceTime	30	Yarım kalan girişleri hızla keser
PermitEmptyPasswords	no	Boş şifreli hesabı engeller
X11Forwarding	no	Gereksiz saldırı yüzeyi
AuthorizedKeysFile	%h/.ssh/authorized_keys	Her kullanıcının kendi dizini

SSH Portu Değiştirme: Küçük Kazanım, Büyük Değil

Port 22'yi değiştirmek sık önerilen bir adım — haklı temeli var: varsayılan botlar port 22'yi tarar. Port değişince bu otomatik taramalar kaybolur, log dosyası temizlenir. Ama güvenliğin özü değil. Kararlı bir saldırgan tüm portları tarayabilir; güvenlik anahtar + sertleştirme + fail2ban'dan geliyor.

Yine de logları temizlemek, gerçek saldırıları gürültüden ayırt etmek açısından pratik fayda sağlar.

# /etc/ssh/sshd_config
Port 2222    # veya 49222, 50022 gibi üst port aralığı

# Firewall'da yeni portu açmadan servisi yeniden başlatmayın — kilitlenirsiniz
sudo ufw allow 2222/tcp && sudo ufw delete allow 22/tcp    # Ubuntu/UFW
# veya
sudo firewall-cmd --permanent --add-port=2222/tcp && sudo firewall-cmd --reload  # AlmaLinux/firewalld

# Ardından
sudo systemctl restart sshd

# Bağlantı testi (yeni terminal, eski oturumu kapatmayın)
ssh -p 2222 deploy@SUNUCU_IP

fail2ban ile Brute-Force Koruması

Anahtar tabanlı doğrulama açık olsa bile şifre denemesi yapan botlar log'ları kirletir ve sisteme yük bindirir. fail2ban bu girişimleri otomatik olarak engelleyen hafif, etkili bir araç.

# Kurulum
sudo apt install fail2ban     # Ubuntu / Debian
sudo dnf install fail2ban     # AlmaLinux / Rocky / RHEL

# Servis etkinleştir
sudo systemctl enable --now fail2ban

Varsayılan ayarları override etmek için /etc/fail2ban/jail.local oluşturun:

# /etc/fail2ban/jail.local
[sshd]
enabled  = true
port     = 2222           # SSH port değiştirdiyseniz buraya yazın; 22 ise ssh yazabilirsiniz
filter   = sshd
logpath  = /var/log/auth.log       # Ubuntu/Debian
# logpath = /var/log/secure        # AlmaLinux/RHEL için bu satırı aktif edin
maxretry = 3              # 3 başarısız denemeden sonra ban
findtime = 600            # 10 dakika içinde
bantime  = 3600           # 1 saat ban (daha sıkı: 86400 = 1 gün)

# fail2ban'ı yeniden başlat
sudo systemctl restart fail2ban

# SSH jail durumu
sudo fail2ban-client status sshd

# Ban'lı IP'leri gör
sudo fail2ban-client status sshd | grep "Banned IP"

# Yanlışlıkla ban'landıysanız manuel kaldır
sudo fail2ban-client set sshd unbanip 192.168.1.100

MFA ile Ek Katman: TOTP (İsteğe Bağlı)

Anahtar tabanlı doğrulama zaten çok güçlü. Ama ekstra katman isteyenler için TOTP (Google Authenticator PAM modülü) ile her girişte ek doğrulama kodu eklenebilir. Bu kurulum zorunlu değil; yönetici sayısı az, disiplinli ekiplerde anlamlı.

# Ubuntu / Debian
sudo apt install libpam-google-authenticator

# Kullanıcı başına kurulum (her kullanıcı kendi hesabında çalıştırır)
google-authenticator
# Sorular: zaman tabanlı token = y, QR kodu = y, rate limiting = y

# /etc/pam.d/sshd dosyasının en üstüne ekle
auth required pam_google_authenticator.so

# /etc/ssh/sshd_config — TOTP için ek direktifler
ChallengeResponseAuthentication yes
AuthenticationMethods publickey,keyboard-interactive

sudo systemctl restart sshd

Artık giriş sırası: SSH anahtarı → TOTP kodu. Anahtarı olmayan bağlanamaz; anahtarı çalınan birisi TOTP'suz da bağlanamaz.

Troubleshooting: Sık Karşılaşılan Sorunlar

"Permission denied (publickey)" Hatası

En yaygın sorun. Sırayla kontrol edin:

# 1. Sunucu tarafında verbose SSH log
sudo tail -f /var/log/auth.log    # Ubuntu/Debian
sudo journalctl -u sshd -f        # systemd sistemler

# 2. İstemci tarafında verbose mod ile bağlan
ssh -vvv -i ~/.ssh/id_ed25519 deploy@SUNUCU_IP

# 3. Sunucuda authorized_keys var mı?
cat ~/.ssh/authorized_keys

# 4. İzinler doğru mu?
stat ~/.ssh/
stat ~/.ssh/authorized_keys

# 5. authorized_keys içindeki public key, istemcideki .pub ile birebir eşleşiyor mu?
cat ~/.ssh/id_ed25519.pub
# Sunucudaki authorized_keys satırıyla karşılaştırın

Kendinizi Kilitlediyseniz: KVM Konsol

1. Buyukweb müşteri panelinden VDS'in KVM konsolunu açın
2. Root olarak giriş yapın (başlangıç şifresi ile)
3. /etc/ssh/sshd_config dosyasını düzenleyip sorunu giderin
4. systemctl restart sshd
5. SSH ile normal bağlantıyı test edin

SSH Güvenlik Kontrol Listesi

Aşağıdaki liste tamamlandığında VDS'iniz SSH tarafında temel sertleştirmeye sahip olur:

• Ed25519 (veya RSA 4096) anahtar çifti oluşturuldu, passphrase eklendi
• ssh-agent ile passphrase yönetimi yapılandırıldı
• Public key authorized_keys'e eklendi; ~/.ssh/ 700, authorized_keys 600
• Yeni terminal penceresi ile anahtar girişi test edildi
• sshd_config: PasswordAuthentication no, PermitRootLogin no, MaxAuthTries 3
• sshd -t ile config doğrulandı, sshd restart edildi
• fail2ban kuruldu, SSH jail aktif
• (İsteğe bağlı) Port 22 yerine üst port kullanılıyor
• (İsteğe bağlı) TOTP MFA yapılandırıldı

Sıkça Sorulan Sorular

Ed25519 ile RSA 4096 arasında güvenlik farkı var mı?

Her ikisi de 2026 itibarıyla kriptografik olarak güvenli. Ed25519, eliptik eğri kriptografi (EdDSA) tabanlı; çok daha kısa anahtarla eşdeğer güvenlik sunar, imzalama işlemi RSA'ya kıyasla belirgin şekilde hızlı. RSA 4096 ise eski sisteme bağlı legacy uyum gerektiğinde tercih edilir. Yeni kurulumda Ed25519 seçin.

Root login'i kesinlikle kapatmalı mıyım?

Kapatmanız şiddetle tavsiye edilir (PermitRootLogin no). Root hesabı, tüm Linux sistemlerde sabit kullanıcı adı olduğundan saldırıların birincil hedefi. Bunun yerine sudo yetkisi verdiğiniz normal bir kullanıcı oluşturun. Zorunlu durum varsa PermitRootLogin without-password (yalnızca anahtar, şifre yok) orta seçenek.

.ssh dizin izinleri neden bu kadar önemli?

OpenSSH, grup veya diğer kullanıcıların yazabildiği dizin/dosyaları güvenlik riski olarak görür ve anahtar girişini reddeder. ~/.ssh 777 veya 755 ise authorized_keys 644 ise SSH anahtarınızın doğru olmasına rağmen giriş çalışmaz. Her zaman: dizin 700, authorized_keys ve private key 600.

Passphrase koymak zorunda mıyım? Sunucu otomasyonu için sorun çıkarır mı?

Otomasyon (CI/CD, cron, rsync scriptleri) için passphrase sorun çıkarır. Çözüm: otomasyon için ayrı bir key pair oluşturun, passphrase koymayın; bu key'i sadece gerekli sunucuda ve gerekli komutla sınırlayın (authorized_keys'te command= direktifi ile). İnsan kullanımı için her zaman passphrase + ssh-agent kullanın.

authorized_keys'te birden fazla key olabilir mi?

Evet. Her satır bir ayrı public key. Birden fazla ekip üyesi veya cihaz için farklı satırlara ekleyebilirsiniz. Bir kullanıcının erişimini iptal etmek için o satırı silmeniz yeterli; servis yeniden başlatmak gerekmez.

fail2ban ile SSH port değiştirme aynı anda gerekli mi?

İkisi farklı koruma sağlar. fail2ban, port 22'de bile brute-force girişimlerini ban'lar. Port değiştirmek otomatik taramaları azaltır ama kararlı saldırgana karşı yeterli değil. İdeali: ikisini birlikte uygulayın. Ama öncelik sıranız varsa: anahtar tabanlı doğrulama → PasswordAuthentication no → fail2ban → port değiştirme sıralaması.

TOTP MFA eklemek SSH'ı yavaşlatır mı?

Bağlantı hızı üzerinde ölçülebilir etkisi yok. Tek ek adım, giriş sırasında TOTP uygulamasından (telefon veya donanım token) 6 haneli kod okumak. Otomasyon için sorun çıkarır; deploy scriptleri TOTP'u atlayacak biçimde yapılandırılmalı (AuthenticationMethods ile otomasyon kullanıcılarına sadece publickey zorunlu tutulabilir).

---

İlgili Büyükweb Hizmetleri

SSH güvenliği ve sunucu yönetimi için:

• VDS Sunucu — KVM, root erişim, KVM konsol
• E5 v4 VDS Sunucu
• Fiziksel Dedicated Sunucu
• Imunify360 Korumalı cPanel Hosting

Teknik sorularınız için 7/24 destek hattı: 0850 302 60 70 veya iletişim sayfamız.