Yeni sunucuyu teslim aldınız, ilk kez journalctl -u sshd çalıştırdınız ve ekran akmaya başladı: Failed password for root from 45.x.x.x, Invalid user admin from 103.x.x.x, dakikada onlarca satır. Sunucu daha yayına bile girmemişken binlerce giriş denemesi görmek insanı haklı olarak tedirgin ediyor ve ilk refleks hep aynı oluyor: SSH portunu değiştirmek. SSH port değiştirme işlemi doğru yapıldığında bu gürültünün neredeyse tamamını keser; yanlış sırayla yapıldığında ise sizi kendi sunucunuzun dışında bırakır. Yıllardır en sık gördüğüm destek talebi de tam olarak bu: "ssh port değiştirdim bağlanamıyorum".
Bu yazıda 22 portunu kapatma işlemini kilitlenmeden yapmanın doğru sırasını anlatacağım: önce güvenlik duvarında yeni portu açmak, AlmaLinux/Rocky Linux tarafında SELinux'un portu reddetmesini semanage port ile çözmek, yeni Ubuntu sürümlerinde sshd_config içindeki Port satırının neden hiçbir işe yaramadığı ve socket aktivasyonunun nasıl düzenleneceği. Sonunda da kimsenin söylemediği şeyi söyleyeceğim: port değiştirmek bir güvenlik önlemi değildir, sadece bir gürültü filtresidir — ve onun yerine geçmesi gereken asıl önlemler bellidir.
Port Değiştirmek Gerçekten Güvenlik Sağlar mı#
Hayır; port değiştirmek saldırı yüzeyini küçültmez, sadece otomatik tarama botlarının kayıtlarınızı doldurmasını engeller. Bunu net anlamak önemli, çünkü "portu değiştirdim, artık güvendeyim" diyerek parola girişini açık bırakan yüzlerce sunucu gördüm.
Gerçekte olan şudur: internetteki toplu tarayıcılar tüm IPv4 adres uzayını 22 portundan tarar ve bulduğu her SSH servisine sözlük saldırısı dener. Portu 2222'ye aldığınızda bu geniş taramaların dışında kalırsınız ve auth.log dosyanız temizlenir. Ama sizi hedef alan biri, tüm portları tarayan bir araçla saniyeler içinde SSH'ın 2222'de dinlediğini bulur — üstelik SSH banner'ı (SSH-2.0-OpenSSH_9.6) kendini tanıtır, hangi portta olduğu fark etmez.
O halde port değiştirmenin gerçek faydası nedir? Üç somut kazanç var:
- Log gürültüsü biter.
fail2bangibi araçların işlemesi gereken satır sayısı düşer, gerçek bir anomaliyi gözle fark edebilirsiniz. - CPU ve bant genişliği tasarrufu. Saniyede birkaç bağlantı isteği küçük bir sunucuda ölçülebilir yük demektir; her istek TCP el sıkışması ve kripto anlaşması başlatır.
- Bazı ağlarda erişim kolaylaşır. Kurumsal ağların ve otel/kafe Wi-Fi'larının çıkışta 22 portunu kapattığını çok gördüm; SSH'ı 443'e taşımak bu ağlardan bağlanabilmenizi sağlar.
Kazanç bu kadar. Kimlik doğrulamayı sertleştirmediğiniz sürece port değişikliği kozmetiktir. Asıl önlemleri yazının sonunda ayrı bir bölümde topladım.
SSH Portunu Değiştirmenin Doğru Sırası#
Kilitlenmelerin tamamı sıra hatasından çıkar. Doğru sıra şudur ve hiçbir adımı atlamayın:
-
Yeni portu önce güvenlik duvarında açın.
-
RHEL ailesindeyseniz (AlmaLinux, Rocky, CentOS) SELinux'a portu tanıtın.
-
sshd_configiçine yeni portu ekleyin ama 22'yi henüz silmeyin; ikisi bir süre birlikte dinlesin. -
Yapılandırmayı
sshd -tile sözdizimi açısından test edin. -
Servisi yeniden başlatın.
-
Mevcut oturumu kapatmadan ikinci bir terminalden yeni porttan bağlanın.
-
Yeni port çalışıyorsa 22'yi
sshd_config'den ve güvenlik duvarından kaldırın. -
adım pazarlık konusu değil. Açık SSH oturumu, yapılandırma bozulduğunda elinizde kalan tek kurtarma yoludur; onu kapattığınız anda sunucu sağlayıcınızın konsol/VNC ekranına muhtaç kalırsınız.
Port seçerken 1024 üzerindeki bir değeri tercih edin (1024 altı portlar ayrıcalıklı portlardır ve başka servislerle çakışabilir). 2222 yaygın olduğu için tarayıcıların ikinci hedefidir; 22022, 49222 gibi daha az öngörülebilir bir değer daha çok gürültü keser. Seçeceğiniz portun boş olduğunu şununla doğrulayın:
ss -tlnp | grep :22022
Çıktı boşsa port müsaittir. Hangi portların kullanımda olduğunu ve neyin neden açık kalması gerektiğini sunucuda hangi portlar açık olmalı yazısında ayrıntılı ele aldım.
Adım 1: Güvenlik Duvarında Yeni Portu Açın#
En sık yapılan hata bu adımın atlanmasıdır: sshd_config düzenlenir, servis yeniden başlatılır, SSH artık 22022'de dinlemektedir ama güvenlik duvarı o portu bilmediği için paketleri sessizce düşürür. Sonuç: bağlantı zaman aşımına uğrar, hiçbir hata mesajı gelmez, sunucu erişilemez hale gelir.
Dağıtımınıza göre komut:
# Ubuntu / Debian (ufw)
sudo ufw allow 22022/tcp comment 'SSH yeni port'
sudo ufw status numbered
# AlmaLinux / Rocky / CentOS (firewalld)
sudo firewall-cmd --permanent --add-port=22022/tcp
sudo firewall-cmd --reload
sudo firewall-cmd --list-ports
# nftables kullanan sistemler
sudo nft add rule inet filter input tcp dport 22022 accept
ufw status çıktısında yeni portu ALLOW IN olarak görmeden devam etmeyin. UFW kurallarının mantığını ve varsayılan politikanın nasıl ayarlandığını ufw güvenlik duvarı yazısında adım adım anlattım.
Ayrıca bir katman daha var ki genelde unutulur: birçok sağlayıcının panelinde, sunucunun kendi işletim sistemi güvenlik duvarından ayrı bir ağ güvenlik duvarı bulunur. Sunucu içinde portu açsanız bile sağlayıcı tarafındaki kural setinde açık değilse paket sunucuya hiç ulaşmaz. Bağlanamıyorsanız panelde böyle bir bölüm olup olmadığını mutlaka kontrol edin.
Adım 2: AlmaLinux ve Rocky Linux'ta SELinux İzni#
RHEL ailesinde SELinux varsayılan olarak enforcing modda çalışır ve sshd sürecinin yalnızca ssh_port_t etiketli portları dinlemesine izin verir. Bu etikete sahip olmayan bir porta geçtiğinizde servis yeniden başlatma komutu hata verir ve SSH hiç ayağa kalkmaz.
Tipik hata çıktısı şuna benzer:
error: Bind to port 22022 on 0.0.0.0 failed: Permission denied.
fatal: Cannot bind any address.
"Permission denied" ifadesi burada dosya izniyle ilgili değildir; SELinux politikasıdır. Önce durumu doğrulayın:
getenforce
sudo semanage port -l | grep ssh
İkinci komut ssh_port_t tcp 22 satırını gösteriyorsa yeni portu eklemeniz gerekir:
# semanage komutu yoksa önce paketi kurun
sudo dnf install -y policycoreutils-python-utils
sudo semanage port -a -t ssh_port_t -p tcp 22022
sudo semanage port -l | grep ssh
Artık çıktıda ssh_port_t tcp 22022, 22 görmelisiniz. Port zaten başka bir tipe atanmışsa -a yerine -m (modify) kullanmanız gerekir:
sudo semanage port -m -t ssh_port_t -p tcp 22022
SELinux'u devre dışı bırakmak bu sorunu "çözer" ama sunucunun en güçlü zorunlu erişim denetimi katmanını kapatmış olursunuz; asla önerdiğim bir yol değil. SELinux'un mantığını ve audit.log okumayı selinux temelleri ve yönetimi yazısında ayrıca ele aldım.
Ubuntu ve Debian'da AppArmor kullanılır ve AppArmor'un varsayılan SSH profili port kısıtlaması yapmaz; bu adımı atlayabilirsiniz.
| Dağıtım | Güvenlik duvarı komutu | SELinux adımı gerekli mi | Servis adı |
|---|---|---|---|
| Ubuntu / Debian | ufw allow 22022/tcp | Hayır (AppArmor kısıtlamaz) | ssh |
| AlmaLinux / Rocky / CentOS Stream | firewall-cmd --permanent --add-port=22022/tcp | Evet (semanage port -a) | sshd |
| Fedora | firewall-cmd --permanent --add-port=22022/tcp | Evet | sshd |
| Alpine | iptables -A INPUT -p tcp --dport 22022 -j ACCEPT | Hayır | sshd |
Adım 3: sshd_config Dosyasını Düzenleme#
Yapılandırma dosyası /etc/ssh/sshd_config yolundadır. Düzenlemeden önce yedek alın:
sudo cp /etc/ssh/sshd_config /etc/ssh/sshd_config.bak
sudo nano /etc/ssh/sshd_config
Port 22 satırını bulun. Genelde başında # ile yorum satırı halindedir. Onu olduğu gibi bırakıp altına yenisini ekleyin:
Port 22
Port 22022
Evet, iki satır. Geçiş süresince SSH her iki portu da dinler; yeni portun çalıştığını doğruladıktan sonra Port 22 satırını silersiniz. Bu, kilitlenme riskini tek başına ortadan kaldıran en basit önlemdir.
Modern dağıtımlarda ek bir tuzak var: sshd_config dosyasının sonunda genelde şu satır bulunur:
Include /etc/ssh/sshd_config.d/*.conf
Bu dizindeki bir dosya sizin Port tanımınızı ezebilir. OpenSSH'ta ilk okunan değer kazanır ve Include satırı dosyanın başındaysa alt dizindeki dosya sizin ayarınızdan önce işlenir. Kontrol edin:
sudo grep -r "^Port" /etc/ssh/sshd_config /etc/ssh/sshd_config.d/ 2>/dev/null
Birden fazla Port tanımı çıkıyorsa hangisinin geçerli olduğunu tahmin etmeyin, doğrudan sorun:
sudo sshd -T | grep -i "^port"
sshd -T etkin yapılandırmayı çözümlenmiş haliyle basar; ekranda ne yazıyorsa servis onu uygular.
Adım 4: Test Edin ve Servisi Yeniden Başlatın#
Yeniden başlatmadan önce sözdizimini test edin. Bu tek komut sayısız kilitlenmeyi önler:
sudo sshd -t
Çıktı boşsa yapılandırma geçerlidir. Hata varsa satır numarasıyla birlikte söyler ve düzeltmeden devam etmezsiniz.
Sonra servisi yeniden başlatın:
# Debian / Ubuntu
sudo systemctl restart ssh
# AlmaLinux / Rocky / CentOS
sudo systemctl restart sshd
Yeniden başlatmak mevcut SSH oturumunuzu düşürmez; açık oturumlar ayrı süreçlerde devam eder. Bu yüzden mevcut terminali kapatmayın.
Şimdi dinlenen portu doğrulayın:
sudo ss -tlnp | grep sshd
Beklenen çıktı:
LISTEN 0 128 0.0.0.0:22 0.0.0.0:* users:(("sshd",pid=812,fd=3))
LISTEN 0 128 0.0.0.0:22022 0.0.0.0:* users:(("sshd",pid=812,fd=4))
İki satır da görünüyorsa ikinci bir terminal açın ve yeni porttan bağlanın:
ssh -p 22022 kullanici@sunucu-ip
Bağlantı başarılıysa sshd_config içinden Port 22 satırını silin, servisi tekrar başlatın ve güvenlik duvarından 22'yi kapatın:
sudo ufw delete allow 22/tcp
# veya
sudo firewall-cmd --permanent --remove-service=ssh && sudo firewall-cmd --reload
firewall-cmd tarafında dikkat: ssh servisi varsayılan olarak açıktır ve 22 portuna karşılık gelir; sadece portu kaldırmak yetmez, servisi de kaldırmanız gerekir.
Yeni Ubuntu Sürümlerinde Socket Aktivasyonu Tuzağı#
Bu, son yıllarda en çok kafa karıştıran değişiklik. Ubuntu'nun yeni sürümlerinde SSH artık systemd socket aktivasyonuyla çalışabiliyor: bağlantı isteğini ssh.socket birimi karşılıyor, sshd yalnızca istek geldiğinde ayağa kalkıyor. Bu modda sshd_config içindeki Port satırı tamamen yok sayılır. Portu değiştirir, servisi yeniden başlatır ve ss çıktısında hâlâ 22 görürsünüz — hiçbir şey anlamazsınız.
Önce hangi modda olduğunuzu tespit edin:
systemctl is-enabled ssh.socket
systemctl status ssh.socket
enabled veya active dönüyorsa socket aktivasyonu devrededir. Bu durumda portu socket biriminden değiştirirsiniz:
sudo systemctl edit ssh.socket
Açılan düzenleyiciye şunu yazın (boş ListenStream= satırı önceki değeri sıfırlar, yazmazsanız iki port birden dinlenir):
[Socket]
ListenStream=
ListenStream=22022
Kaydedip uygulayın:
sudo systemctl daemon-reload
sudo systemctl restart ssh.socket
sudo ss -tlnp | grep :22022
Socket aktivasyonunu tamamen kapatıp klasik davranışa dönmek isterseniz:
sudo systemctl disable --now ssh.socket
sudo systemctl enable --now ssh.service
Bu geçişi yaparken de yine açık bir oturum bulundurun.
SSH Port Değiştirdim Bağlanamıyorum: Teşhis Sırası#
Bağlantı kurulamıyorsa aldığınız hata mesajı hangi katmanda takıldığınızı söyler. Sırayla eleyin:
| Belirti | Muhtemel neden | Kontrol |
|---|---|---|
Connection timed out | Güvenlik duvarı paketi düşürüyor (sunucu içi veya sağlayıcı paneli) | ufw status, sağlayıcı panelindeki ağ kuralları |
Connection refused | Port açık ama o portta dinleyen servis yok | ss -tlnp | grep sshd |
Permission denied (servis başlarken) | SELinux portu reddediyor | semanage port -l | grep ssh |
| Eski porttan bağlanıyor, yenisi çalışmıyor | sshd_config.d/ altında ezen tanım veya socket aktivasyonu | sshd -T | grep port, systemctl status ssh.socket |
Sunucudan localhost ile bağlanılıyor, dışarıdan bağlanılmıyor | Güvenlik duvarı veya ListenAddress kısıtlaması | sshd -T | grep listenaddress |
| Hiçbir port yanıt vermiyor, ping de gitmiyor | Sunucu kapalı veya ağ arayüzü düşmüş | Sağlayıcı konsolu/VNC |
Kendi tarafınızı da eleyin: bulunduğunuz ağdan belirli portlar kapalı olabilir. Farklı bir ağdan (örneğin mobil veri) deneyin veya dışarıdan port erişimini test edin. Zaman aşımı hatasının katman katman çözümünü err connection timed out hatası yazısında ayrıca inceledim; bağlantı kuramadığınızda izlenecek tam akış ise sunucuma bağlanamıyorum yazısında.
Tamamen kilitlendiyseniz tek yol sağlayıcının konsol/VNC erişimidir. Oradan root ile girip yedeklediğiniz dosyayı geri alın:
cp /etc/ssh/sshd_config.bak /etc/ssh/sshd_config
systemctl restart sshd
Port Değiştirmenin Yerine Geçmeyecek Asıl Önlemler#
Portu değiştirdiniz, loglar temizlendi. Şimdi gerçek işi yapın; bunlar olmadan port değişikliği sadece kozmetiktir:
1. Parola girişini tamamen kapatın. SSH anahtarı oluşturup yükledikten sonra:
PasswordAuthentication no
KbdInteractiveAuthentication no
PubkeyAuthentication yes
Bu üç satır, sözlük saldırısı kavramını sunucunuz için anlamsız hale getirir. Anahtar üretme ve yükleme adımlarını ssh anahtarı nasıl oluşturulur yazısında bulabilirsiniz.
2. Root ile doğrudan girişi kapatın.
PermitRootLogin no
Saldırganın önce geçerli bir kullanıcı adı bilmesi gerekir; root herkesin bildiği tek isimdir. Yetkili kullanıcıyla çalışma düzenini root yerine kullanıcı ile çalışmak yazısında anlattım.
3. fail2ban kurun. Port değişse de değişmese de tekrarlayan başarısız denemeleri IP bazında engeller. Kurulumu fail2ban kurulumu yazısında.
4. Erişimi IP ile sınırlayın. Sabit IP'niz varsa SSH'ı yalnızca oradan açın; bu, port değiştirmekten kat kat etkilidir:
sudo ufw allow from 203.0.113.10 to any port 22022 proto tcp
5. Bastion/jump host kullanın. Birden fazla sunucunuz varsa hepsini internete açmak yerine tek bir giriş noktası üzerinden yönetin; yöntemi ssh jump host bastion sunucu yazısında.
Bu beş maddeden ilk ikisi uygulandığında, portunuz 22'de kalsa bile saldırı yüzeyiniz port değiştirmekle elde edeceğinizden çok daha küçüktür.
Sıkça Sorulan Sorular#
SSH portunu değiştirdikten sonra eski porttan bağlanabilir miyim#
Hayır, sshd_config içinden Port 22 satırını sildiyseniz eski port artık dinlenmez ve bağlantı Connection refused ile reddedilir. Geçiş sürecinde iki Port satırını birlikte tutmanızın nedeni tam olarak budur: yeni portun çalıştığını doğrulayana kadar eski yol açık kalır. Doğrulama tamamlandıktan sonra 22'yi hem yapılandırmadan hem güvenlik duvarından kaldırmanız gerekir; yalnızca birinden kaldırmak yarım iş olur. Güvenlik duvarında ssh servisi tanımı varsa onu da kaldırmayı unutmayın.
Hangi port numarasını seçmeliyim#
1024 üzerinde, başka bir servisle çakışmayan ve yaygın olmayan bir değer seçin. 2222 en sık kullanılan alternatif olduğu için tarayıcıların ikinci hedefidir; 22022 veya 49222 gibi tahmin edilmesi zor bir sayı daha çok gürültü keser. Bulunduğunuz ağ 22 portunu kapatıyorsa 443'ü kullanmak pratik bir çözümdür, ancak sunucuda HTTPS servisi varsa o port zaten doludur. Seçmeden önce ss -tlnp | grep :PORT ile boş olduğunu doğrulayın.
SELinux hatası almamak için SELinux'u kapatabilir miyim#
Teknik olarak kapatabilirsiniz ama kesinlikle önermiyorum; SELinux, bir servis ele geçirildiğinde saldırganın sistemin geri kalanına yayılmasını engelleyen en güçlü katmandır. Doğru çözüm semanage port -a -t ssh_port_t -p tcp <port> komutuyla yeni portu politikaya tanıtmaktır ve bu tek satırlık bir iştir. policycoreutils-python-utils paketi kurulu değilse dnf install ile eklemeniz gerekir. Kapatmak yerine tanıtmak, ileride başka servislerde de karşılaşacağınız aynı sınıf sorunun kalıcı çözümüdür.
Port değiştirince fail2ban kurmama gerek kalır mı#
Gerek kalır; port değişikliği yalnızca rastgele tarayıcıları eler, hedefli denemeleri engellemez. fail2ban belirli sayıda başarısız denemeden sonra IP'yi güvenlik duvarı seviyesinde engelleyerek gerçek bir bariyer kurar. Kurulumdan sonra jail.local dosyasındaki port değerini yeni portunuza güncellemeyi unutmayın, aksi halde fail2ban 22 portunu izlemeye devam eder ve hiçbir şeyi engellemez. En sağlam kombinasyon anahtar tabanlı giriş, kapalı parola doğrulaması ve fail2ban üçlüsüdür.
SFTP ve SCP bağlantıları da yeni portu kullanacak mı#
Evet, SFTP ve SCP aynı SSH servisi üzerinden çalıştığı için otomatik olarak yeni portu kullanmaları gerekir, ancak port numarasını istemciye elle bildirmeniz şarttır. Komut satırında scp için büyük -P, sftp için de -P parametresi kullanılır: scp -P 22022 dosya.txt kullanici@sunucu:/yol/. FileZilla gibi grafik istemcilerde sunucu adresinin yanındaki port alanına yeni değeri yazmanız yeterlidir. Her seferinde yazmamak için istemci makinenizde ~/.ssh/config dosyasına Host sunucu bloğu altında Port 22022 tanımlayabilirsiniz.
Bağlantı zaman aşımına uğruyor ama servis çalışıyor görünüyor#
Bu tablonun neredeyse tek sebebi güvenlik duvarıdır; Connection timed out mesajı paketin hedefe hiç ulaşmadığını, Connection refused ise ulaştığını ama dinleyen olmadığını söyler. Önce sunucu içinde ufw status veya firewall-cmd --list-all ile yeni portun izinli olduğunu doğrulayın. Orada sorun yoksa sağlayıcınızın panelindeki ağ güvenlik duvarını kontrol edin; işletim sistemi dışında ikinci bir filtre katmanı bulunması çok yaygındır. Son olarak bulunduğunuz ağın çıkışta o portu kapatmadığından emin olmak için farklı bir bağlantıdan deneyin.
Değişikliği geri almam gerekirse ne yapmalıyım#
Yedeklediğiniz dosyayı geri kopyalayıp servisi yeniden başlatmanız yeterlidir: cp /etc/ssh/sshd_config.bak /etc/ssh/sshd_config && systemctl restart sshd. SSH erişiminiz tamamen kesildiyse bu işlemi sağlayıcınızın konsol veya VNC ekranından yaparsınız; panel üzerinden açılan bu ekran ağdan bağımsız çalıştığı için güvenlik duvarı hatalarından etkilenmez. RHEL ailesinde ayrıca eklediğiniz SELinux port kaydını semanage port -d -t ssh_port_t -p tcp 22022 ile silebilirsiniz. Geri dönüşten sonra 22 portunun güvenlik duvarında yeniden açık olduğunu doğrulayın.
Kapanış#
SSH port değiştirme işlemi tek satırlık bir düzenleme değil, dört katmanın uyumlu çalışmasını gerektiren küçük bir operasyondur: güvenlik duvarı, SELinux, sshd_config ve yeni sistemlerde systemd socket birimi. Sırayı doğru uyguladığınızda — önce firewall, sonra SELinux, sonra yapılandırma, en son eski portun kapatılması — kilitlenme ihtimali pratikte sıfıra iner. Ve unutmayın: bu işlem log gürültüsünü keser, sunucunuzu güvenli hale getirmez. Asıl güvenliği parola girişini kapatmak, root erişimini kısıtlamak, fail2ban çalıştırmak ve mümkünse SSH'ı sabit IP'nize kilitlemek sağlar.
Bu işlemleri kendi başınıza yapmak istiyorsanız tam yetkili bir ortama ihtiyacınız var; VDS sunucu paketlerinde root erişimi ve panel üzerinden konsol/VNC bağlantısı bulunduğu için yanlış bir kural yüzünden kilitlendiğinizde sunucuya yine ulaşabilirsiniz. Farklı sunucu tiplerini karşılaştırmak isterseniz sunucu çözümleri sayfasına göz atabilir, sertleştirme ve güvenlik duvarı yapılandırmasını uzmanların üstlenmesini tercih ederseniz sunucu yönetimi hizmetini inceleyebilirsiniz. Güçlü ve tahmin edilemez parolalar üretmek için de şifre üretici aracını kullanabilirsiniz.