SSH: Connection Refused vs Connection Timed Out

Ano ang ibig sabihin ng “Connection refused” at “Connection timed out” sa SSH

Magkaibang kabiguan ang SSH connection refused at SSH connection timed out, kaya hindi kailanman pareho ang solusyon sa mga ito. Ibig sabihin ng refused, nakarating ang packet mo sa server at sumagot ang kernel ng server ng “walang nakikinig dito”. Ibig sabihin naman ng timed out, walang napuntahan ang packet mo na makasasagot, kaya naghintay ang client mo at sumuko. Problema sa service sa server ang refused. Problema sa network path bago makarating sa server ang timed out.

Basahin ang eksaktong linyang ipinakita ng client mo, dahil nasa wording nito ang buong diagnosis.

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

Ikalawang clue ang timing. Agad bumabalik ang refused, humigit-kumulang sa tagal ng isang round trip. Nananatili naman ang timed out nang maraming segundo bago ito lumabas, dahil paulit-ulit na ipinapadala ng client ang packet bago ito sumuko. Ipinapakita ng macOS ang Operation timed out para sa parehong kondisyon. Kung bago sa iyo ang protocol mismo, ang kung paano gumagana ang SSH at ang ginagawa ng sshd ang background na ipinapalagay ng guide na ito.

Bakit magandang balita ang “Connection refused”

Ang “refused” ay TCP (transmission control protocol) reset. Nagpapadala ang client mo ng SYN packet sa port 22. Dumadaan ito sa internet, nakararating sa network stack ng server, at nakikita ng kernel na walang socket na nakikinig sa port na iyon, kaya sumasagot ito ng RST (reset) packet. Isinasalin ng SSH client mo ang RST na iyon sa mga salitang Connection refused.

Marami ang napapatunayan ng nagbalik na packet na iyon. Tama ang address. Naka-on at nagra-route ang host. Walang bahagi ng path ang tahimik na nagtatapon ng traffic papunta sa port na iyon, dahil may bumalik mula sa kabilang dulo. Kaya ang lahat ng natitirang posibleng sanhi ay nasa server mismo.

• Hindi tumatakbo ang sshd dahil nabigong mag-start o hindi ito kailanman na-enable.
• Nakikinig ang sshd sa ibang port, karaniwan pagkatapos ng hardening change.
• Naka-bind ang sshd sa isang address, gaya ng ListenAddress 127.0.0.1, kaya ang server mismo lamang ang makaaabot dito.
• Naka-configure ang firewall na mag-reject sa halip na mag-drop, kaya ang firewall ang nagpapadala ng RST sa ngalan ng host. Parehong ginagawa ito ng ufw reject action at ng nftables rule na nagtatapos sa reject with tcp reset.

May isa pang sitwasyon na mukhang ganito pero iba: nag-type ka ng address na pag-aari ng ibang live host. Sumasagot ang host na iyon sa iyong SYN, walang SSH sa port 22, at maayos nitong nire-reject ang koneksyon mo. Kumpirmahin ang address bago ka maglaan ng isang oras sa maling server. Kung alam mo kung ano talaga ang listening port sa Linux, mas mabilis mong mauunawaan ang natitirang bahagi ng seksyong ito.

Paano ayusin ang “Connection refused”

Hindi mo ito maaayos gamit ang SSH dahil ang SSH mismo ang may problema. Buksan ang web console o serial console ng iyong provider, mag-sign in doon, at saka isa-isang patakbuhin ang mga command na ito.

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

Ginagamit ng systemctl status ssh ang unit name sa Ubuntu at Debian. Sa RHEL at mga rebuild nito gaya ng AlmaLinux, ang unit ay sshd. Inililista ng ss -tlnp ang lahat ng TCP socket na nasa listening state, pati ang process na may-ari ng bawat isa. Ito ang aktuwal na batayan: kung walang linyang nagbabanggit ng sshd, walang process na nakikinig, anuman ang sinasabi ng configuration file. Ipinapakita ng sshd -T ang effective configuration matapos pagsamahin ang lahat ng Include file. Dito makikita kung may nakalimutang port sa /etc/ssh/sshd_config.d/.

Basahing mabuti ang address column. Ang 0.0.0.0:22 ay nangangahulugang lahat ng IPv4 address sa server. Ang [::]:22 ay nangangahulugang lahat ng IPv6 address. Ang 127.0.0.1:22 ay nangangahulugang loopback lamang. Dahil dito, tatanggihan ang bawat remote connection dito habang gumagana nang maayos ang lokal na ssh localhost.

Kung walang nakikinig na process, simulan ang service at basahin ang error kung hindi ito magsimula.

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

Ipa-parse ng sshd -t ang configuration at ipapakita nito ang file at line number ng maling directive nang hindi inaapektuhan ang tumatakbong service. Patakbuhin ito bago ang bawat restart, dahil kapag tinanggihan ang configuration, lalabas ang sshd sa pagsisimula at tatanggihan ang susunod mong connection.

Ang socket activation trap sa Ubuntu

May systemd socket unit ang Ubuntu 24.04 para sa OpenSSH. Kapag naka-enable ang unit na ito, hawak ng systemd ang listening port at sinisimulan ang sshd para sa bawat connection. Kaya walang epekto ang Port 2222 sa sshd_config, at patuloy na sumasagot ang server sa dating port. Suriin muna kung aling mode ang ginagamit bago mag-edit ng anuman.

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

Kung naka-enable ang socket, itakda ang port sa socket unit sa halip na sa sshd_config.

sudo systemctl edit ssh.socket

[Socket]
ListenStream=
ListenStream=2222

Kailangan ang blangkong ListenStream= line dahil idinadagdag ng systemd ang list settings sa dati nang configuration. Kapag iniwan ito, makikinig ang server sa parehong port. I-apply ang pagbabago gamit ang sudo systemctl daemon-reload at sudo systemctl restart ssh.socket, pagkatapos ay kumpirmahin gamit ang sudo ss -tlnp na ang bagong port ang hawak ng socket. Karaniwang hakbang ang paglilipat ng port sa pag-hardening ng SSH sa isang VPS, at ito rin ang hakbang na pinakamadalas mag-lock out sa mga user.

Bakit walang ipinapahiwatig ang “Connection timed out”

Ang timeout ay kawalan ng tugon. Nagpadala ang client mo ng SYN, ilang beses itong muling ipinadala sa loob ng isa o dalawang minuto, at wala ni isang packet na bumalik. Walang makukumpirma tungkol sa server dahil wala namang natanggap na tugon mula rito.

Ang ganitong katahimikan ang eksaktong nalilikha ng isang DROP rule, at sinasadya ang pag-drop. Ipinapaalam ng rejection sa sinumang nag-scan na umiiral ang host, kaya dini-discard ng ufw at ng network firewall ng bawat cloud provider ang mga hindi gustong packet at walang ipinapadalang tugon. Karaniwang firewall ang sanhi ng timeout mo sa port na gusto mong buksan.

• Mali ang address: maaaring nakaturo pa rin ang DNS record sa server na muli mong binuo, o may typo na tumutukoy sa address na walang gumagamit.
• Hindi naka-on ang host: maaaring naka-power off o nasa kalagitnaan ng reboot. Ganito rin ang nakikita mula sa labas kapag sinuspinde ng provider ang account dahil sa billing.
• Dina-drop ng host firewall ang port 22, kadalasan dahil na-run ang ufw enable bago magkaroon ng anumang allow rule.
• Dina-drop ito ng provider firewall na nasa harap ng instance, kaya hindi man lang nakikita ng operating system ang packet.
• Bina-block ng sarili mong network ang outbound port 22, na karaniwan sa mga office at hotel connection.

Patakbuhin ang test mula sa tamang panig ng connection

Ito ang pagkakamaling pinakamaraming oras ang sinasayang. Hindi mo madi-diagnose ang dropped packet mula sa loob ng machine na hindi naaabot ng mga packet. Kung makakapag-login ka para patakbuhin ang command, wala sana ang problemang ito. Lahat ng command sa seksyong ito ay pinapatakbo sa sarili mong machine.

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

Ipinapakita ng getent hosts ang address na aktuwal na gagamitin ng iyong machine. Dahil dito, mabilis nitong natutukoy ang stale DNS record. Ipi-print ng ssh -G ang mga setting na ginagamit ng iyong client matapos basahin ang ~/.ssh/config. Dahil dito, natutukoy nito ang lumang Host block na tahimik na nagre-rewrite ng hostname, port, o user. Ipinapakita ng ssh -vvv kung gaano kalayo umabot ang pagtatangka. Ang huling linyang tungkol sa pagkonekta sa address na sinusundan ng mahabang paghihintay ay timeout. Samantala, kapag may linyang nag-uulat ng remote OpenSSH version, matagumpay na ang TCP at authentication ang tunay na problema. Sa Windows, pinapalitan ng Test-NetConnection 203.0.113.10 -Port 22 sa PowerShell ang nc.

I-test ang port, hindi ang host. Walang napapatunayan ang nabigong ping dahil maraming provider ang nagfi-filter ng ICMP (internet control message protocol) sa edge. Wala ring napapatunayan ang matagumpay na ping dahil wala itong sinasabi tungkol sa port 22.

Pagkatapos, baguhin ang isang variable na walang command na makakapagbago para sa iyo: ang iyong network. Subukang muli gamit ang phone hotspot. Kung kumonekta ang hotspot ngunit hindi ang desk connection mo, nasa panig mo ng internet ang block, o na-ban sa server ang address ng opisina mo.

Ang provider firewall na hindi mo nakikita mula sa server

Karamihan sa VPS panel ay may network firewall, na kung minsan ay tinatawag na security group o cloud firewall. Tumatakbo ito upstream ng iyong instance at may sarili itong listahan ng rules. Hindi ito nakikita ng ufw status sa server. Kaya karaniwan ang pahayag na “pero pinayagan ko na ang port 22.” Buksan ang panel at basahin ang listahang iyon bago ka magbago ng kahit isang rule sa server.

Isang command lang ang makapaglilinaw nito, at kailangan nito ng console access. Patakbuhin ito sa server, pagkatapos ay subukang kumonekta mula sa iyong laptop habang tumatakbo ito.

sudo tcpdump -ni any tcp port 22

Kung walang lumilitaw habang kumokonekta ang iyong client, dini-discard ang mga packet bago makarating sa operating system. Ibig sabihin, nasa provider firewall o sa route papunta sa host ang problema. Kung dumarating ang mga SYN packet pero walang lumalabas na reply, lokal ang pag-drop at kabilang ito sa ufw o nftables. Hinahati ng isang test na ito sa dalawang bahagi ang timeout branch. Kaya sulit ang pag-access sa console.

pagkakasunod ng ufw, IPv6, at pag-ban sa sarili

Ang maling pagkakasunod sa ufw ang nagla-lock out ng mas maraming user kaysa sa iba pang problema rito. Agad na naglalapat ang sudo ufw enable ng default policy na deny incoming. Kaya kung wala pang SSH rule, magpapatuloy ang kasalukuyang session dahil established na ito, pero magti-time out ang bawat bagong connection. Maglagay muna ng allow rule, saka i-enable ang ufw.

sudo ufw allow OpenSSH
sudo ufw status verbose

Port 22 lamang ang saklaw ng OpenSSH application profile. Kung ililipat mo ang SSH sa 2222, ang kailangan mong rule ay sudo ufw allow 2222/tcp. Idagdag ito bago baguhin ang port, hindi pagkatapos. Tinalakay ang mas malawak na rule set sa mga pangunahing kaalaman sa ufw firewall para sa isang VPS, at bahagi ng mga dapat gawin sa unang sampung minuto sa bagong VPS ang ligtas na pagkakasunod.

Ang IPv6 ay maaaring magdulot ng timeout na tila walang malinaw na dahilan. Kung may AAAA record ang hostname, IPv6 muna ang sinusubukan ng client. Kaya nagha-hang ang server na kulang ang IPv6 rules nito, habang gumagana ang direktang IPv4 attempt. Manu-manong paghiwalayin ang dalawang ito.

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

Kung kumokonekta ang -4 pero hindi ang -6, nasa IPv6 rules ng server ang problema. Ipinapakita ng pagbubukas ng parehong port para sa IPv6 sa ufw kung paano ito ayusin.

Posible ring na-ban mo ang sarili mo. Mino-monitor ng fail2ban ang authentication log at naglalagay ito ng firewall rule laban sa mga address na paulit-ulit na nabibigo. Kaya maaaring ma-lock out ang buong office address dahil sa maling key o script na patuloy na nagre-retry sa background. Ang ban na nagda-drop ng traffic ay mukhang timeout. Ang ban na nagre-reject ay nagbabalik naman ng No route to host. Mula sa console:

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

Bahagi ng gumaganang fail2ban setup sa Ubuntu 24.04 ang pagdaragdag ng sarili mong address sa ignoreip.

Mga error na hindi tinanggihan o nag-time out

No route to host ang ibig sabihin ay may bumalik na ICMP unreachable message. Walang route ang sarili mong machine papunta sa network na iyon, o may sumagot sa daanan na may administrative rejection. Ito ang ipinapadala ng isang iptables REJECT rule.

Network is unreachable ang sariling machine mo ang nagsasalita. Wala talaga itong route para sa address family na iyon. Karaniwan itong lumalabas kapag IPv6 address lamang ang nire-resolve ng hostname sa isang IPv4-only na koneksyon.

kex_exchange_identification: Connection closed by remote host ang ibig sabihin ay nakakonekta ang TCP, pero isinara ng server ang koneksyon bago matapos ang key exchange. Bukas ang port at buhay ang sshd, kaya suriin ang server load, ang MaxStartups, o ang ban na nailapat habang kumokonekta ka.

Permission denied (publickey) ang ibig sabihin ay nakarating ka sa authentication pero nabigo roon. Maayos ang network at maayos ang firewall, kaya walang naaangkop sa gabay na ito. Pumunta sa pag-aayos ng Permission denied (publickey) sa SSH sa halip.

Paano makakapasok muli at paano maiiwasan ang panibagong pagka-lockout

Ang bawat seryosong VPS host ay may console na hindi nakadepende sa network ng guest: serial console o browser-based na VNC screen. Ang console na ito ang recovery route para sa dalawang branch ng gabay na ito, dahil patuloy itong gumagana kapag nakahinto ang sshd at kapag dini-discard ng firewall rule ang lahat ng traffic. Hanapin ito sa panel, mag-sign in bilang root o bilang normal mong user, at patakbuhin ang mga check sa itaas. Kung hindi ka kailanman nag-set ng root password, maaaring mag-reset nito ang karamihan sa mga panel para sa iyo.

Kung walang console, ang fallback ay rescue mode ng provider. Nagbo-boot ito ng maliit na recovery system at mina-mount ang disk mo, kaya maaari mong i-edit ang /etc/ssh/sshd_config o mag-delete ng firewall rule offline at mag-reboot.

Dalawang gawi ang makakapigil sa susunod na lockout. Panatilihing bukas ang isang pangalawang SSH session tuwing nag-e-edit ka ng sshd o firewall, dahil nananatiling gumagana ang session na iyon sa established state habang sinusubukan mo ang isang bagong session. Magtakda rin ng automatic undo bago magsagawa ng mapanganib na pagbabago sa firewall.

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

I-schedule ng unang line na awtomatikong i-off ng ufw ang sarili nito pagkalipas ng sampung minuto. I-apply ang bago mong rules, magbukas ng bagong SSH session para patunayang gumagana ang mga ito, pagkatapos ay patakbuhin ang ikalawang line upang kanselahin ang rollback. Kung ma-lockout ka naman, maghintay ng sampung minuto at awtomatikong mag-stand down ang firewall. Mananatiling walang filter ang server hanggang sa muli mong i-enable ang ufw, kaya gamitin ito habang nasa keyboard ka at hindi bilang permanenteng arrangement.

Ang pagkakasunod-sunod ng gagawin

1. Basahin ang error text at pansinin kung gaano katagal bago ito lumitaw.
2. Refused: pumunta sa console at tingnan ang sudo ss -tlnp para sa listening socket, port nito, at address na pinag-bind-an nito.
3. Timed out: mula sa sarili mong machine, kumpirmahin ang address. Pagkatapos, tingnan ang provider firewall sa panel at ang host firewall sa server.
4. Kung wala sa dalawang string na iyon: may TCP connection ka na. Ituring itong isyu sa authentication o server load, hindi sa network.

FAQ

Bakit sinasabi ng SSH na "Connection refused" kahit tumatakbo ang sshd?

Dahil nagmumula ang refusal sa socket, hindi sa service, at maaari ka pa ring tanggihan ng tumatakbong sshd. Buksan ang provider console at patakbuhin ang sudo ss -tlnp. Tinatanggihan ng socket sa 127.0.0.1:22 ang lahat ng remote client dahil naka-bind lamang ito sa loopback. Tinatanggihan ng socket sa ibang port ang lahat ng gumagamit pa rin ng 22. Kung ginagamit ang systemd socket activation, mula sa ssh.socket kinukuha ang port at hindi sa sshd_config, kaya suriin din ang systemctl is-enabled ssh.socket. Maaari ring magbalik ng refusal ang ufw reject rule para sa host, kaya basahin ang sudo ufw status verbose bago gumawa ng konklusyon.

Bakit nagti-time out ang SSH kahit pinapayagan na ng ufw ang port 22?

Dahil ang timeout ay nangangahulugang walang nakabalik na sagot, at hindi lang ufw ang firewall sa path. Karamihan sa VPS panel ay may network firewall sa harap ng instance, at hindi nakikita ng operating system ang ibinabagsak ng firewall na iyon. Mula sa console, patakbuhin ang sudo tcpdump -ni any tcp port 22 at subukang kumonekta mula sa laptop habang tumatakbo ito. Kung walang dumarating na packet, nasa upstream ang drop, sa panel. Kung dumarating ang mga packet pero walang reply na lumalabas, nasa local host ang drop, sa ufw o nftables.

Nangangahulugan bang down ang VPS ko kapag nag-fail ang ping?

Hindi. Sine-filter ng maraming provider ang ICMP sa network edge, kaya maaaring balewalain ng server na normal na naghahatid ng traffic ang bawat ping na ipinapadala mo. Mahina rin ang ipinapahiwatig ng successful ping sa kabilang direksyon, dahil wala itong sinasabi kung bukas ang port 22. I-test mismo ang port gamit ang nc -vz -w 5 203.0.113.10 22 mula sa sarili mong machine, o gamit ang Test-NetConnection 203.0.113.10 -Port 22 sa PowerShell sa Windows.

Binago ko ang SSH port at ngayon ay walang makakonekta. Ano ang nangyari?

Dalawang maling pagkakasunod-sunod ang maaaring magdulot nito. Kung walang rule ang firewall para sa bagong port, magti-time out ang mga pagtatangkang kumonekta sa bagong port habang magre-refuse ang port 22, kaya dapat patakbuhin ang sudo ufw allow 2222/tcp bago baguhin ang port at hindi pagkatapos nito. Kung gumagamit ang machine ng systemd socket activation para sa SSH, binabalewala ang Port 2222 sa sshd_config at patuloy na hawak ng systemd ang lumang port; makukumpirma mo ito gamit ang systemctl is-enabled ssh.socket. Mag-recover sa provider console, ayusin ang naaangkop na problema, pagkatapos ay kumonekta gamit ang ssh -p 2222 user@203.0.113.10 kapag ipinakita ng sudo ss -tlnp ang bagong socket.