VPS SSH Güvenliği Nasıl Sağlanır?

SSH neden ilk olarak güçlendirilmesi gereken unsurdur

SSH, sunucunuzu kontrol etme yönteminizdir; bu da onu saldırganların ilk denediği kilit haline getirir. Bir VPS çevrimiçi olduğu anda, tarayıcılar port 22 üzerinden kullanıcı adı ve şifre tahmin etmeye başlar. Bu durum dakikalar içinde log kayıtlarınızda görülebilir. SSH güçlendirme işlemi, tahmin edilebilecek unsurları devre dışı bırakmayı amaçlar: şifre ile girişi tamamen kapatın, root girişini kapatın ve yalnızca kriptografik anahtarlara izin verin. Bu işlemler yapıldığında, bulunacak bir şifre kalmadığı için sürekli tahmin denemeleri başarısız olacaktır.

Bu süreç, SSH'ın halihazırda çalıştığını varsayar. Eğer giriş yapabiliyorsanız, SSH'ı güçlendirebilirsiniz. Hata yapılması durumunda sistemden dışarıda kalmamak için adımları sırasıyla uygulayın ve yeni bir oturum başarılı olana kadar mevcut oturumunuzu açık tutun.

Adım 1: Öncelikle anahtar kimlik doğrulamasının çalıştığından emin olun

Anahtar kimlik doğrulaması, şifre yerine bir anahtar çifti kullanır: bilgisayarınızda kalan bir özel anahtar (private key) ve sunucuya yüklediğiniz bir genel anahtar (public key). Sunucu, özel anahtar makinenizden hiç çıkmadan, ona sahip olduğunuzu kanıtlar. Şifreleri devre dışı bırakmadan önce anahtarların çalıştığını onaylayın; aksi takdirde erişiminiz engellenebilir.

Kendi bilgisayarınızda, eğer bir anahtarınız yoksa bir anahtar oluşturun:

ssh-keygen -t ed25519

Genel anahtarın yarısını sunucuya kopyalayın:

ssh-copy-id user@your-server

Ardından yeni bir SSH oturumu açın. Eğer şifre sormadan giriş yapmanıza izin veriyorsa, anahtarınız çalışıyor demektir ve şifreleri kapatmak için güvenli durumdasınız. Eğer anahtar kullanımı konusunda yeniyseniz veya birden fazla bilgisayar kullanıyorsanız, SSH key management basics tüm modeli açıklamaktadır: cihaz başına bir anahtar, sshd tarafından talep edilen izinler ve bir dizüstü bilgisayar kaybolduğunda bir anahtarın nasıl iptal edileceği.

Step 2: sshd yapılandırmasını bir drop-in dosyası ile sıkılaştırın

/etc/ssh/sshd_config dosyasını doğrudan düzenlemeyin. Ubuntu 24.04, drop-in dosyalarını /etc/ssh/sshd_config.d/ dizininden okur. Bu dizindeki küçük bir dosya kullanmak daha temizdir, paket güncellemelerinde silinmez ve bir sorun oluşursa kolayca kaldırılabilir. Dosya ismi önemlidir: sshd, her ayar için okuduğu ilk değeri tutar. Ubuntu cloud imajları, bu dizinde PasswordAuthentication yes içeren 50-cloud-init.conf dosyasını barındırır. Dosyanızın ismi 00- olmalıdır; böylece diğer dosyadan önce sıralanır ve geçerli olur. 99- isimli bir dosya sessizce devre dışı kalır. Şu dosyayı oluşturun:

sudo nano /etc/ssh/sshd_config.d/00-hardening.conf

İçeriği şöyledir:

# Key-only login: no passwords to guess.
PasswordAuthentication no
KbdInteractiveAuthentication no

# No direct root login. Log in as your user, then use sudo.
PermitRootLogin no

Her satır bir güvenlik açığını kapatır. PasswordAuthentication no en kritik olanıdır: parolalar devre dışı bırakıldığında, kaba kuvvet (brute-force) saldırıları için hedef kalmaz. KbdInteractiveAuthentication no ikinci bir parola tabanlı erişim yolunu kapatır. PermitRootLogin no ise saldırganın sadece her sistemde bulunan root hesabı yerine, kullanıcı adınızı bilmesi ve anahtarınıza sahip olması gerektiği anlamına gelir.

Step 3: Yapılandırmayı test edin, ardından yeniden yükleyin

Hatalı bir yazımın servisi bozmaması için yapılandırmayı uygulamadan önce hatalara karşı kontrol edin:

sudo sshd -t

Eğer çıktı alınmıyorsa yapılandırma geçerlidir. SSH servisini yeniden yükleyin:

sudo systemctl reload ssh

Ardından, bir ayarın başka bir dosya tarafından geçersiz kılınıp kılınmadığını anlamak için sshd tarafından kullanılan ayarları kontrol edin:

sudo sshd -T | grep -Ei 'passwordauthentication|permitrootlogin'

Her iki çıktı da no değerini göstermelidir. Mevcut oturumunuzu kapatmadan, başka bir terminal üzerinden yeni bir oturum açın. Anahtarınız ile giriş yapabiliyorsanız işlem tamamlanmıştır. Bir sorun oluşursa, hataları düzeltmek için ilk oturumunuz hala açıktır. Bu yöntem bir güvenlik ağıdır, bu adımı asla atlamayın.

Step 4: İsteğe bağlı standart dışı port

SSH portunu 22 yerine 2222 gibi bir port ile değiştirmek gerçek anlamda bir güvenlik sağlamaz; çünkü kararlı bir saldırgan tüm portları tarar. Bu işlem sadece log kalabalığını azaltır, çünkü çoğu otomatik tarayıcı yalnızca 22 portunu dener. Eğer isterseniz, drop-in dosyanıza Port 2222 ekleyin, önce yeni porta firewall üzerinden izin verin, ardından sudo systemctl daemon-reload && sudo systemctl restart ssh.socket komutunu çalıştırın ve ssh -p 2222 ile bağlanın. Ubuntu 24.04 üzerinde, dinleme portu ssh.socket tarafından yönetilir; bu nedenle standart bir reload ssh kullanımı sshd'yi 22 portunda bırakır; yeni portun devreye girmesi için socket'in yeniden başlatılması gerekir. Bu işlemi bir koruma yöntemi olarak değil, bir düzenleme yöntemi olarak değerlendirin.

Step 5: Ek savunma katmanları ekleyin

Güçlendirilmiş SSH anahtarları temel yapıyı oluşturur; bunların üzerinde iki katman daha bulunur.

Fail2ban, log dosyalarını izler ve sürekli hata veren adresleri yasaklar. Bu işlem, tarayıcı gürültüsünü azaltır ve saldırganları erkenden uzaklaştırır. Bu yöntem, yalnızca anahtar tabanlı kimlik doğrulama ile uyumludur: SSH saldırılarını durdurmak için Ubuntu üzerinde Fail2ban kullanımına bakınız.

Daha güçlü bir yöntem ise SSH'ı tamamen halka açık internetten ayırmaktır. Eğer SSH'ı bir WireGuard VPN arkasına koyarsanız ve 22 numaralı portu sadece tünel için sınırlandırırsanız, VPN dışındaki hiç kimse SSH'a erişemez. Bu durumda kaba kuvvet (brute-force) saldırıları sadece zorlaşmakla kalmaz, imkansız hale gelir. Tüm bu adımlar, VPS üzerinde kurulmuş UFW gibi varsayılan olarak her şeyi engelleyen bir güvenlik duvarı var olduğunu varsayar.

SSH, daha geniş bir kontrol listesinin bir parçasıdır: yeni bir VPS üzerindeki ilk 10 dakika adımları sırasıyla sunar ve Ubuntu üzerinde otomatik güvenlik güncellemeleri sistemin sonrasında yamalı kalmasını sağlar.

FAQ

Ubuntu 24.04 üzerinde SSH için parola ile girişi nasıl devre dışı bırakırım?

/etc/ssh/sshd_config.d/00-hardening.conf konumunda PasswordAuthentication no ve KbdInteractiveAuthentication no içeren bir drop-in dosyası oluşturun (00 öneki, 50-cloud-init.conf dosyasından önce sıralanmasını sağlar; aksi takdirde sshd ilk okuduğu değeri kabul ettiği için PasswordAuthentication yes geçerli olur). Yapılandırmayı kontrol etmek için sudo sshd -t komutunu, ardından sudo systemctl reload ssh komutunu çalıştırın. Anahtar ile girişe güvenmeden önce yeni bir oturumda çalıştığını doğrulayın. sshd_config yerine bir drop-in dosyasını düzenlemek, paket güncellemelerinde ayarların korunmasını sağlar ve işlemi geri almayı kolaylaştırır.

SSH üzerinden root girişini devre dışı bırakmalı mıyım?

Evet. Kimsenin doğrudan root olarak giriş yapamaması için PermitRootLogin no ayarını yapın. Normal kullanıcınızla giriş yapın ve yönetici görevleri için sudo kullanın. Root her Linux sisteminde mevcuttur; erişilebilir bırakılması, saldırganlara hedef alabilecekleri bilinen bir kullanıcı adı verir. Devre dışı bırakılması, saldırganın hesap adınızı bilmesi ve anahtarınıza sahip olması gerektiği anlamına gelir.

SSH portunu değiştirmek sunucumu daha güvenli yapar mı?

Anlamlı bir fark yaratmaz. Port 22'den taşınmak, sadece 22 portunu tarayan tembel tarayıcılardan gizlenmenizi sağlar ve log kalabalığını azaltır; ancak gerçek bir saldırgan tüm portları tarar ve portu yine de bulur. Sızmaları asıl engelleyen şey, sadece anahtar tabanlı kimlik doğrulamadır. Port değiştirirseniz, önce yeni portu güvenlik duvarında açın, ardından sudo systemctl daemon-reload && sudo systemctl restart ssh.socket komutunu çalıştırın; Ubuntu 24.04 üzerinde dinleyiciyi socket yönetir ve basit bir reload işlemi sshd'yi port 22'de bırakır.

SSH anahtarları kullanıyorsam Fail2ban kullanmam gerekir mi?

Opsiyoneldir ancak hala kullanışlıdır. Sadece anahtar tabanlı kimlik doğrulamada parola tahminleri başarılı olamaz, bu nedenle saldırganları dışarıda tutan şey Fail2ban değildir. Fail2ban, tek bir adresten gelen tekrarlanan hataları sınırlandırır; bu da loglardaki tarayıcı gürültüsünü azaltır ve tekrarlayan ihlalleri erkenden engeller; yavaş ve dağıtık bir saldırı ise yine de yasaklama eşiğinin altında kalır. Anahtar kimlik doğrulamasıyla birlikte çalıştırın ve ideal olarak SSH'ı bir VPN arkasında tutun.

SSH erişimim kilitlenirse nasıl kurtarırım?

Sağlayıcınızın web konsolunu kullanın. Bu konsol, sunucuya SSH üzerinden geçmeyen bir seri veya VNC bağlantısı ile erişir. Buradan giriş yapabilir, sshd drop-in dosyasını düzeltebilir ve servisi yeniden başlatabilirsiniz. Yeni bir SSH yapılandırması, mevcut oturum kapatılmadan önce ikinci bir terminalde test edilmelidir; çünkü şifreler kapatılmadan önce anahtar kimlik doğrulaması zaten çalışıyor olmalıdır.