Linux SSH Port Değiştirme: Prosedür, Port Knocking ve Alternatifler

Linux SSH Port Değiştirme: Prosedür, Security Through Obscurity Tartışması ve Alternatif Yaklaşımlar

Public IP'li bir Linux sunucusu açtıktan sonra /var/log/auth.log veya journalctl -u ssh çıktısına bakanların ilk şoku şudur: 22 numaralı port saatte yüzlerce, bazen binlerce deneme alır. Bu trafiğin neredeyse tamamı otomatik botnet'lerin "açık 22 + zayıf parola" eşleşmesi aradığı dağıtık taramalardır. Sysadmin'ler bu gürültüden kurtulmak için ilk akla gelen çözüme başvurur: SSH portunu değiştirmek. Ancak port değişikliği gerçek bir koruma mıdır, yoksa yalnızca log gürültüsünü mü azaltır? Ne zaman uygulanmalı, ne zaman fazla iş çıkarır? Port değişikliğinin yerine veya yanında kullanılabilecek port knocking, Single Packet Authorization (SPA), bastion host ve VPN tunnel gibi alternatifler nelerdir? Bu rehberde Buyukweb VDS müşterileri için SSH port değiştirme prosedürünü adım adım, kritik tuzaklarıyla ve modern alternatifleriyle birlikte ele alıyoruz.

Buyukweb perspektifi: E5-V4 VDS paketleri Bursa Tier 3 datacenter'da unmanaged teslim edilir; root erişim size aittir ve SSH portunu istediğiniz değere taşıyabilirsiniz. Yapılandırmada kendinizi kilitlerseniz panel üzerinden KVM web konsola düşüp /etc/ssh/sshd_config düzenleyerek kurtulabilirsiniz; bu yazıdaki adımları takip ederken bu kurtarma yolunu daima aklınızda tutun. cPanel paylaşımlı paketlerde ise SSH varsayılan olarak 2222 portunda dinler ve kullanıcı tarafından değiştirilemez (sunucu yöneticisinin politikasıdır); bu rehberin port değiştirme bölümü VDS/dedicated sahipleri içindir.

İlgili rehberler: SSH bağlantı kurma temelleri, Linux SSH terminal komutları, SSH güvenliği ve fail2ban, SSH anahtar tabanlı kimlik doğrulama, port nedir ve port aralıkları. Bu yazı bunlardan ayrı odak taşır: yalnızca port değiştirme prosedürü, obscurity tartışması ve alternatifler.

Neden SSH Portunu Değiştirmek İsteriz?

Port değiştirmenin somut faydaları ve sınırları net olarak belirlenmeden hangi katmanın gerçek koruma sağladığını ayırt edemezsiniz.

Somut Fayda 1: Log Gürültüsünü %95+ Azaltmak

22 portu internet ölçeğinde sürekli taranır. Bir Buyukweb VDS'de port 22'yi açık bırakıp fail2ban çekirdek varsayılanları ile çalıştırırsanız /var/log/auth.log günde binlerce satır brute-force denemesi içerir. SSH'ı 22122 gibi popüler olmayan bir porta taşıdığınızda bu log gürültüsü %95'ten fazla düşer. Bunun pratik anlamı:

• Logları gözle taramak mümkün hale gelir, gerçek olayları (kendi başarısız girişleriniz, ekip arkadaşı denemeleri) kolay görürsünüz.
• Wazuh, CrowdSec, syslog-ng gibi SIEM/log ajanlarının indeksleme ve depolama maliyeti düşer.
• fail2ban kuyruğu küçülür; daha az IP ban listesi, daha hızlı tepki.
• SSH daemon'un her başarısız bağlantıyı log'lamak için harcadığı CPU çekirdek ısırığı düşer (mikroskopik ama gerçek).

Somut Fayda 2: Düşük Vasıflı Botnet Trafiğini Kesmek

Mirai ve türevi otomatik botnet'ler maliyet/getiri optimizasyonu yapar: yalnızca 22 numaralı portu tarar ve zayıf parola dener. Port değişikliği bu sınıf saldırıyı pratikte sıfırlar. Bot, sunucunuzun 22 portunu kapalı görür ve listede sonraki IP'ye geçer.

Sınır 1: Gerçek Koruma Değil

Hedefli bir saldırgan nmap -p 1-65535 sunucu.ornek.tr veya masscan ile tüm portları 1 dakikadan kısa sürede tarar; SSH'ın 22122'de dinlediğini görür. Port değişikliği security through obscurity'dir (gizleme yoluyla güvenlik); kararlı tehdit aktörü için yalnızca bir hız tümseğidir.

Sınır 2: Tek Başına Yetmez

Port değişikliği yapılıp başka katman eklenmezse zayıf parola hâlâ saldırılabilir, OpenSSH sıfır gün açığı hâlâ etkili kalır, sızdırılan SSH key hâlâ kullanılabilir. Defense-in-depth zincirinin bir halkasıdır; asıl koruma aşağıdaki katmanlarda yatar:

• Parola girişini kapatmak (PasswordAuthentication no) — bkz. SSH anahtar tabanlı kimlik doğrulama
• fail2ban ile reaktif IP ban — bkz. SSH güvenliği ve fail2ban
• sshd_config sertleştirme (MaxAuthTries, LoginGraceTime, AllowGroups)
• Cloud firewall (sağlayıcı paneli üzerinden whitelist)
• OpenSSH ve kernel güncelleme disiplini

Bu liste tamamlandıktan sonra port değişikliği isteğe bağlı bir gürültü azaltıcı katmandır; asıl güvenlik üst beş satırda yatar.

Port Seçimi: 0-65535 Aralığında Nereye Taşımalı?

TCP/UDP port aralığı üç sınıfa ayrılır ve seçim bu sınıfların pratik özelliklerine göre yapılır. Detaylı port mantığı için port nedir yazımıza bakabilirsiniz; burada SSH özelinde özet veriyoruz.

Well-Known Ports (0-1023)

Sistem servisleri için ayrılmış aralık. SSH varsayılanı 22 burada. Bu aralıkta dinleme yapmak için sunucu sürecinin root yetkisi olmalı; OpenSSH zaten root altında başladığı için bu kısıt SSH için sorun değil. Ama IANA bu aralığı resmi servis tahsisi için kullanır; sebepsiz olarak başka bir well-known port'a (örneğin 443 HTTPS) SSH koymayın — log analizinde, IDS imzalarında ve istemci varsayımlarında karışıklık yaratır.

Registered Ports (1024-49151)

Yazılım üreticileri tarafından IANA'ya kayıtlı ya da fiilen tahsis olmuş aralık. SSH için tercih edilmesi gereken bölge burası:

• 2222 — cPanel/WHM'in SSH portu olarak çok yaygın; otomatik tarayıcılar artık 22 yanında 2222'yi de düzenli tarar. Yine de 22'den temiz, ama "az popüler" değil.
• 22022, 22122, 22322, 50022 — bot tarayıcıların ilk 1000 listede olmayan aralıklar; pratikte log gürültüsünde gözle görülür rahatlama.
• Çakışma kontrolü: yeni port'u seçmeden önce ss -tlnp | grep :<port> veya lsof -i :<port> ile başka servisin dinleyip dinlemediğini görün. Aynı port'ta web sunucusu, mail relay veya container ağ köprüsü çalışıyorsa SSH başlamaz.

Dynamic/Private Ports (49152-65535)

İstemci tarafının geçici (ephemeral) bağlantıları için ayrılan aralık. Bu aralıkta dinleyen SSH'ın TIME_WAIT çakışma ve istemci kaynak port problemleri olur: yüksek trafikli sunucularda outbound bağlantılar bu aralıktan geçici port aldığında SSH dinleyici ile çakışma riski yükselir. SSH için 1024-49151 arasını tercih edin; ephemeral aralığını boş bırakın.

Şehir Efsanesi: "22 yerine 222 yeterli"

Birkaç yıl öncesine kadar 222 bot tarayıcı listelerinde yoktu; bugün öyle değil. 22, 222, 2222, 22222 — bu pattern'ler artık standart bot listelerinde. Pratik tavsiye: 5 haneli ve popüler olmayan bir sayı seçin (örnek: 22122, 50322, 64022). Hatırlanması zorsa ~/.ssh/config dosyasında alias oluşturursunuz; akılda tutmak zorunda kalmazsınız.

Adım Adım Port Değiştirme Prosedürü

Bu prosedürün her adımı kendi kapısını kilitleme riskini en aza indirir. Hiçbir adımı atlamayın; özellikle "yeni terminalde test" maddesini.

Adım 1: Yeni Port'a Önceden Firewall İzni Verin

sshd'yi yeni porta taşımadan önce firewall'da yeni port'u açın. Aksi halde sshd başlatılır ama trafik firewall'da bloke olur ve eski porttan da düşmüş olursunuz.

# UFW (Ubuntu/Debian)
sudo ufw allow 22122/tcp comment 'SSH yeni port'

# firewalld (RHEL/AlmaLinux/Rocky)
sudo firewall-cmd --permanent --add-port=22122/tcp
sudo firewall-cmd --reload

# iptables (klasik)
sudo iptables -A INPUT -p tcp --dport 22122 -j ACCEPT
sudo iptables-save | sudo tee /etc/iptables/rules.v4

Adım 2: sshd_config'i Düzenleyin — Eski Satırı SİLMEYİN

/etc/ssh/sshd_config dosyasında Port direktifini bulun; eski satırı kaldırmayın, yeni bir satır ekleyin:

sudo nano /etc/ssh/sshd_config

# /etc/ssh/sshd_config
Port 22
Port 22122

OpenSSH iki port'u aynı anda dinleyebilir. Bu sayede yeni port'tan test ederken eski 22 üzerindeki açık oturumunuz düşmez. Yeni port'un çalıştığını teyit ettikten sonra eski Port 22 satırını kaldıracaksınız.

Adım 3: SELinux Uyarısı (RHEL, AlmaLinux, Rocky, Oracle Linux)

SELinux enforcing modda çalışan sistemlerde sshd yalnızca ssh_port_t etiketli portları dinleyebilir. Yeni port'u bu etikete eklemezseniz sshd -t sözdizimi geçer ama servis başlamaz ve journalctl "Failed to bind to port" hatası verir.

# Yeni port'u SELinux SSH port havuzuna ekle
sudo semanage port -a -t ssh_port_t -p tcp 22122

# Kontrol
sudo semanage port -l | grep ssh
# ssh_port_t                     tcp      22122, 22

semanage komutu yoksa policycoreutils-python-utils paketini kurun:

sudo dnf install policycoreutils-python-utils

SELinux denial yaşandığında audit2allow ile özel politika üretebilirsiniz; ama port etiketleme semanage standart yoldur.

Adım 4: Sözdizimi Denetimi — sshd -t

Yapılandırma değişikliği sonrası mutlaka sözdizimi denetimi yapın:

sudo sshd -t
# Çıktı boşsa config geçerli; hata varsa satır numarasıyla raporlar

sshd -t sessiz çıkarsa yapılandırma yüklenebilir demektir.

Adım 5: Reload, Restart Değil

Aktif oturumunuzun düşmemesi için reload kullanın; restart yapılırsa açık SSH oturumu kapanma riskine girer.

sudo systemctl reload ssh        # Debian/Ubuntu
sudo systemctl reload sshd       # RHEL/AlmaLinux/Rocky

Reload sonrası sshd hem 22 hem 22122 portunda dinler.

Adım 6: Yeni Port'tan Test — Eski Terminali KAPATMAYIN

Bu adım kritiktir. Mevcut SSH oturumunuzu kapatmadan, ayrı bir terminal penceresi açın ve yeni port üzerinden bağlanın:

ssh -p 22122 [email protected]

Bağlantı başarılıysa hem firewall, hem sshd, hem SELinux (uygunsa) doğru yapılandırılmış demektir. Bağlantı başarısızsa eski terminalden geri dönüp logları inceleyin (sudo journalctl -u ssh -n 50) ve gerekli düzeltmeyi yapın.

Adım 7: Eski Port Satırını Kaldırın

Yeni port çalışıyorsa sshd_config'deki eski Port 22 satırını silin veya yorum satırına çevirin:

# Port 22
Port 22122

Sonra tekrar sshd -t ve systemctl reload çalıştırın.

Adım 8: Firewall'da Eski 22'yi Kapatın

# UFW
sudo ufw delete allow 22/tcp
# veya
sudo ufw deny 22/tcp

# firewalld
sudo firewall-cmd --permanent --remove-service=ssh
sudo firewall-cmd --reload

# iptables
sudo iptables -D INPUT -p tcp --dport 22 -j ACCEPT
sudo iptables-save | sudo tee /etc/iptables/rules.v4

Adım 9: fail2ban jail.local Güncelleyin

Eğer fail2ban kullanıyorsanız (kullanmıyorsanız ID 128 rehberini okuyun), sshd jail'inin port'unu güncelleyin:

# /etc/fail2ban/jail.local
[sshd]
enabled = true
port = 22122
filter = sshd
logpath = %(sshd_log)s
maxretry = 3
bantime = 1h

sudo systemctl reload fail2ban

Adım 10: Cloud Firewall (Sağlayıcı Paneli) Güncellemeyi Unutmayın

Sunucu içi firewall (UFW/firewalld/iptables) ile sağlayıcı taraflı cloud firewall ayrı katmanlardır. Buyukweb panel üzerinden ağ kuralları tanımladıysanız 22 portunu kapatıp 22122'yi açın. Aksi halde dış dünyaya hâlâ 22 açık görünür ya da yeni port iç firewall'da açıkken dış firewall'da kapalı olduğu için bağlantı kuramazsınız.

Kendi Kapısını Kilitleme: KVM Web Konsol Kurtarma Yolu

Bu prosedürün herhangi bir adımında bir hata yaparsanız (yanlış port, eksik SELinux etiketleme, firewall sırası karışırsa) ve SSH oturumunuzu kaybederseniz panik yapmayın. Buyukweb VDS paketleri KVM tabanlı web konsol erişimi sağlar; panel üzerinden konsola düşersiniz, doğrudan tty ile sunucuya bağlanır ve aşağıdaki kurtarma adımlarını uygularsınız:

# Konsoldan root veya sudo'lu kullanıcı ile girin
sudo nano /etc/ssh/sshd_config
# Port satırını eski haline getirin veya yeni port'u kontrol edin

sudo sshd -t
sudo systemctl restart ssh

# Firewall durumunu görün
sudo ufw status
# veya
sudo firewall-cmd --list-all

KVM konsol ağ üzerinden çalışmaz, doğrudan sanal donanıma bağlandığı için SSH/firewall sorununa karşı bağışıktır. Yeni VDS açtığınız ilk gün panel üzerinden bu konsola erişebildiğinizi mutlaka test edin; ihtiyaç anında tanımak için.

İstemci Tarafı Otomasyonu: ~/.ssh/config

Her bağlantıda -p 22122 yazmak istemiyorsanız ~/.ssh/config dosyasında host alias tanımlayın:

Host vds
    HostName sunucu.ornek.tr
    User omer
    Port 22122
    IdentityFile ~/.ssh/id_ed25519

Bundan sonra basit ssh vds komutu yeterli olur. SCP ve rsync için de port büyük P (-P) parametresi ile geçer ama config alias kullanıyorsanız bu da otomatik olur:

# Manuel port belirtimi
scp -P 22122 dosya.tar.gz [email protected]:/srv/backup/
rsync -avz -e 'ssh -p 22122' /local/dir/ [email protected]:/srv/dir/

# Config alias ile
scp dosya.tar.gz vds:/srv/backup/
rsync -avz /local/dir/ vds:/srv/dir/

CI/CD pipeline'ları, Ansible inventory, Git remote (git@vds:org/repo.git SSH transport), IDE remote-SSH eklentileri (VS Code Remote-SSH, JetBrains Gateway) — hepsinin yapılandırmasını yeni port'a göre güncellemeniz gerekir. Port değişikliğinden sonra çağrı dışı kalmış ne kadar otomasyon olduğunu test edip listelemeniz iyi olur; yoksa bir gece yarısı CI pipeline'ın "connection refused" hatasıyla kırılır.

Port Knocking (knockd) ile SSH'ı Gizlemek

Port değişikliği yerine veya yanında uygulanabilecek daha güçlü bir gizleme tekniği port knocking'tir. Mantığı:

1. SSH port'u (örneğin 22122) firewall'da varsayılan olarak kapalı.
2. İstemci, sunucuya önceden anlaşılmış bir paket dizisi atar (örnek: 7000 → 8000 → 9000).
3. Sunucu üzerinde çalışan knockd daemon'u bu sırayı tanır, iptables/nftables üzerinden 22122'yi geçici (örneğin 10 saniye) açar.
4. İstemci açılan pencereden SSH bağlantısını kurar; bağlantı kurulduktan sonra port tekrar kapanır ama mevcut bağlantı kapanmaz (stateful firewall).

knockd Kurulum

# Debian/Ubuntu
sudo apt install knockd

# Yapılandırma
sudo nano /etc/knockd.conf

[options]
    UseSyslog

[openSSH]
    sequence    = 7000,8000,9000
    seq_timeout = 10
    command     = /sbin/iptables -A INPUT -s %IP% -p tcp --dport 22122 -j ACCEPT
    tcpflags    = syn

[closeSSH]
    sequence    = 9000,8000,7000
    seq_timeout = 10
    command     = /sbin/iptables -D INPUT -s %IP% -p tcp --dport 22122 -j ACCEPT
    tcpflags    = syn

Knockd'yi etkinleştirin:

sudo systemctl enable --now knockd

İstemci Tarafı: knock

# Önce port'u "vur"
knock sunucu.ornek.tr 7000 8000 9000

# Sonra SSH
ssh -p 22122 [email protected]

Tek satıra birleştirmek için:

knock sunucu.ornek.tr 7000 8000 9000 && ssh -p 22122 [email protected]

Avantajlar ve Dezavantajlar

Avantajlar:

• Dış nmap taramasında SSH port'u kapalı görünür; saldırgan SSH'ın orada olduğunu bile anlamaz.
• fail2ban gerek bırakmayacak kadar saldırı yüzeyi azalır.
• Standart firewall altyapısı üstüne kurulur, ek port açmaz.

Dezavantajlar:

• Replay attack riski: TCP paket sırası ağda gözlemlenirse aynı sıra başkasınca tekrarlanabilir. Bazı kurumsal IDS ortamlarında knock paketleri sırasını yakalar.
• Tek faktörlü: dizi bilgisi tek başına kafidir; ek kimlik doğrulama yok.
• Otomasyona zor sığar: cron job'lar, monitoring agent'lar her dakika knock atmak zorunda kalır.
• Mobil ağda paket sırası bozulur: NAT/proxy'li ağlarda paketlerin SYN bayrağı veya sırası kaybolabilir; pratik kullanım zorlaşır.

Bu sebeplerle modern alternatif Single Packet Authorization (SPA) öne çıktı.

Single Packet Authorization (SPA) — fwknop

SPA, port knocking'in evrimleşmiş hali olarak Cipherdyne tarafından geliştirilen fwknop projesinde somutlanır. Mantığı şudur: dizi yerine tek bir şifrelenmiş paket içine kimlik doğrulama bilgisi gömülür. Sunucu paketi açar, doğrularsa SSH port'unu istemci IP'sine geçici açar.

SPA Paketi İçeriği

Tek bir UDP/TCP paketinde aşağıdakiler vardır:

• Şifreleme: AES (CBC veya GCM) ile şifrelenmiş payload
• HMAC: SHA-256 veya SHA-512 ile bütünlük doğrulama
• Zaman damgası (anti-replay): paket eski ise reddedilir
• Hedef IP/port: hangi servis açılacak
• Kullanıcı adı veya client ID
• Access window süresi

Sunucu paketi alır, HMAC doğrular, AES şifresini çözer, zaman damgasını kontrol eder; sonuç başarılıysa iptables/nftables üzerinden geçici kural ekler.

fwknop Kurulum

# Sunucu tarafı
sudo apt install fwknop-server

# İstemci tarafı (kendi laptop'unuzda)
sudo apt install fwknop-client

Sunucuda /etc/fwknop/fwknopd.conf ve /etc/fwknop/access.conf dosyalarını yapılandırın. access.conf örneği:

SOURCE: ANY;
OPEN_PORTS: tcp/22122;
KEY_BASE64: <random-base64-32byte>;
HMAC_KEY_BASE64: <random-base64-32byte>;
FW_ACCESS_TIMEOUT: 30;

İstemci ~/.fwknoprc dosyasında aynı anahtarları tutar ve şu komutla paket gönderir:

fwknop -A tcp/22122 -a <kendi-genel-ip> -D sunucu.ornek.tr
# Sonra SSH
ssh -p 22122 [email protected]

SPA'nın knockd'ye Üstünlüğü

• Tek paket olduğu için NAT/proxy'li ağlarda paket sırası bozulması sorunu yok.
• HMAC + AES sayesinde replay attack'a karşı zaman damgası ile bağışık.
• IDS imzaları paketi normal UDP/TCP trafik olarak görür; sıra örüntüsü yok.
• Standart kütüphanelerle (Python, Go, C) istemci yazmak kolay; otomasyona uyar.

Yüksek değerli sunucular için knockd yerine fwknop tercih edilir; yapılandırma daha karmaşıktır ama güvenlik kazanımı belirgin.

VPN Tunnel Üzerinden SSH (En Güvenli Yaklaşım)

Port değişikliği, port knocking ve SPA — hepsi SSH'ın public internet'te dinlemesi varsayımına dayanır. Daha güçlü bir mimari, SSH'ı internetten hiç görünmez kılmaktır: sunucuda VPN endpoint çalıştırıp SSH'ı yalnızca VPN subnet'inden erişilebilir hale getirmek.

WireGuard Senaryosu

WireGuard rehberimizde detaylı anlatılan kurulumdan sonra sunucuda wg0 arayüzü oluşur ve VPN subnet'i (örneğin 10.10.0.0/24) tahsis edilir. sshd_config:

ListenAddress 10.10.0.1
Port 22

ya da sshd public IP'de dinlese bile firewall'da:

sudo ufw deny in on eth0 to any port 22
sudo ufw allow in on wg0 to any port 22

Sonuç: dış dünyadan SSH portu kapalı; yalnızca WireGuard tüneli kurulu istemciler bağlanabilir.

OpenVPN Senaryosu

OpenVPN sunucu kurulumu rehberinde tarif edildiği gibi tun0 arayüzü ve client subnet (10.8.0.0/24) sonrası benzer firewall kuralları uygulanır.

Avantajlar

• SSH internet'e açık değil; nmap taramada port closed.
• VPN istemci sertifikası iptal edilince SSH erişimi de kesilir; merkezi yönetim.
• Ek faktör olarak VPN kimlik doğrulama gelir (sertifika + parola + TOTP).
• SSH dışındaki yönetim portları (panel, monitoring) da aynı tünelden geçer; saldırı yüzeyi tek noktaya iner.

Dezavantajlar

• Acil durum erişimi: VPN sunucusu kendisi düşerse SSH'a da düşemezsiniz. KVM web konsol burada hayat kurtarır.
• VPN istemci dağıtımı: yeni ekip üyesine sertifika üretme/iptal süreci kurulmalı.
• Mobil bağlantıda gecikme: VPN tüneli üstünden SSH ekstra 20-50 ms RTT ekleyebilir.

VPN'in ek karmaşıklığını taşıyabiliyorsanız (3+ ekip üyesi, kritik sunucu) bu yaklaşım en güçlü güvenlik katmanını sağlar.

Bastion Host (Jump Host) Pattern ve ProxyJump

Birden fazla iç sunucu yöneten ekipler için bastion host klasik kalıbıdır. Tek bir sertleştirilmiş sunucu (bastion) public IP'de SSH dinler; iç sunucular yalnızca internal network'te erişilebilir. Yönetici bastion'a girer, oradan iç sunuculara atlar.

ProxyJump (-J) — SSH'ın Yerleşik Çözümü

OpenSSH 7.3+ ile gelen -J parametresi bu kalıbı tek komutta uygular:

ssh -J [email protected]:22122 [email protected]

İstemci önce bastion'a bağlanır, bastion'dan iç sunucuya bir TCP forwarding kurar ve iç sunucuya SSH'lar. Bastion'da omer kullanıcısının authorized_keys dosyası gerekir; iç sunucuda da aynı kullanıcının anahtarı kabul edilmelidir.

~/.ssh/config ile Otomatik ProxyJump

Host bastion
    HostName bastion.ornek.tr
    User omer
    Port 22122
    IdentityFile ~/.ssh/id_ed25519

Host internal-*
    User omer
    IdentityFile ~/.ssh/id_ed25519
    ProxyJump bastion

Host internal-web
    HostName 10.0.1.50

Host internal-db
    HostName 10.0.1.51

Bundan sonra ssh internal-web komutu otomatik bastion üzerinden zıplar.

Bastion'un Sertleştirilmesi

Bastion tek public-facing sunucu olduğu için ekstra sıkı yapılandırılır:

• Sadece SSH portu açık (başka servis yok)
• PasswordAuthentication no, key-only auth
• 2FA (TOTP veya FIDO2) ekstra katman
• Tüm SSH oturumları auditd ile loglanır
• İç sunuculara erişen anahtarlar bastion üzerinde authorized_keys from= kısıtı ile bastion IP'sine sabitlenir
• Bastion düşerse iç sunuculara erişim için KVM/console fallback olmalı

Cloudflare Zero Trust Yaklaşımı (Kavramsal)

Modern bulut güvenlik yaklaşımlarında Cloudflare Tunnel + Cloudflare Access ile SSH'ı public IP'den hiç açmadan, tarayıcı tabanlı bir SSH gateway üzerinden erişim verme modeli yaygınlaştı. Sunucuda cloudflared daemon'u Cloudflare ağına outbound tünel kurar, kullanıcı Cloudflare Access ile SSO/2FA üzerinden kimlik doğrular ve tarayıcıdan SSH oturumu açar. Buyukweb bu modeli pazarlamamakla birlikte mimari olarak bilinmesi faydalı bir alternatiftir; özellikle ekip büyüdükçe SSH key yönetimi yerine kimlik tabanlı erişim modeline geçmek isteyenler için kavramsal bir referanstır.

Port Değiştirme Yerine veya Yanında: Reaktif Savunma Araçları

Port değişikliğinin sınırını gördükten sonra reaktif savunma katmanlarını mutlaka kurmanız gerekir:

fail2ban

ID 128 rehberinde detaylı anlatıldığı gibi, 3 başarısız deneme sonrası IP'yi 1 saat ban'lar. Standart kurulum:

sudo apt install fail2ban

/etc/fail2ban/jail.local ile sshd jail'ini aktive edersiniz.

CrowdSec

fail2ban'a modern alternatif; topluluk tabanlı IP threat sharing yapar. Ban kararları yerel log + global IP itibar listesi ile alınır. Sizin sunucunuza saldıran IP başka sunuculara da saldırıyorsa CrowdSec topluluğu üzerinden bilgi paylaşılır.

curl -s https://install.crowdsec.net | sudo sh
sudo apt install crowdsec
sudo apt install crowdsec-firewall-bouncer-iptables

sshguard

fail2ban benzeri, daha hafif syslog tabanlı alternatif. C ile yazılmıştır, Python bağımlılığı yoktur.

sudo apt install sshguard

Wazuh ve IDS/IPS

Daha gelişmiş ortamlarda Wazuh ajanı sunucuda çalışır, merkezi yönetim panelinden tüm sunucuların SSH log'larını korelasyonla analiz eder. SIEM görevi görür; tek sunucu ölçeğinde abartılı olsa da 5+ sunucu işleten ekipler için verimli.

Coğrafi IP Filtreleme

Eğer yalnızca Türkiye'den (veya birkaç ülkeden) erişim bekleyen bir sunucu işletiyorsanız (e-ticaret panel, iyzico/PayTR merchant admin gibi) GeoIP filtreleme ile SSH portunu yalnızca o ülkelere açabilirsiniz:

# ipset + iptables ile basit Türkiye whitelisting örneği
sudo apt install ipset xtables-addons-common
sudo ipset create tr_subnets hash:net
# Kaynak listeden TR subnet'lerini ipset'e doldurun
sudo iptables -I INPUT -p tcp --dport 22122 -m set ! --match-set tr_subnets src -j DROP

Coğrafi filtreleme botnet trafiğinin büyük çoğunluğunu (çoğu Çin, Brezilya, Rusya kaynaklı) keser. Ama VPN/proxy üzerinden Türkiye IP'sine çıkan herkes geçer; mutlak değil, ek katman.

cPanel Paylaşımlı Hosting Bağlamı

Buyukweb cPanel paylaşımlı hosting paketlerinde SSH yapılandırması sizin kontrolünüzde değildir; WHM yöneticisi seviyesinde belirlenir:

• Varsayılan port: 2222
• Kullanıcı bazlı port değişimi: yapılamaz; ortak SSH daemon ile çalışır
• WHM SSH Password Authorization Tweak: parola girişini WHM tarafı kapatır (önerilir)
• SSH key kabul etme: cPanel her kullanıcının kendi ~/.ssh/authorized_keys dosyasını yönetmesine izin verir (cPanel → SSH Access)
• Chroot kafesi: paylaşımlı SSH genellikle jailshell veya rbash benzeri kısıtlı kabukta çalışır

Paylaşımlı paket kullanıcısıysanız port değiştirme bu rehberin konusu değildir; bunun yerine güçlü parola + SSH key + WHM düzeyinde fail2ban yapılandırması yeterli olur (sunucu yöneticisi sizin için zaten kurmuştur). Tam kontrol istiyorsanız VDS sunucu paketlerine geçmeniz gerekir.

Buyukweb VDS Perspektifinden Önerilen Sıra

Yeni VDS açılışında SSH güvenliği için tavsiye ettiğimiz uygulama sırası:

1. İlk girişte parola değiştirin ve güçlü parola seçin
2. SSH anahtar oluşturun (ssh-keygen -t ed25519) ve ~/.ssh/authorized_keys ekleyin
3. Anahtar girişini test edin (yeni terminalde)
4. PasswordAuthentication no ve PermitRootLogin no uygulayın
5. fail2ban kurun ve sshd jail'ini etkinleştirin
6. Cloud firewall (Buyukweb panel) üzerinden 22'yi yalnızca kendi IP'nize açın
7. (Opsiyonel) Port değiştirme — defense-in-depth ek katman olarak; gürültü azaltıcı
8. (İleri) Port knocking veya fwknop SPA — yüksek değerli sunucu için
9. (İleri) WireGuard veya OpenVPN tünel — SSH'ı internetten gizlemek için
10. (Kurumsal) Bastion + ProxyJump — birden fazla iç sunucu varsa

KVM web konsol her zaman kurtarma yolunuzdur; ilk gün test edip tanıyın.

Yaygın Hatalar — Kendinizi Kilitlemeyin

Bu liste sysadmin'lerin SSH port değiştirirken en sık yaptığı hataları içerir. Her birini önceden okuyun:

1. Eski Port Satırını Silip Reload Yapmak

Port 22 satırını silip Port 22122 yazıp reload ettikten sonra mevcut bağlantı 22 üzerinde olsa bile sshd yeni reload sonrası yalnızca 22122'yi dinler ve eski bağlantınız komut yürütmeye devam edebilir ama yeni bağlantı kuramazsınız. Yeni port'u firewall'da açmayı unuttuysanız kendinizi kilitlersiniz. Çözüm: önce eski + yeni iki port aynı anda dinlesin, test sonrası eski'yi kaldırın.

2. SELinux Etiketlemesini Unutmak

RHEL/AlmaLinux/Rocky'de semanage port -a yapmazsanız sshd reload sonrası "Failed to bind to port 22122" hatası alır ve servis durur. Eski oturum devam edebilir ama yeni bağlantı imkansızdır. Çözüm: semanage port -a -t ssh_port_t -p tcp <yeni-port> adımını atlamayın.

3. Firewall'da Yeni Port'u Açmamak

UFW veya firewalld varsayılan olarak yalnızca açık portlara izin verir. Yeni port'u önceden açmadıysanız sshd dinlese bile dış istemci ulaşamaz. Çözüm: 1. adımı atlamayın.

4. Cloud Firewall'ı Güncellememek

Sunucu içi firewall ile sağlayıcı paneli cloud firewall ayrı katmanlardır. Yalnızca birini güncellerseniz yeni port'a hâlâ erişemezsiniz. Çözüm: Buyukweb panel ağ kuralları sayfasını da güncelleyin.

5. SCP/Rsync/Ansible Otomasyonunu Atlamak

Backup cron, Ansible playbook'ları, Git remote'ları, CI/CD pipeline'ları, IDE remote-SSH eklentileri — hepsi eski port'a sabit yazılmış olabilir. Port değişikliği sonrası bu otomasyonların hepsini test edin. Çözüm: ~/.ssh/config host alias kullanarak tek yerden yönetin.

6. fail2ban jail.local Güncellememek

Eski 22 portuna göre yapılandırılmış fail2ban yeni port'ta saldırı patternlarını yakalamaz. Çözüm: port = 22122 olarak güncelleyin ve reload edin.

7. KVM Konsol Erişimini Test Etmemek

İlk gün test etmediğiniz bir kurtarma yolu, ihtiyaç anında çalışmaz. Çözüm: yeni VDS'in ilk dakikalarında panel üzerinden KVM web konsola girip "ben buyum" testi yapın.

SSS — Sıkça Sorulan Sorular

1. SSH portunu sadece değiştirsem yetmez mi? Anahtar girişine geçmeden de iyi olur mu?

Hayır. Port değişikliği botnet trafiğini keser ama hedefli saldırgan port'u 1 dakikada bulur ve zayıf parolanız hâlâ savunmasızdır. Asıl koruma PasswordAuthentication no + SSH key + fail2ban'dadır. Port değişikliği yalnızca log gürültüsü azaltıcı bir katmandır; tek başına yetmez.

2. Hangi portu seçeyim? 2222 olur mu?

2222 cPanel/WHM'de yaygın olduğu için bot tarayıcılar artık düzenli tarar; 22'den temiz ama "popüler olmayan" değil. Tavsiye: 1024-49151 aralığında 5 haneli ve standart listelerde olmayan bir sayı (örneğin 22122, 50322, 64022). Ephemeral aralık (49152-65535) seçmeyin; istemci geçici port çakışması riski var.

3. Port knocking ile fail2ban'i birlikte kullanmak mantıklı mı?

Mantıklıdır ama tek başına port knocking daha iyi kurgulanırsa fail2ban gerekmeyebilir (saldırgan port'u zaten görmez). Yine de defense-in-depth açısından her ikisi birlikte daha güçlüdür: knockd dış görünürlüğü keser, fail2ban içeride başarısız denemeleri sınırlar. Modern uygulamalarda fwknop SPA + fail2ban kombinasyonu daha verimli ve güvenli.

4. VPN tünel kurmak port değişikliğine göre çok mu karmaşık?

İlk kurulumda evet, sonrasında değil. WireGuard 30-40 satır config ile çalışır; OpenVPN biraz daha geniş ama easyrsa script'leri çoğu işi otomatikleştirir. 3+ ekip üyesi veya 5+ sunucu varsa VPN yatırımı kesin geri döner: sertifika iptal etmek bir kullanıcının tüm SSH erişimini bir komutta keser. Sertifika dağıtımı ve KVM konsol fallback'ı kurulduktan sonra port değişikliğine göre çok daha güçlü bir mimari sunar.

5. SSH port'umu değiştirdikten sonra Buyukweb teknik desteği bağlanabilir mi?

Buyukweb VDS unmanaged teslim edilir; teknik destek sunucu içine doğrudan giriş yapmaz. Acil durum müdahale gerekirse sizin onayınızla KVM web konsol üzerinden işlem yapabilir veya sunucuyu rescue mode ile başlatıp dosya sistemine erişebilir. SSH port değişikliği destek sürecini etkilemez; tüm değişiklikleri kendiniz uygularsınız. Sorularınız için 0850 302 60 70 numaralı destek hattımıza ulaşabilirsiniz.

Sonuç

SSH port değiştirme tek başına bir güvenlik çözümü değildir; log gürültüsü azaltıcı, düşük vasıflı botnet trafiğini kesici ve defense-in-depth zincirinin bir halkası olarak değerlendirilmelidir. Asıl koruma katmanları parola girişini kapatmak, SSH anahtar tabanlı kimlik doğrulama, fail2ban ile reaktif IP ban, sshd_config sertleştirmesi ve cloud firewall whitelist'tir. Yüksek değerli sunucularda port knocking (knockd) veya Single Packet Authorization (fwknop) ile SSH'ı internet'ten gizlemek mümkündür; en güçlü mimari ise WireGuard veya OpenVPN tüneli üzerinden SSH'ı yalnızca VPN subnet'inden erişilebilir hale getirmektir. Birden fazla iç sunucu yöneten ekipler için bastion host + ProxyJump kalıbı klasik standarttır.

Bu rehberdeki adımları uygularken her zaman KVM web konsol kurtarma yolunu hatırlayın; SSH yapılandırmasında kendinizi kilitlerseniz panel üzerinden konsola düşüp düzeltebilirsiniz. Buyukweb E5-V4 VDS paketleri Bursa Tier 3 datacenter'da unmanaged teslim edilir, root erişim sizin kontrolünüzdedir ve port değiştirme gibi tüm sistem yönetimi işlemlerini kısıtlamasız yapabilirsiniz.

İlgili Buyukweb hizmetleri:

• E5-V4 VDS Sunucu Paketleri — root erişim, KVM konsol, Tier 3 Bursa
• Fiziksel Dedicated Sunucu — IPMI, tam donanım
• cPanel Web Hosting — paylaşımlı paket, SSH 2222 default
• Tüm Paket Karşılaştırma

Detaylı bilgi ve destek için 0850 302 60 70 numaralı hattımızı arayabilir veya iletişim sayfamızdan yazabilirsiniz.