SSH Connection Refused ve Connection Timed Out Farkı

SSH'te "Connection refused" ve "Connection timed out" hatalarının anlamı

SSH bağlantısının reddedilmesi (refused) ve zaman aşımına uğraması (timed out) birbirine zıt hata türleridir; dolayısıyla birinin çözümü diğeri için asla geçerli değildir. "Refused" hatası, paketinizin sunucuya ulaştığını ve sunucu çekirdeğinin "burada dinleme yapan bir servis yok" yanıtını verdiğini gösterir. "Timed out" hatası ise paketinizin yanıt verebilecek kimseye ulaşmadığını, bu nedenle istemcinin bekleyip vazgeçtiğini ifade eder. "Refused" sunucu tarafındaki bir servis sorunudur. "Timed out" ise sunucunun önündeki bir yol veya ağ sorunudur.

İstemcinizin yazdırdığı tam satırı okuyun; çünkü kullanılan ifadeler teşhisin tamamını oluşturur.

ssh: connect to host 203.0.113.10 port 22: Connection refused
ssh: connect to host 203.0.113.10 port 22: Connection timed out

Zamanlama ikinci ipucudur. "Refused" hatası, bir gidiş-dönüş süresi kadar kısa bir sürede hemen döner. "Timed out" hatası ise istemci vazgeçmeden önce tekrar denemeler yaptığı için ekranda görünmeden önce uzun saniye boyunca bekler. macOS aynı durum için Operation timed out çıktısını verir. Eğer protokolün kendisi sizin için yeniyse, SSH'in çalışma mantığı ve sshd'nin işlevi bu kılavuzun varsaydığı temel bilgileri içerir.

"Connection refused" neden iyi bir haberdir

Refused, bir TCP (transmission control protocol) sıfırlama işlemidir. İstemciniz 22 numaralı porta bir SYN paketi gönderir. Paket internet üzerinden geçer, sunucunun ağ yığınına ulaşır ve çekirdek bu portta dinleme yapan bir soket bulamadığı için bir RST (reset) paketiyle yanıt verir. SSH istemciniz bu RST paketini Connection refused ifadesine dönüştürür.

Geri dönen bu tek paket çok şey kanıtlar. Adres doğrudur. Sunucu çalışır durumdadır ve yönlendirme yapmaktadır. Yol üzerindeki hiçbir cihaz bu porta giden trafiği sessizce düşürmemektedir; çünkü karşı taraftan bir yanıt gelmiştir. Dolayısıyla geriye kalan tüm şüpheliler sunucunun kendisindedir.

• sshd çalışmıyordur; çünkü başlatılamamıştır veya hiçbir zaman etkinleştirilmemiştir.
• sshd başka bir portu dinliyordur; bu durum genellikle bir sıkılaştırma (hardening) değişikliğinden sonra gerçekleşir.
• sshd belirli bir adrese bağlıdır, örneğin ListenAddress 127.0.0.1; bu nedenle sadece sunucunun kendisi ona erişebilir.
• Bir güvenlik duvarı, trafiği düşürmek (drop) yerine reddetmek (reject) üzere ayarlanmıştır; bu yüzden güvenlik duvarı, sunucu adına RST paketini gönderir. ufw reject eylemi ve reject with tcp reset ile biten bir nftables kuralı bu işlemi gerçekleştirir.

Bunlara benzeyen ancak farklı olan bir durum daha vardır: yanlışlıkla başka bir aktif sunucuya ait bir adres yazmış olabilirsiniz. O sunucu SYN paketinize yanıt verir, 22 numaralı portta SSH servisi yoktur ve sizi nazikçe reddeder. Yanlış sunucu üzerinde vakit kaybetmeden önce adresi doğrulayın. Linux üzerinde dinleme yapan bir portun gerçekte ne olduğunu bilmek, bu bölümün geri kalanının daha hızlı anlaşılmasını sağlar.

Connection refused hatası nasıl giderilir

SSH bağlantısı koptuğu için bu sorunu SSH üzerinden çözemezsiniz. Sağlayıcınızın web konsolunu veya seri konsolunu açın, oturum açın ve ardından aşağıdaki komutları sırasıyla uygulayın.

systemctl status ssh
sudo ss -tlnp
sudo sshd -T | grep -Ei '^(port|listenaddress|addressfamily)'

systemctl status ssh, Ubuntu ve Debian üzerinde birim adını kullanır. RHEL ve AlmaLinux gibi türevlerinde ise birim sshd şeklindedir. ss -tlnp, dinleme durumundaki tüm TCP soketlerini ve bunlara sahip süreçleri listeler; bu, temel doğrulama yöntemidir: Eğer hiçbir satırda sshd geçmiyorsa, yapılandırma dosyası ne derse desin hiçbir şey dinlenmiyordur. sshd -T, tüm Include dosyaları birleştirildikten sonra geçerli olan yapılandırmayı yazdırır; /etc/ssh/sshd_config.d/ içinde unutulmuş bir port burada kendini belli eder.

Adres sütununu dikkatle inceleyin. 0.0.0.0:22, sunucudaki tüm IPv4 adreslerini ifade eder. [::]:22, tüm IPv6 adresleri anlamına gelir. 127.0.0.1:22 ise yalnızca loopback (yerel) arayüzü ifade eder; bu durumda yerel bir ssh localhost bağlantısı sorunsuz çalışırken, tüm uzak bağlantılar reddedilir.

Eğer hiçbir şey dinlenmiyorsa, servisi başlatın ve başlamadığı takdirde hata mesajını okuyun.

sudo sshd -t
sudo systemctl enable --now ssh
sudo journalctl -u ssh -n 50 --no-pager

sshd -t, çalışan servise dokunmadan yapılandırmayı ayrıştırır ve hatalı yönergenin bulunduğu dosya ile satır numarasını yazdırır. Her yeniden başlatmadan önce bu komutu çalıştırın; çünkü reddedilen bir yapılandırma, sshd'nin başlangıçta kapanmasına ve bir sonraki bağlantınızın reddedilmesine neden olur.

Ubuntu üzerinde socket activation tuzağı

Ubuntu 24.04, OpenSSH için bir systemd socket birimi ile gelir. Bu birim etkinleştirildiğinde, systemd dinleme portunu tutar ve sshd sürecini her bağlantı için ayrı başlatır; bu nedenle Port 2222 dosyasındaki sshd_config ayarı hiçbir şeyi değiştirmez ve sunucu eski port üzerinden yanıt vermeye devam eder. Herhangi bir düzenleme yapmadan önce sisteminizin hangi modda olduğunu kontrol edin.

systemctl is-enabled ssh.socket
systemctl status ssh.socket

Eğer socket etkinse, portu sshd_config yerine socket birimi içerisinde ayarlayın.

sudo systemctl edit ssh.socket

[Socket]
ListenStream=
ListenStream=2222

Boş ListenStream= satırı gereklidir, çünkü systemd liste ayarları mevcut yapılandırmanın üzerine ekleme yapar. Bu satırı çıkarırsanız sunucu her iki portu da dinler. Değişikliği sudo systemctl daemon-reload ve sudo systemctl restart ssh.socket ile uygulayın, ardından yeni portun tutulduğunu doğrulamak için sudo ss -tlnp komutunu kullanın. Portu değiştirmek, VPS üzerinde SSH güvenliğini sıkılaştırma sürecinde standart bir adımdır ve kullanıcıların sistem dışı kalmasına en sık yol açan işlem budur.

"Connection timed out" hatası neden yanıt alınamadığını belirtir

Zaman aşımı (timeout) sessizlik demektir. İstemciniz bir SYN paketi gönderdi, bunu bir veya iki dakika boyunca birkaç kez yeniden iletti ancak karşılığında tek bir paket bile almadı. Sunucudan hiçbir yanıt duyulmadığı için sunucu hakkında herhangi bir çıkarım yapılamaz.

Sessizlik, tam olarak bir DROP kuralının ürettiği sonuçtur ve paketlerin düşürülmesi (dropping) kasıtlıdır. Bir reddetme (rejection) yanıtı, tarama yapan herkese ana bilgisayarın var olduğunu bildirir; bu nedenle ufw ve tüm bulut sağlayıcılarının ağ güvenlik duvarları istenmeyen paketleri sessizce atar ve geri hiçbir şey göndermez. Karşılaştığınız zaman aşımı, genellikle bir güvenlik duvarının açık olmasını istediğiniz bir portta görevini yapmasından kaynaklanır.

• Adres yanlıştır: Bir DNS kaydı, yeniden oluşturduğunuz bir sunucuyu işaret ediyor olabilir veya kimsenin kullanmadığı bir adrese yönlendiren bir yazım hatası olabilir.
• Ana bilgisayar çalışmıyordur: Gücü kapalıdır veya yeniden başlatılma sürecindedir. Fatura ödemesi nedeniyle bir sağlayıcı tarafından askıya alınma durumu, dışarıdan bakıldığında aynı şekilde görünür.
• Ana bilgisayar güvenlik duvarı 22 numaralı portu düşürüyordur; bu durum genellikle herhangi bir izin kuralı tanımlanmadan önce ufw enable çalıştırıldığında meydana gelir.
• Örneğinizin (instance) önündeki bir sağlayıcı güvenlik duvarı paketi düşürüyordur ve işletim sistemi paketi hiçbir şekilde görmüyordur.
• Kendi ağınız 22 numaralı port üzerinden giden trafiği engelliyordur; bu durum ofis ve otel bağlantılarında yaygındır.

Testi bağlantının diğer ucundan çalıştırın

En çok zaman kaybettiren hata budur. Paketlerin ulaşmadığı bir kutunun içinden paket kaybını teşhis edemezsiniz. Komutu çalıştırmak için giriş yapabiliyor olsaydınız, zaten bu sorunu yaşamazdınız. Bu bölümdeki her komut kendi makinenizde çalıştırılmalıdır.

getent hosts vps.example.com
ssh -G vps.example.com | grep -Ei '^(hostname|port|user)'
ssh -vvv -o ConnectTimeout=10 user@vps.example.com
nc -vz -w 5 203.0.113.10 22

getent hosts, makinenizin gerçekten kullanacağı adresi gösterir; bu sayede güncelliğini yitirmiş bir DNS kaydı saniyeler içinde tespit edilir. ssh -G, istemcinizin ~/.ssh/config dosyasını okuduktan sonra uyguladığı ayarları yazdırır; böylece ana makine adını, portu veya kullanıcıyı sessizce yeniden yazan eski bir Host bloğu yakalanmış olur. ssh -vvv, bağlantı denemesinin ne kadar ilerlediğini gösterir: adrese bağlanma ile ilgili son satırdan sonra gelen uzun bir duraksama zaman aşımı (timeout) anlamına gelir; uzak OpenSSH sürümünü bildiren bir satır ise TCP'nin zaten başarılı olduğunu ve asıl sorunun kimlik doğrulama olduğunu gösterir. Windows üzerinde PowerShell içinde Test-NetConnection 203.0.113.10 -Port 22, nc komutunun yerini tutar.

Ana makineyi değil, portu test edin. Başarısız bir ping hiçbir şeyi kanıtlamaz, çünkü birçok servis sağlayıcı ICMP (internet control message protocol) trafiğini sınırda filtreler. Başarılı bir ping de hiçbir şeyi kanıtlamaz, çünkü port 22 hakkında hiçbir bilgi vermez.

Ardından, hiçbir komutun sizin yerinize değiştiremeyeceği tek değişkeni değiştirin: ağınızı. Bir telefon erişim noktası (hotspot) üzerinden tekrar deneyin. Eğer hotspot üzerinden bağlantı kurulabiliyor ancak masaüstü ağınızdan kurulamıyorsa, engel internetin sizin tarafınızdadır veya ofis IP adresiniz sunucu üzerinde yasaklanmıştır.

Sunucu üzerinden göremediğiniz sağlayıcı güvenlik duvarı

Çoğu VPS paneli, sunucunuzun önünde çalışan ve kendi kural listesini barındıran, güvenlik grubu veya bulut güvenlik duvarı olarak adlandırılan bir ağ güvenlik duvarı sunar. Sunucu üzerindeki ufw status bunu göremez; bu nedenle "ama 22 numaralı portu zaten açmıştım" cümlesi oldukça yaygındır. Sunucu üzerinde tek bir kuralı bile değiştirmeden önce paneli açın ve bu listeyi kontrol edin.

Tek bir komut bu sorunu çözer ve konsol erişimi gerektirir. Komutu sunucuda başlatın, ardından komut çalışırken dizüstü bilgisayarınızdan bağlanmayı deneyin.

sudo tcpdump -ni any tcp port 22

İstemciniz bağlantı kurmaya çalışırken hiçbir şey görünmüyorsa, paketler işletim sistemine ulaşmadan önce atılıyor demektir; bu durumda hata, sağlayıcı güvenlik duvarında veya ana makineye giden rotadadır. Eğer SYN paketleri ulaşıyor ancak yanıt çıkmıyorsa, paketler yerel olarak düşürülüyordur ve sorun ufw veya nftables kaynaklıdır. Bu tek test, zaman aşımı durumunu ikiye ayırır; bu yüzden konsola gitmeye değer.

ufw sıralaması, IPv6 ve kendi kendinizi engelleme durumu

ufw sıralama hatası, bu konudaki diğer tüm sorunlardan daha fazla kullanıcının sistem dışı kalmasına neden olur. sudo ufw enable, gelen bağlantılar için varsayılan olarak reddetme politikasını anında uygular; bu nedenle SSH kuralı tanımlanmadan etkinleştirildiğinde, mevcut oturumunuz devam eden bağlantı durumu sayesinde açık kalsa da, her yeni bağlantı zaman aşımına uğrar. Önce izin verin, sonra etkinleştirin.

sudo ufw allow OpenSSH
sudo ufw status verbose

OpenSSH uygulama profili yalnızca 22 numaralı portu kapsar. SSH servisini 2222 numaralı porta taşımayı planlıyorsanız, port değişikliğinden sonra değil, önce sudo ufw allow 2222/tcp kuralını eklemeniz gerekir. Daha kapsamlı kural setleri VPS için ufw güvenlik duvarı temelleri kısmında, güvenli sıralama ise yeni bir VPS üzerinde ilk on dakikada yapılması gerekenler kısmında açıklanmıştır.

IPv6, doğaüstü bir zaman aşımı hissi yaratır. Eğer sunucu adınız bir AAAA kaydına sahipse, istemciniz önce IPv6 üzerinden bağlanmayı dener; bu nedenle IPv6 kuralları eksik olan bir sunucuda bağlantı askıda kalırken, IPv4 üzerinden yapılan denemeler başarılı olur. Bu iki protokolü manuel olarak birbirinden ayırın.

ssh -4 user@vps.example.com
ssh -6 user@vps.example.com

Eğer -4 ile bağlantı kurulabiliyor ancak -6 ile kurulamıyorsa, çözüm sunucunun IPv6 kurallarındadır; ufw üzerinde IPv6 için aynı portu açma rehberi bu süreci adım adım anlatır.

Ayrıca kendi kendinizi engellemiş olabilirsiniz. fail2ban, kimlik doğrulama günlüklerini izler ve art arda başarısız giriş yapan adreslere karşı bir güvenlik duvarı kuralı ekler; bu nedenle hatalı bir anahtar veya arka planda çalışan bir betik, tüm ofis ağınızın engellenmesine yol açabilir. Bağlantıyı düşüren bir engelleme, zaman aşımı gibi görünür. Bağlantıyı reddeden bir engelleme ise No route to host hatası döndürür. Konsol üzerinden:

sudo fail2ban-client status sshd
sudo fail2ban-client set sshd unbanip 198.51.100.24

Kendi adresinizi ignoreip dosyasına eklemek, Ubuntu 24.04 üzerinde çalışan bir fail2ban kurulumu rehberinin bir parçasıdır.

Reddedilmeyen veya zaman aşımına uğramayan hatalar

No route to host, bir ICMP ulaşılamaz mesajının geri döndüğü anlamına gelir. Ya kendi makinenizin o ağa giden bir rotası yoktur ya da yol üzerindeki bir cihaz idari bir reddetme ile yanıt vermiştir; iptables REJECT kuralının gönderdiği yanıt budur.

Network is unreachable, kendi makinenizin verdiği yanıttır. Makinenin o adres ailesi için hiçbir rotası yoktur; bu durum genellikle bir ana makine adının yalnızca IPv6 adresine çözümlendiği ancak bağlantının yalnızca IPv4 üzerinden yapıldığı durumlarda görülür.

kex_exchange_identification: Connection closed by remote host, TCP bağlantısının kurulduğunu ancak anahtar değişimi tamamlanmadan sunucunun bağlantıyı kestiğini gösterir. Port açıktır ve sshd çalışmaktadır; bu nedenle sunucu yükünü, MaxStartups dosyasını veya bağlantı sırasında devreye giren bir engellemeyi kontrol edin.

Permission denied (publickey), kimlik doğrulama aşamasına ulaştığınızı ancak başarısız olduğunuzu belirtir. Ağ ve güvenlik duvarı düzgün çalışmaktadır, dolayısıyla bu kılavuzdaki hiçbir madde bu durum için geçerli değildir. Bunun yerine SSH üzerinde Permission denied (publickey) hatasını giderme bölümüne gidin.

Sisteme tekrar giriş ve ikinci bir kilitlenmeyi önleme

Her ciddi VPS sağlayıcısı, konuk işletim sisteminin ağ durumundan bağımsız bir konsol sunar: seri konsol veya tarayıcı tabanlı bir VNC ekranı. Bu konsol, rehberin her iki dalı için de kurtarma yoludur; çünkü sshd durdurulduğunda veya bir güvenlik duvarı kuralı tüm trafiği reddettiğinde dahi çalışmaya devam eder. Konsolu panelinizde bulun, root veya normal kullanıcınızla giriş yapın ve yukarıdaki kontrolleri çalıştırın. Eğer daha önce bir root parolası belirlemediyseniz, çoğu panel sizin için bir parola sıfırlama işlemi gerçekleştirebilir.

Konsolun bulunmadığı durumlarda, yedek yöntem sağlayıcının kurtarma modudur (rescue mode). Bu mod, küçük bir kurtarma sistemini başlatır ve diskinizi bağlar; böylece /etc/ssh/sshd_config dosyasını düzenleyebilir veya bir güvenlik duvarı kuralını çevrimdışı olarak silebilir ve sistemi yeniden başlatabilirsiniz.

İki alışkanlık, bir sonraki kilitlenmeyi önler. sshd veya güvenlik duvarını düzenlerken her zaman ikinci bir SSH oturumunu açık tutun; çünkü siz yeni bir oturumu test ederken mevcut oturumunuz kurulmuş durum üzerinden çalışmaya devam eder. Ayrıca, riskli bir güvenlik duvarı değişikliğinden önce kendinize otomatik bir geri alma komutu tanımlayın.

sudo systemd-run --unit=ufw-rollback --on-active=10min /usr/sbin/ufw disable
sudo systemctl stop ufw-rollback.timer

İlk satır, ufw aracının on dakika sonra kendini kapatmasını planlar. Yeni kurallarınızı uygulayın, çalıştıklarını doğrulamak için yeni bir SSH oturumu açın ve ardından geri almayı iptal etmek için ikinci satırı çalıştırın. Eğer kendinizi kilitlerseniz, on dakika bekleyin; güvenlik duvarı kendiliğinden devre dışı kalacaktır. Bu işlem, siz ufw aracını tekrar etkinleştirene kadar sunucuyu filtresiz bırakır; bu nedenle bu yöntemi yalnızca klavye başında olduğunuzda kullanın, kalıcı bir yapılandırma olarak tercih etmeyin.

İş akışı sırası

1. Hata metnini okuyun ve hata mesajının ne kadar sürede görüntülendiğine dikkat edin.
2. Refused (Reddedildi) hatası: Konsola gidin ve dinleme yapan bir soket, ilgili port ve bağlandığı adres için sudo ss -tlnp komutunu kontrol edin.
3. Timed out (Zaman aşımı) hatası: Kendi makinenizden adresi doğrulayın, ardından panel üzerinden sağlayıcı güvenlik duvarını ve son olarak sunucu üzerindeki yerel güvenlik duvarını kontrol edin.
4. Bu dizelerden hiçbiri değilse: Zaten bir TCP bağlantınız var demektir; bu durumu bir ağ sorunu olarak değil, kimlik doğrulama veya sunucu yükü sorunu olarak ele alın.

FAQ

sshd çalışıyor olmasına rağmen SSH neden "Connection refused" hatası veriyor?

Çünkü bağlantı reddi servisten değil, soketten kaynaklanır ve çalışan bir sshd yine de bağlantınızı reddedebilir. Sağlayıcı konsolunu açın ve sudo ss -tlnp komutunu çalıştırın. 127.0.0.1:22 üzerindeki bir soket, yalnızca loopback adresine bağlı olduğu için tüm uzak istemcileri reddeder. Başka bir porttaki soket ise hala 22 numaralı portu kullanan herkesi reddeder. Eğer systemd socket activation kullanılıyorsa, port sshd_config dosyasından değil ssh.socket dosyasından gelir; bu nedenle systemctl is-enabled ssh.socket dosyasını da kontrol edin. Bir ufw reject kuralı da ana makine adına bağlantıyı reddedebilir; bu yüzden herhangi bir sonuca varmadan önce sudo ufw status verbose dosyasını inceleyin.

ufw üzerinde 22 numaralı porta izin verilmiş olmasına rağmen SSH neden zaman aşımına uğruyor?

Çünkü zaman aşımı, herhangi bir yanıtın dönmediği anlamına gelir ve ufw yoldaki tek güvenlik duvarı değildir. Çoğu VPS paneli, instance önünde bir ağ güvenlik duvarı çalıştırır ve işletim sistemi, bu güvenlik duvarının engellediği paketleri asla görmez. Konsoldan sudo tcpdump -ni any tcp port 22 komutunu çalıştırın ve bu komut çalışırken dizüstü bilgisayarınızdan bağlanmayı deneyin. Hiç paket gelmiyorsa, engelleme panel tarafında, yani yukarı akışta gerçekleşiyordur. Paketler geliyor ancak yanıt dönmüyorsa, engelleme yereldir; yani ufw veya nftables kaynaklıdır.

Başarısız bir ping, VPS'imin kapalı olduğu anlamına mı gelir?

Hayır. Birçok sağlayıcı ICMP trafiğini ağ sınırında filtreler; bu nedenle normal şekilde trafik sunan bir sunucu, gönderdiğiniz tüm ping isteklerini görmezden gelebilir. Başarılı bir ping de diğer yönde aynı derecede zayıf bir kanıttır, çünkü 22 numaralı portun açık olup olmadığı hakkında hiçbir bilgi vermez. Portun kendisini kendi makinenizden nc -vz -w 5 203.0.113.10 22 ile veya Windows üzerinde PowerShell kullanarak Test-NetConnection 203.0.113.10 -Port 22 ile test edin.

SSH portunu değiştirdim ve artık hiçbir yerden bağlantı kuramıyorum. Ne yanlış gitti?

Buna iki durum neden olur. Eğer güvenlik duvarına yeni port için bir kural eklenmediyse, yeni porta yapılan denemeler zaman aşımına uğrar ve 22 numaralı port reddeder; bu nedenle sudo ufw allow 2222/tcp kuralı port değişikliğinden sonra değil, önce eklenmelidir. Eğer sunucu SSH için systemd socket activation kullanıyorsa, sshd_config içindeki Port 2222 ayarı göz ardı edilir ve systemd eski portu tutmaya devam eder; bunu systemctl is-enabled ssh.socket ile doğrulayabilirsiniz. Sağlayıcı konsolu üzerinden erişim sağlayın, ilgili sorunu düzeltin ve sudo ss -tlnp üzerinde yeni soket göründüğünde ssh -p 2222 user@203.0.113.10 ile bağlanın.