SSH Key ile Girişi Güvenceye Alın: Şifre Tabanlı Login Devre Dışı

Sunucu yönetiminde en sık görülen risklerden biri, SSH erişiminin şifre tabanlı açık bırakılmasıdır. Şifreli girişler kaba kuvvet (brute force) denemelerine daha açıktır ve loglarda çok sayıda başarısız deneme üretir. Bu rehberde, Linux tabanlı bir VDS/VPS/dedicated sunucuda SSH key kullanımı kurup şifre tabanlı girişi devre dışı bırakmayı adım adım öğreneceksiniz. Ayrıca yanlışlıkla bağlantıyı kaybetmeme için test, geri dönüş ve kontrol maddeleri de net şekilde yer alacak.

SSH key neden şifreye göre daha güvenli?

SSH, uzak yönetim için standart bir protokoldür. Şifre tabanlı girişte sunucu, kullanıcı adı + parola kombinasyonunu doğrular. Parola yeterince güçlü olsa bile saldırgan otomatik denemeler yapabilir ve süreç uzun sürse de başarılı deneme ihtimali sıfır değildir.

SSH key (anahtar) yaklaşımında doğrulama iki parçanın eşleşmesine dayanır: - Public key (genelde sunucuya yüklenir) - Private key (kullanıcının cihazında kalır)

Private key cihaz dışına çıkmadığı sürece, ele geçirilen tek şey public key olursa doğrudan giriş yapılamaz. Ek olarak doğru yapılandırmayla şu ek korumalar devreye alınabilir: - Şifre tabanlı login kapatılır. - Rastgele port/otomasyon denemelerinin etkisi azalır (tamamen bitmez ama ciddi düşer). - Anahtar yönetimi kolaylaşır: gerektiğinde sadece ilgili anahtarı kaldırırsınız.

Şifre kapatmadan önce bilinmesi gereken kritik nokta

Şifre tabanlı girişi kapatmadan önce, SSH key ile girişin çalıştığını önceden test etmeniz gerekir. Çünkü sshd_config hatası veya yanlış key yerleştirme durumunda, bağlantı kaybı yaşayabilirsiniz.

Bu yüzden plan şu sırayla ilerlemeli: 1) Public key sunucuya yükle 2) Yeni bir terminal/oturum açarak key ile giriş dene 3) Şifreli girişi kapat 4) Yapılandırmayı yeniden yükle 5) Loglardan doğrula

Sunucuda SSH key oluşturma ve kopyalama

Bu bölüm, istemci tarafında (Windows/macOS/Linux bilgisayarınız) başlayarak sunucu tarafında biten akışı anlatır.

1) Anahtar çiftini üretin

Linux/macOS/WSL üzerinde genelde şu komut kullanılır:

ssh-keygen -t ed25519 -a 64 -f ~/.ssh/netkiyas_key

• -t ed25519: Modern ve pratik bir algoritma.
• -a 64: Anahtar oluşturma maliyeti (parola korumalıysa brute force maliyetini artırır).
• -f: Dosya adı. Örneğin ~/.ssh/netkiyas_key.

Sonrasında iki dosya oluşur: - ~/.ssh/netkiyas_key (private key) - ~/.ssh/netkiyas_key.pub (public key)

Private key dosyasının herkese açık olmaması gerekir. En iyi pratik: private key için sadece siz yetkili olmalısınız.

2) Public key’i sunucuya yükleyin

Kolay yöntem ssh-copy-id ile olur. Sunucunuzda kullanıcı adı örneğin ubuntu ise:

ssh-copy-id -i ~/.ssh/netkiyas_key.pub ubuntu@SUNUCU_IP

Sunucunuz root kullanıyorsa veya farklı kullanıcı ile bağlanıyorsanız komutu ona göre düzenleyin. Buradaki kritik nokta: key’in hangi kullanıcı için eklendiğidir. Genellikle ubuntu, debian veya benzeri hazır kullanıcılar kullanılır.

Alternatif yöntem (manual) de uygulanabilir: - Public key içeriğini ~/.ssh/id_ed25519.pub benzeri dosyadan okuyup - Sunucuda ~/.ssh/authorized_keys dosyasına eklemek

Şifre tabanlı SSH login’i devre dışı bırakma

Artık sunucunun key ile giriş yapabildiğini test edebilirsiniz. Bu aşamada hedef, sshd üzerinde şifre doğrulamayı kapatmak ve yapılandırmayı güvenli şekilde yeniden yüklemektir.

1) sshed_config yedek alın

Sunucuda /etc/ssh/sshd_config dosyasını düzenleyeceksiniz. Önce yedek alın:

sudo cp /etc/ssh/sshd_config /etc/ssh/sshd_config.bak-$(date +%F)

Bu, hatalı bir satır yüzünden erişiminiz kesilirse geri dönüş şansını hızlılaştırır.

2) Yapılandırma dosyasını doğrulayın

Düzenleme sonrası şu ayarlar hedeflenir:

• PasswordAuthentication no
• PubkeyAuthentication yes (çoğu kurulumda zaten açıktır)

Dosyanın içinde benzer satırlar varsa üzerine yazın, yoksa dosyaya ekleyin.

Ek olarak, canlı ortamda görülen saldırı yüzeyini azaltmak için şu satır da tercih edilir: - PermitRootLogin no

Bu satırların hepsi her senaryoda şart değildir, ancak şifre tabanlı girişin kapanması için PasswordAuthentication no belirleyicidir.

3) Güvenli test: ikinci bir oturumdan doğrulayın

Şifreyi kapatmadan önce iki bağlantı stratejisi uygulayın: - Mevcut oturumunuz açık kalsın. - Ayrı bir terminalden aynı kullanıcıyla SSH key üzerinden bağlanmayı deneyin.

Örnek komut:

ssh -i ~/.ssh/netkiyas ubuntu@SUNUCU_IP

Bu adım sorunsuz geçerse, şifre tabanlı kapatma aşamasına geçin.

4) Şifreli girişi kapatın ve servisi yeniden başlatın

Ayarları kaydettikten sonra sshd’yi yeniden yükleyin:

sudo systemctl reload sshd

Bazı sistemlerde sshd yerine ssh servis adı kullanılabilir. Hata alırsanız şu komutla servis adını kontrol edin:

sudo systemctl status sshd

veya:

sudo systemctl status ssh

5) Log kontrolü ile doğrulayın

Aşağıdaki loglar, key ile giriş denemelerinizin çalışıp çalışmadığını hızlı görmenizi sağlar:

tail -n 200 /var/log/auth.log

Dağıtıma göre dosya adı değişebilir. Alternatif olarak: - Debian/Ubuntu: /var/log/auth.log - CentOS/RHEL: /var/log/secure

Key ile başarılı giriş görmeniz gerekir. Şifre denemeleri devam ediyorsa PasswordAuthentication no satırının etkisini test etmek için kontrol edin.

Yaygın hatalar ve net çözümler

Aşağıdaki problemler SSH key geçişlerinde en sık yaşanır. Listelenen çözümler, “neden oldu?” sorusunu hızlı kapatır.

Hata 1: authorized_keys dosyası bulunamadı

Belirti: - Key ile bağlanınca Permission denied (publickey).

Çözüm: - Doğru kullanıcı altında ~/.ssh/authorized_keys dosyasının var olduğunu doğrulayın.

Hata 2: Klasör izinleri yanlış

Belirti: - Server refused our key veya benzeri publickey reddi.

Çözüm: ~/.ssh ve authorized_keys izinleri doğru olmalı.

Örnek doğru yaklaşım: - ~/.ssh için 700 - authorized_keys için 600

Komut:

chmod 700 ~/.ssh
chmod 600 ~/.ssh/authorized_keys

Hata 3: yanlış key eklendi (farklı kullanıcıya yükleme)

Belirti: - Key dosyası doğru olsa bile yine publickey reddi.

Çözüm: - Public key’i eklediğiniz kullanıcı ile bağlandığınız kullanıcı aynı olmalı. - Örn. ssh-copy-id ubuntu@IP yaptıysanız ssh ubuntu@IP kullanmalısınız.

Hata 4: sshd_config içinde çakışan ayarlar

Belirti: - PasswordAuthentication no eklediniz ama hâlâ şifre kabul ediliyor.

Çözüm: - sshd_config içinde birden fazla kez geçen ayarları kontrol edin. - Bazı satırlar yorumlanmış olsa bile yanlış okuma olabilir. Etkin değer sonuca göre belirlenir.

Hata 5: Port değişikliği ve güvenlik grupları

Belirti: - Key ile giriş deneniyor ama bağlantı hiç kurulmadan zaman aşımına düşüyor.

Çözüm: - Cloud firewall / security group / yerel UFW/iptables kuralları SSH portunu açmalı. - sshd_config içinde Port değiştiyse istemcide doğru portu kullanın.

Key güvenliği için ek kontrol listesi

Şifreyi kapatmak tek başına “tam güvenlik” değildir; key yönetimi ve erişim disiplini kritik kalır. Aşağıdaki maddeler, pratikte olay riskini azaltır.

Anahtarları yönetin (liste + revokasyon)

• Her kullanıcı/cihaz için ayrı key kullanın.
• Bir cihaz kaybolduğunda veya personel ayrıldığında: ilgili public key’i authorized_keys içinden kaldırın.

Parola korumalı private key kullanın

ssh-keygen sırasında anahtarı parola ile korumak (passphrase) isterseniz private key ele geçirilse bile kullanım zorlaşır.

Fail2ban gibi ek katmanlar

Şifre kapatılınca brute force etkisi azalır; ancak log gürültüsü ve servis dışı riskini daha da düşürmek için fail2ban değerlendirilir. Burada hedef otomatik saldırıyı tamamen durdurmak değil, etkisini daha erken sınırlamaktır.

Root login’i kapatın (gerektiğinde)

PermitRootLogin no ile saldırı yüzeyini küçültürsünüz. Root’a ihtiyaç varsa sudo yetkisi olan normal kullanıcıdan ilerleyin.

İstemci tarafında doğru komutlar (pratik karşılaştırma)

SSH key kurulumunda kullanıcıların en çok takıldığı yerlerden biri hangi komutla hangi key’in kullanılacağıdır. Aşağıdaki tablo, pratikte farkı netleştirir.

(Opsiyonel) ~/.ssh/config ile standartlaştırma

Örnek host tanımı:

Host netkiyas-prod
  HostName SUNUCU_IP
  User ubuntu
  IdentityFile ~/.ssh/netkiyas_key
  IdentitiesOnly yes

Sonra sadece ssh netkiyas-prod çalışır. Bu yöntem, birden fazla key kullanan ekiplerde hata riskini düşürür.

Son kontrol: devre dışı bırakmadan sonra doğrulama adımları

Şifreli login kapatıldıktan sonra şu sırayı takip edin:

1) Key ile yeni oturum açın (mevcut oturumdan bağımsız) 2) Şifre ile giriş denemesi yapın (bilinçli olarak) ve reddedildiğini görün 3) Loglarda publickey doğrulaması ve şifre denemelerinin reddi görünün 4) Gerekirse başka bir kullanıcıyla da doğrulama yapın

Aşağıdaki hedef durumlar “doğru ayar” göstergesidir: - Başarılı giriş: Accepted publickey - Şifre reddi: Password authentication is disabled

Sonuç: Şifreyi kapatın ama önce key ile kanıtlayın

SSH key kullanımı ve PasswordAuthentication no adımı, kaba kuvvet denemelerine karşı en etkili ve ölçülebilir korumalardan biridir. Yapılandırmayı değiştirirken kritik olan nokta, bağlantıyı kesmeden önce key ile girişin çalıştığını iki ayrı oturumla doğrulamaktır.

Aksiyon önerisi: Önce key ekleyin, ayrı bir terminalden key ile bağlanmayı test edin, ardından sshd_config içinde şifre tabanlı girişi kapatıp sshd’yi reload edin. Son olarak loglardan publickey kabulünü kontrol edin. Böylece hem güvenliği artırır hem de erişim kaybı riskini sıfıra indirirsiniz.