SSH Connection Refused Hatası Nasıl Çözülür? Linux SSH Erişim Rehberi

SSH Connection refused hatası, istemcinin hedef IP adresine ulaştığını ancak hedef portta bağlantıyı kabul eden bir SSH hizmeti bulamadığını gösterir. Bu hata çoğunlukla sshd servisinin durmuş olması, servisin beklenen portta dinlememesi, güvenlik duvarının bağlantıyı açıkça reddetmesi veya bulut sağlayıcısındaki ağ kuralının yanlış yapılandırılması nedeniyle oluşur. Ağ gecikmesini ifade eden Connection timed out hatasından farklı olarak, burada TCP bağlantısı hedef tarafından reddedilir. Bu rehberde Linux sunucularda SSH Connection refused hatasını, mevcut erişimi riske atmadan servis, port, firewall ve yapılandırma katmanlarında adım adım teşhis edip gidereceksiniz.

Belirti ve kapsam: “Connection refused” ne anlama gelir?

Hata çoğunlukla aşağıdaki biçimlerden biriyle görünür:

ssh: connect to host 203.0.113.10 port 22: Connection refused

kex_exchange_identification: Connection closed by remote host

İlk mesaj, istemcinin hedefe TCP SYN paketi gönderdiğini ve hedef ağ yığınının RST paketiyle bağlantıyı reddettiğini düşündürür. Başka bir deyişle IP adresi yönlendirilebilir olabilir; fakat SSH için kullanılan portta erişilebilir bir dinleyici yoktur veya bir güvenlik politikası bağlantıyı reject eder.

Bu durum henüz kullanıcı adı, parola, SSH anahtarı ya da PermitRootLogin aşamasına gelinmediği anlamına gelir. Dolayısıyla önce kimlik doğrulama ayarlarına değil, servis ve ağ erişimine odaklanın.

SSH Connection refused hatası için hızlı teşhis özeti

• Hedef IP ve portun doğru olduğundan emin olun.
• İstemciden ayrıntılı SSH çıktısı ve TCP port testi alın.
• Sunucu konsolu, KVM/IPMI, seri konsol veya sağlayıcı kurtarma konsolu ile sunucuya erişin.
• sshd servisinin çalıştığını ve doğru IP/portta dinlediğini doğrulayın.
• İşletim sistemi firewall’ı, bulut güvenlik grubu ve varsa ağ ACL kurallarını kontrol edin.
• Yapılandırma değişikliğinden önce sözdizimi testi yapın; çalışan SSH oturumunu kapatmadan yeniden yükleme uygulayın.

Gözlem	Muhtemel katman	İlk kontrol
Yalnızca 22 numaralı port reddediliyor	sshd veya yerel firewall	systemctl status, ss -ltnp
Özel portta çalışması gerekirken 22 deneniyor	İstemci hedefi veya sshd yapılandırması	ssh -p PORT, Port ayarı
İç ağdan erişiliyor, internetten reddediliyor	Bulut güvenlik grubu, edge firewall veya NAT	Sağlayıcı ağ kuralları ve public IP eşlemesi
Servis yeniden başlatma sonrası reddediliyor	Geçersiz SSH yapılandırması veya servis hatası	sshd -t, journal kayıtları
Yalnızca IPv6 adresinde reddediliyor	Adres ailesi veya IPv6 firewall	ss -ltnp, IPv6 kural seti

Olası nedenler

SSH servisi durmuş veya başlatılamıyor olabilir

Paket güncellemesi, hatalı yapılandırma, disk alanı sorunu ya da başarısız bir servis işlemi sshd sürecini durdurabilir. Bazı Debian/Ubuntu sistemlerinde systemd birim adı ssh, RHEL türevlerinde ise genellikle sshd olur.

SSH beklenen portta veya doğru ağ adresinde dinlemiyor olabilir

Sunucu SSH’ı 22 yerine farklı bir portta dinliyor olabilir. Ayrıca ListenAddress ayarı yalnızca bir özel IP’ye bağlanmışsa, public IP üzerinden gelen bağlantı reddedilebilir. IPv4 ve IPv6 dinleme davranışı da ayrı incelenmelidir.

Firewall veya bulut ağ kuralı bağlantıyı reddediyor olabilir

ufw, firewalld veya doğrudan nftables/iptables kuralları SSH portunu reddedebilir. Sanal sunucularda işletim sistemi firewall’ına ek olarak sağlayıcı panelindeki güvenlik grubu, güvenlik duvarı ya da ACL kuralı da etkili olabilir. Yanlış hedef IP’ye yönlendiren NAT yapılandırması da aynı belirtiyi üretebilir.

Hatalı sshd yapılandırması yeni servisin açılmasını engellemiş olabilir

sshd_config dosyası veya dahil edilen ek yapılandırma dosyalarındaki bir sözdizimi hatası, yeniden başlatma sonrasında SSH servisinin çalışmamasına neden olabilir. Yapılandırma test edilmeden yapılan yeniden başlatmalar bu yüzden risklidir.

Log ve bağlantı teşhis komutları

Önce kendi yönetim bilgisayarınızdan doğru hedefe bağlandığınızı kontrol edin. Özel port kullanılıyorsa hem SSH hem de port testi için aynı portu yazın:

ssh -vvv -p 22 kullanici@203.0.113.10
nc -vz -w 5 203.0.113.10 22

nc kurulu değilse, Bash destekleyen bir istemcide aşağıdaki test kullanılabilir:

timeout 5 bash -c '</dev/tcp/203.0.113.10/22'

Sunucuya ağ dışı konsoldan eriştikten sonra servis adını sisteminize göre kontrol edin:

sudo systemctl status ssh
sudo systemctl status sshd

Aktif TCP dinleyicilerini ve SSH sürecinin hangi adreste çalıştığını görüntüleyin:

sudo ss -ltnp | grep -E '(:22|sshd)'
sudo ss -ltnp

22 yerine özel port kullanıyorsanız komuttaki :22 kısmını o portla değiştirin. Beklenen sonuç, ilgili portta LISTEN durumunda bir sshd süreci görülmesidir.

Servis günlükleri dağıtıma göre journal üzerinden güvenle incelenebilir:

sudo journalctl -u ssh -b --no-pager
sudo journalctl -u sshd -b --no-pager
sudo journalctl -xe --no-pager

Yapılandırmanın geçerliliğini, hiçbir ayarı değiştirmeden test edin:

sudo sshd -t

Komut çıktı üretmeden sıfır durum koduyla biterse temel sözdizimi geçerlidir. Hata dönerse bildirilen dosya ve satırı düzeltmeden servisi yeniden başlatmayın.

Güvenli adım adım çözüm

1. Bakım ve geri dönüş koşullarını hazırlayın

SSH yapılandırması veya firewall üzerinde değişiklik yapmadan önce çalışan bir SSH oturumunu açık tutun. Mümkünse ikinci bir oturum açın ve sağlayıcınızın web konsolu, seri konsol veya KVM erişiminin çalıştığını doğrulayın. Uzak ve kritik sistemlerde değişiklik için bakım penceresi planlayın.

Yapılandırma dosyasında düzenleme yapacaksanız önce yedek alın. Yaygın OpenSSH yapılandırma yolu aşağıdaki gibidir; sisteminizde farklı bir düzen varsa kendi etkin dosya yapınızı esas alın:

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

2. SSH servisini başlatın ve kalıcı olarak etkinleştirin

Önce sisteminizde geçerli birim adını belirleyin. Debian ve Ubuntu’da çoğu kurulumda:

sudo systemctl enable --now ssh
sudo systemctl status ssh --no-pager

RHEL, AlmaLinux, Rocky Linux ve benzeri sistemlerde çoğunlukla:

sudo systemctl enable --now sshd
sudo systemctl status sshd --no-pager

Servis başlamıyorsa journalctl çıktısındaki hatayı çözün. Özellikle sshd -t başarısızsa yalnızca servisi tekrar tekrar başlatmak sorunu gidermeyecektir.

3. Port ve dinleme adresini doğrulayın

ss -ltnp çıktısında servis yalnızca 127.0.0.1:22 üzerinde dinliyorsa, uzaktan erişim kabul edilmez. Bu durumda etkin SSH yapılandırmasındaki ListenAddress, Port ve AddressFamily seçeneklerini dikkatle gözden geçirin. Birden fazla yapılandırma parçası kullanılıyorsa etkin ayarın hangi dosyadan geldiğini ayrıca doğrulayın.

Değişiklik yaptıktan sonra önce test edin, sonra yeniden başlatmak yerine yapılandırmayı yeniden yükleyin:

sudo sshd -t
sudo systemctl reload ssh

RHEL türevlerinde son komut genellikle şöyledir:

sudo sshd -t
sudo systemctl reload sshd

Not: Portu değiştirdiyseniz istemcide yeni portu açıkça belirtin:

ssh -p 2222 kullanici@203.0.113.10

4. İşletim sistemi firewall kuralını kontrol edin

Yalnızca sisteminizde aktif olarak kullanılan firewall aracını yönetin. Aynı anda birden fazla araçta gelişigüzel kural eklemek, teşhisi zorlaştırır.

Ubuntu/Debian üzerinde UFW etkinse durumunu görüntüleyin ve yalnızca gereken yönetim kaynağına izin verin:

sudo ufw status numbered
sudo ufw allow from YONETIM_IP_ADRESINIZ to any port 22 proto tcp
sudo ufw status verbose

Firewalld kullanan sistemlerde kalıcı kural eklemek için:

sudo firewall-cmd --get-active-zones
sudo firewall-cmd --list-services
sudo firewall-cmd --permanent --add-service=ssh
sudo firewall-cmd --reload

Özel SSH portu kullanılıyorsa servis adı yerine gerekli TCP portunu tanımlayın:

sudo firewall-cmd --permanent --add-port=2222/tcp
sudo firewall-cmd --reload

Nftables veya iptables kullanan sunucularda önce mevcut kuralları okuyun; dağıtıma özgü kalıcılık mekanizmasını doğrulamadan doğrudan kural silmeyin:

sudo nft list ruleset
sudo iptables -S

5. Bulut ve SELinux katmanını unutmayın

Sunucu bir VDS veya bulut örneğiyse, sağlayıcı panelindeki inbound kuralında doğru public IP, TCP protokolü ve SSH portunun tanımlı olduğundan emin olun. Güvenlik kuralını geçici olarak tüm internete açmak yerine yönetim IP adresinizi kaynak olarak sınırlayın.

SELinux etkin RHEL tabanlı sistemlerde, standart dışı SSH portunun SELinux tarafından izinli olması gerekir. Önce durumu kontrol edin:

getenforce
sudo semanage port -l | grep ssh_port_t

semanage komutu sistemde yoksa ilgili yönetim aracını dağıtımınızın paket yöneticisiyle kurmanız gerekir. Özel portu eklemeden önce portun başka bir SELinux türüne atanmadığını ve SSH’ın gerçekten o portta dinlediğini doğrulayın.

Çözümün doğrulanması

Sunucu tarafında dinleme durumu ve servis sağlığı doğrulandıktan sonra, ayrı bir istemci terminalinden bağlantıyı deneyin. Mevcut yönetim oturumunu başarılı yeni oturum açılana kadar kapatmayın:

nc -vz -w 5 203.0.113.10 22
ssh -o ConnectTimeout=10 -p 22 kullanici@203.0.113.10

Port testi başarılı olup SSH girişinde parola veya anahtar doğrulama mesajı görülüyorsa, SSH Connection refused hatası çözülmüş; süreç kimlik doğrulama aşamasına ilerlemiş demektir. Port hâlâ reddediliyorsa tekrar ss -ltnp çıktısını, aktif firewall kuralını ve sağlayıcı ağ kuralını aynı port numarasıyla karşılaştırın.

Tekrarını önlemek için öneriler

• SSH yapılandırma değişikliklerinde her zaman sshd -t çalıştırın ve mümkünse restart yerine reload kullanın.
• SSH portu, firewall kuralı, güvenlik grubu ve otomasyon betiklerinde aynı port bilgisinin kullanıldığını belgeleyin.
• Firewall’da SSH erişimini yalnızca sabit yönetim IP’leri veya güvenilir VPN ağıyla sınırlandırın.
• Bulut konsolu veya out-of-band erişimi acil durumlar için düzenli aralıklarla test edin.
• Yapılandırma yedeklerini ve değişiklik kayıtlarını güvenli bir yerde saklayın.

Sonuç: SSH Connection refused hatası katmanlı teşhis gerektirir

SSH Connection refused hatası genellikle kullanıcı hesabından değil, SSH servisinin çalışmaması, yanlış portta dinleme veya ağ politikalarının bağlantıyı reddetmesinden kaynaklanır. En güvenli yaklaşım; konsol erişimini korumak, servis durumunu incelemek, dinleyen portu doğrulamak, firewall ile bulut kurallarını karşılaştırmak ve her yapılandırma değişikliğini test etmektir. Bu sıra, erişimi tamamen kaybetmeden sorunun gerçek kaynağını ayırmanıza yardımcı olur.

Sık sorulan sorular

Connection refused ile Connection timed out arasındaki fark nedir?

Connection refused, hedefin bağlantıyı aktif biçimde reddettiğini; Connection timed out ise paketlerin yanıt alamadığını gösterir. İlki çoğunlukla servis/port veya reject kuralı, ikincisi ise yönlendirme, drop kuralı ya da ağ erişimi sorunudur.

SSH servisini yeniden başlatmak güvenli midir?

Yapılandırma geçerliyse genellikle güvenlidir; ancak hatalı yapılandırma erişim kaybına yol açabilir. Önce sshd -t çalıştırın, alternatif konsol erişimini hazır tutun ve mümkünse reload tercih edin.

SSH farklı bir portta çalışıyorsa nasıl bağlanırım?

ssh -p PORT kullanici@sunucu biçimini kullanın. Aynı portun sunucu firewall’ında ve bulut güvenlik grubunda TCP için açık olduğundan emin olun.

Firewall kapalı olduğu hâlde neden bağlantı reddedilir?

sshd durmuş olabilir, yalnızca localhost üzerinde dinliyor olabilir veya bulut sağlayıcısındaki güvenlik grubu/NAT kuralı bağlantıyı engelliyor olabilir. Sunucu tarafında ss -ltnp ile başlayın.

Fail2ban bu hataya neden olabilir mi?

Yapılandırmaya bağlı olarak engellenen istemciye red veya sessiz düşürme uygulanabilir. Ancak önce SSH servisinin dinlediğini ve temel firewall kurallarını doğrulamak daha doğru teşhis sırasıdır.