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

SSH Anahtar Üretimi ve Kurulumu: ssh-keygen ile Temel SSH Güvenliği (2026)

VDS'inize gece 03:00'te 1.500 SSH brute-force denemesi geldi — 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; şifre tabanlı SSH girişi otomatik botnet taramalarına açık davetiye. Bu rehber, Büyükweb VDS müşterilerine yönelik SSH anahtar çifti üretmeyi (ssh-keygen), doğru anahtar tipini seçmeyi ve public key'i sunucuya yüklemeyi adım adım anlatan başlangıç seviyesi bir kılavuzdur. sshd_config sertleştirme, fail2ban, port değiştirme, SSH sertifikaları, 2FA ve FIDO2 donanım anahtarları gibi ileri seviye konuları bu yazının sonundaki bağlantıdan bulabilirsiniz.

Büyükweb perspektifi: VDS paketleri unmanaged teslim edilir; SSH anahtarınızı kurarken güvenliğiniz tamamen sizin sorumluluğunuzdadır. Sunucu, root şifresiyle Web Konsol üzerinden teslim edilir. Web Konsol erişimi kritik güvence: anahtar kurulumunda bir hata yapıp kendinizi kilitlerseniz, konsol üzerinden authorized_keys dosyasını düzenleyip kurtarabilirsiniz. Bu yüzden anahtar yüklemesinden sonra mutlaka yeni bir terminal penceresiyle giriş başarısını doğrulayın, eski oturumu hemen kapatmayı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: yeni bir anahtar kurduğunuzda mutlaka yeni bir terminal penceresi açıp anahtar girişini test edin. Doğrulama yapmadan eski oturumu kapatırsanız kendinizi dışarı atabilirsiniz (Web 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 "admin@sirket.com"

# RSA 4096 (legacy uyum gerekiyorsa)
ssh-keygen -t rsa -b 4096 -C "admin@sirket.com"

# 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 admin@sirket.com" >> ~/.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

Sonraki Adım: Sunucu Sertleştirme (İleri Seviye)

Bu rehber yalnızca SSH anahtar çifti üretmeyi, doğru anahtar tipini seçmeyi ve anahtarı sunucuya yüklemeyi kapsar. Anahtar tabanlı giriş çalıştıktan sonra sunucunuzu daha da sertleştirmek isterseniz sırada şu adımlar var:

• sshd_config sertleştirme (PasswordAuthentication no, PermitRootLogin no, MaxAuthTries gibi direktifler)
• SSH portunu değiştirme ve firewall kuralları
• fail2ban ile otomatik brute-force engelleme
• SSH sertifikaları ile anahtar yönetimini ölçeklendirme
• 2FA (TOTP) ve FIDO2 donanım anahtarlarıyla ek doğrulama katmanı
• Saldırı yüzeyi analizi ve log izleme

Bu adımların tamamı ayrıntılı olarak şu yazıda anlatılıyor: SSH Güvenliği: Saldırı Yüzeyi, SSH Sertifikaları, 2FA ve FIDO2 ile Sertleştirme

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: Web Konsol

Anahtar kurulumunda bir hata yapıp SSH ile giremiyorsanız:

1. Büyükweb müşteri panelinden VDS'in Web Konsolunu açın
2. Root olarak giriş yapın (başlangıç şifresi ile)
3. ~/.ssh/authorized_keys dosyasını kontrol edip düzeltin
4. SSH ile normal bağlantıyı tekrar test edin

SSH Anahtar Kurulum Kontrol Listesi

Aşağıdaki liste tamamlandığında SSH anahtar tabanlı girişiniz çalışır durumda 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

Sunucu sertleştirme adımları (şifre girişini kapatma, fail2ban, 2FA vb.) için yukarıdaki bağlantılı yazıya bakın.

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.

.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.

---

İlgili Büyükweb Hizmetleri

SSH anahtarı ve sunucu yönetimi için:

• VDS Sunucu — VMware vSphere, root erişim, Web Konsol
• E5 v4 VDS Sunucu
• Fiziksel Dedicated Sunucu
• Imunify360 Korumalı cPanel Hosting
• SSH Güvenliği: Saldırı Yüzeyi, SSH Sertifikaları, 2FA ve FIDO2 ile Sertleştirme

Teknik sorularınız için satış öncesi destek numaramız: 0850 302 60 70 veya iletişim sayfamız.