Tofauti ya SSH Connection Refused na Connection Timed Out

Maana ya "Connection refused" na "Connection timed out" katika SSH

Hitilafu ya SSH connection refused na SSH connection timed out ni matatizo tofauti kabisa, hivyo suluhisho la moja haliwezi kutumika kwa jingine. Refused inamaanisha pakiti yako imefika kwenye seva na kernel ya seva imejibu kuwa "hakuna huduma inayoisikiliza port hii". Timed out inamaanisha pakiti yako haijafika kwa yeyote anayeweza kujibu, hivyo mteja wako (client) alisubiri na kukata tamaa. Refused ni tatizo la huduma kwenye seva. Timed out ni tatizo la njia ya mtandao inayoelekea kwenye seva hiyo.

Soma mstari kamili uliotolewa na mteja wako, kwa sababu maneno hayo ndiyo utambuzi mzima wa tatizo.

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

Muda ni dokezo la pili. Refused inarudi mara moja, ndani ya muda wa safari moja ya pakiti kwenda na kurudi. Timed out inakaa kwa sekunde nyingi kabla ya kuonyesha ujumbe, kwa sababu mteja anaendelea kutuma tena pakiti kabla ya kukata tamaa. macOS huonyesha Operation timed out kwa hali hiyo hiyo. Ikiwa itifaki yenyewe ni ngeni kwako, jinsi SSH inavyofanya kazi na kile sshd inachokifanya ndiyo msingi ambao mwongozo huu unauzingatia.

Kwa nini "Connection refused" ni habari njema

Refused ni TCP (transmission control protocol) reset. Mteja wako hutuma pakiti ya SYN kwenye port 22. Inavuka mtandao, inafika kwenye network stack ya seva, na kernel haioni socket inayosikiliza kwenye port hiyo, kwa hivyo inajibu kwa pakiti ya RST (reset). Mteja wako wa SSH hubadilisha RST hiyo kuwa maneno Connection refused.

Pakiti hiyo moja inayorudi inathibitisha mambo mengi. Anwani ni sahihi. Host imewashwa na inafanya routing. Hakuna kitu kwenye njia kinachotupa trafiki ya port hiyo kimya kimya, kwa sababu kuna kitu kimerudi kutoka mwisho wa pili. Kwa hivyo kila mtuhumiwa aliyebaki yupo kwenye seva yenyewe.

• sshd haiendeshi, kwa sababu imeshindwa kuanza au haikuwahi kuwezeshwa.
• sshd inasikiliza kwenye port nyingine, kwa kawaida baada ya mabadiliko ya usalama.
• sshd imefungwa kwenye anwani moja, kama vile ListenAddress 127.0.0.1, kwa hivyo seva yenyewe pekee ndiyo inayoweza kuifikia.
• Firewall imewekwa ili kukataa (reject) badala ya kutupa (drop), kwa hivyo firewall hutuma RST kwa niaba ya host. Kitendo cha ufw reject na sheria ya nftables inayoishia na reject with tcp reset zote hufanya hivi.

Kuna kisa kingine kinachofanana na hayo lakini siyo: umeandika anwani inayomilikiwa na host nyingine iliyo hai. Host hiyo inajibu SYN yako, haina SSH kwenye port 22, na inakukataa kwa heshima. Thibitisha anwani kabla ya kutumia saa nzima kwenye seva isiyo sahihi. Kujua nini maana ya port inayosikiliza kwenye Linux hufanya sehemu iliyobaki ya kipengele hiki kusomeka haraka zaidi.

Jinsi ya kurekebisha Connection refused

Huwezi kurekebisha hili kupitia SSH, kwa sababu SSH ndiyo huduma iliyoharibika. Fungua web console au serial console ya mtoa huduma wako, ingia humo, kisha fuata amri hizi.

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

systemctl status ssh hutumia jina la unit kwenye Ubuntu na Debian. Kwenye RHEL na mifumo inayofanana nayo kama AlmaLinux, unit hiyo ni sshd. ss -tlnp huorodhesha kila TCP socket iliyo katika hali ya kusikiliza (listening) pamoja na mchakato unaoimiliki, na hii ndiyo njia sahihi ya kuthibitisha: kama hakuna mstari unaotaja sshd, basi hakuna kinachosikiliza, bila kujali faili ya usanidi inavyosema. sshd -T huchapisha usanidi halisi baada ya kila faili ya Include kuunganishwa, ambapo port iliyosahaulika katika /etc/ssh/sshd_config.d/ hujitokeza.

Soma safu ya anwani kwa makini. 0.0.0.0:22 inamaanisha kila anwani ya IPv4 kwenye seva. [::]:22 inamaanisha kila anwani ya IPv6. 127.0.0.1:22 inamaanisha loopback pekee, kwa hivyo kila muunganisho wa mbali (remote connection) hukataliwa wakati ssh localhost ya ndani inafanya kazi kikamilifu.

Ikiwa hakuna kinachosikiliza, anzisha huduma hiyo na usome kosa litakalojitokeza ikiwa haitaki kuanza.

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

sshd -t huchunguza usanidi na kuchapisha faili na namba ya mstari wa maelekezo mabaya bila kuathiri huduma inayofanya kazi. Iendeshe kabla ya kila restart, kwa sababu usanidi uliokataliwa unamaanisha sshd itazima wakati wa kuanza na muunganisho wako unaofuata utakataliwa.

Mtego wa socket activation kwenye Ubuntu

Ubuntu 24.04 inakuja na systemd socket unit kwa ajili ya OpenSSH. Pale unit hiyo inapowezeshwa, systemd hushikilia port ya kusikiliza na kuanzisha sshd kwa kila muunganisho, kwa hivyo Port 2222 katika sshd_config haibadilishi chochote na seva huendelea kujibu kwenye port ya zamani. Hakikisha hali ya mfumo wako kabla ya kuhariri chochote.

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

Ikiwa socket imewezeshwa, weka port katika socket unit badala ya sshd_config.

sudo systemctl edit ssh.socket

[Socket]
ListenStream=
ListenStream=2222

Mstari wa ListenStream= ulio wazi unahitajika, kwa sababu mipangilio ya orodha ya systemd huongezea ile iliyosanidiwa tayari. Ukiuacha, seva itasikiliza kwenye port zote mbili. Tekeleza mabadiliko kwa sudo systemctl daemon-reload na sudo systemctl restart ssh.socket, kisha thibitisha na sudo ss -tlnp kuwa port mpya ndiyo inayoshikiliwa. Kubadilisha port ni hatua ya kawaida katika kuimarisha usalama wa SSH kwenye VPS, na ndiyo hatua inayowafungia watu nje mara nyingi zaidi.

Kwa nini "Connection timed out" inamaanisha hakuna jibu lililopokelewa

Timeout ni ukimya. Mteja wako alituma SYN, akairejesha mara kadhaa kwa dakika moja au mbili, na hakupokea pakiti hata moja kama jibu. Hakuna kinachothibitishwa kuhusu seva hapa, kwa sababu hakuna chochote kilichosikika kutoka kwa seva hiyo.

Ukimya ndicho hasa kinachozalishwa na sheria ya DROP, na kuacha pakiti (dropping) ni jambo la makusudi. Kukataa (rejection) humwambia yeyote anayechanganua mtandao kuwa mwenyeji (host) yupo, kwa hivyo ufw na kila firewall ya mtandao ya mtoa huduma wa wingu hutupa pakiti zisizohitajika na hazitumi chochote kurudi. Timeout yako kwa kawaida ni firewall inayofanya kazi yake kwenye port uliyotaka iwe wazi.

• Anwani si sahihi: rekodi ya DNS bado inaelekeza kwenye seva uliyoiunda upya, au kosa la kuandika (typo) linalopeleka kwenye anwani isiyotumiwa na mtu yeyote.
• Mwenyeji haujawaka: umezimwa, au uko katikati ya mchakato wa reboot. Kusimamishwa kwa huduma na mtoa huduma kwa sababu ya malipo huonekana sawa kabisa ukiwa nje.
• Firewall ya mwenyeji inatupa (drops) port 22, mara nyingi kwa sababu ufw enable iliendeshwa kabla ya sheria yoyote ya kuruhusu (allow rule) kuwepo.
• Firewall ya mtoa huduma iliyo mbele ya instance inatupa pakiti hiyo, na mfumo wa uendeshaji hauoni pakiti hiyo hata kidogo.
• Mtandao wako mwenyewe unazuia port 22 ya kutoka (outbound), jambo ambalo ni la kawaida kwenye miunganisho ya ofisi na hoteli.

Endesha jaribio kutoka upande wa pili wa muunganisho

Hili ndilo kosa linalopoteza muda mwingi zaidi. Huwezi kutambua pakiti iliyopotea ukiwa ndani ya seva ambayo pakiti hizo hazifiki. Kama ungeweza kuingia ili kuendesha amri, usingekuwa na tatizo hili. Kila amri katika sehemu hii inaendeshwa kwenye mashine yako mwenyewe.

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 inaonyesha anwani ambayo mashine yako itatumia kikweli, jambo linalobaini rekodi ya DNS iliyopitwa na wakati ndani ya sekunde chache. ssh -G inachapisha mipangilio ambayo mteja wako anatumia baada ya kusoma ~/.ssh/config, hivyo inabaini kizuizi cha zamani cha Host ambacho kinabadilisha jina la mwenyeji (hostname), port au mtumiaji kimyakimya. ssh -vvv inaonyesha jaribio limefika wapi: mstari wa mwisho kuhusu kuunganisha kwenye anwani ukifuatiwa na kusita kwa muda mrefu ni timeout, wakati mstari unaoripoti toleo la OpenSSH la mbali unamaanisha kuwa TCP imefanikiwa na tatizo lako halisi ni uthibitishaji (authentication). Kwenye Windows, Test-NetConnection 203.0.113.10 -Port 22 katika PowerShell inachukua nafasi ya nc.

Jaribu port, si mwenyeji (host). ping iliyoshindwa haithibitishi chochote, kwa sababu watoa huduma wengi huchuja ICMP (internet control message protocol) kwenye ukingo wa mtandao. Ping iliyofanikiwa pia haithibitishi chochote, kwa sababu haisemi chochote kuhusu port 22.

Kisha badilisha kigezo kimoja ambacho hakuna amri inayoweza kukibadilisha kwa ajili yako: mtandao wako. Jaribu tena ukitumia hotspot ya simu. Ikiwa hotspot inaunganisha na dawati lako haliunganishi, kizuizi kipo upande wako wa mtandao, au anwani ya ofisi yako imepigwa marufuku kwenye seva.

Firewall ya mtoa huduma ambayo huwezi kuiona kutoka kwenye seva

Paneli nyingi za VPS hutoa firewall ya mtandao, wakati mwingine huitwa security group au cloud firewall, inayofanya kazi juu ya instance yako na kuhifadhi orodha yake ya sheria. ufw status iliyo kwenye seva haiwezi kuiona, ndiyo maana "lakini tayari nimeruhusu port 22" ni sentensi ya kawaida sana. Fungua paneli hiyo na usome orodha hiyo kabla ya kubadilisha sheria yoyote kwenye seva.

Amri moja hutatua swali hili, na inahitaji ufikiaji wa console. Ianzishe kwenye seva, kisha jaribu kuunganisha kutoka kwenye laptop yako wakati inaendelea kufanya kazi.

sudo tcpdump -ni any tcp port 22

Ikiwa hakuna kinachoonekana wakati client yako inajaribu kuunganisha, pakiti hizo zinatupiliwa mbali kabla hazijafika kwenye mfumo wa uendeshaji, kwa hivyo tatizo ni firewall ya mtoa huduma au njia inayoelekea kwenye host. Ikiwa pakiti za SYN zinafika na hakuna jibu linalotoka, utupaji huo ni wa ndani na unahusu ufw au nftables. Jaribio hilo moja hugawa tawi la timeout katikati, ndiyo maana inafaa kufanya safari hiyo kwenda kwenye console.

Mpangilio wa ufw, IPv6, na kujifungia nje

Kosa la mpangilio wa ufw huwafungia watu nje mara nyingi zaidi kuliko jambo lingine lolote hapa. sudo ufw enable hutekeleza sera ya msingi ya kukataa maombi yote yanayoingia (deny incoming) mara moja, kwa hivyo bila sheria ya SSH iliyowekwa, kikao chako cha sasa kitaendelea kwa sababu ya hali ya muunganisho uliopo (established state), lakini kila muunganisho mpya utashindwa kwa muda (timeout). Ruhusu kwanza, kisha uwashe.

sudo ufw allow OpenSSH
sudo ufw status verbose

Wasifu wa programu ya OpenSSH unashughulikia port 22 pekee. Ikiwa unapanga kuhamishia SSH kwenye 2222, sheria unayohitaji ni sudo ufw allow 2222/tcp, ambayo inapaswa kuongezwa kabla ya kubadilisha port badala ya baada ya hapo. Seti pana ya sheria imeelezwa katika misingi ya firewall ya ufw kwa VPS, na mpangilio salama ni sehemu ya nini cha kufanya katika dakika kumi za kwanza kwenye VPS mpya.

IPv6 husababisha timeout inayoonekana kama ya ajabu. Ikiwa hostname ina rekodi ya AAAA, mteja wako hujaribu IPv6 kwanza, kwa hivyo seva ambayo sheria zake za IPv6 hazipo itakwama wakati jaribio la kawaida la IPv4 linafanya kazi. Tenganisha hizo mbili kwa mikono.

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

Ikiwa -4 inaunganisha na -6 haifanyi hivyo, suluhisho liko kwenye sheria za IPv6 za seva, na kufungua port ileile kwa IPv6 katika ufw inaelezea hatua za kufanya.

Huenda pia umejifungia nje mwenyewe. fail2ban hufuatilia logi ya uthibitishaji na kuingiza sheria ya firewall dhidi ya anwani zinazoshindwa mara kwa mara, kwa hivyo ufunguo usio sahihi au hati inayojaribu tena nyuma inaweza kufungia anwani nzima ya ofisi. Kufungiwa kunakoacha maombi (drop) huonekana kama timeout. Kufungiwa kunakokataa maombi (reject) hurudisha No route to host badala yake. Kutoka kwenye console:

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

Kuongeza anwani yako mwenyewe kwenye ignoreip ni sehemu ya usanidi wa fail2ban unaofanya kazi kwenye Ubuntu 24.04.

Hitilafu ambazo hazikukataliwa wala kuisha muda wake

No route to host inamaanisha ujumbe wa ICMP unreachable umerudi. Aidha mashine yako haina njia (route) kuelekea mtandao huo, au kitu fulani kwenye njia hiyo kimejibu kwa kukataa kiutawala, jambo ambalo ndilo linalofanywa na sheria ya iptables REJECT.

Network is unreachable inamaanisha mashine yako ndiyo inayozungumza. Haina njia yoyote ya anwani hiyo (address family), na hii ndiyo jawabu la kawaida wakati hostname inatatuliwa (resolve) kuwa anwani ya IPv6 pekee kwenye muunganisho wa IPv4 pekee.

kex_exchange_identification: Connection closed by remote host inamaanisha TCP imeunganishwa na seva imekata mawasiliano kabla ya ubadilishanaji wa ufunguo (key exchange) kukamilika. Port iko wazi na sshd inafanya kazi, kwa hivyo angalia mzigo wa seva (server load), angalia MaxStartups, au angalia kama kuna ban iliyojitokeza wakati ulikuwa unaunganisha.

Permission denied (publickey) inamaanisha umefika hatua ya uthibitishaji (authentication) na umeshindwa hapo. Mtandao uko sawa na firewall iko sawa, kwa hivyo hakuna kitu katika mwongozo huu kinachohusika. Nenda kwenye kurekebisha Permission denied (publickey) kwenye SSH badala yake.

Jinsi ya kurejesha ufikiaji, na jinsi ya kuepuka kufungiwa tena

Kila mtoa huduma wa VPS anayeaminika hutoa console ambayo haitegemei mtandao wa mgeni (guest network): serial console, au skrini ya VNC inayopatikana kupitia kivinjari. Console hiyo ndiyo njia ya uokoaji kwa pande zote mbili za mwongozo huu, kwa sababu inaendelea kufanya kazi hata wakati sshd imesimamishwa na hata wakati sheria ya firewall inapokataa kila kitu. Ipatikane kwenye paneli yako, ingia kama root au kama mtumiaji wako wa kawaida, kisha endesha ukaguzi uliotajwa hapo juu. Ikiwa hukuwahi kuweka nenosiri la root, paneli nyingi zinaweza kukuwekea upya.

Pale ambapo console haipo, njia mbadala ni rescue mode ya mtoa huduma. Inawasha mfumo mdogo wa uokoaji na ku-mount diski yako, ili uweze kuhariri /etc/ssh/sshd_config au kufuta sheria ya firewall ukiwa nje ya mtandao na kisha kuwasha upya seva.

Tabia mbili huzuia kufungiwa tena. Weka session ya pili ya SSH ikiwa wazi wakati wowote unapohariri sshd au firewall, kwa sababu session hiyo huendelea kufanya kazi kupitia hali iliyopo (established state) wakati unajaribu session mpya. Na jipe uwezo wa kutengua (undo) kiotomatiki kabla ya kufanya mabadiliko hatari ya firewall.

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

Mstari wa kwanza hupanga ufw kujizima baada ya dakika kumi. Tekeleza sheria zako mpya, fungua session mpya ya SSH ili kuthibitisha kuwa zinafanya kazi, kisha endesha mstari wa pili ili kufuta ule mpango wa kurudisha hali ya awali (rollback). Ikiwa utajifungia nje, subiri dakika kumi na firewall itajizima yenyewe. Hii inaiacha seva bila kichujio hadi utakapowasha ufw tena, kwa hivyo tumia njia hii ukiwa mbele ya kibodi na si kama mpangilio wa kudumu.

Utaratibu wa kufanya kazi

1. Soma maandishi ya kosa, na uone muda uliotumika kabla ya kosa hilo kutokea.
2. Refused: nenda kwenye console na uangalie sudo ss -tlnp ili kuona socket inayosikiliza, port yake, na anwani iliyofungwa nayo.
3. Timed out: kutoka kwenye mashine yako thibitisha anwani, kisha angalia firewall ya mtoa huduma kwenye paneli, na baada ya hapo angalia firewall ya seva kwenye mashine yenyewe.
4. Hakuna kati ya maandishi hayo: tayari una muunganisho wa TCP, kwa hivyo lishughulikie kama swali la uthibitishaji (authentication) au mzigo wa seva (server-load), siyo swali la mtandao.

FAQ

Kwa nini SSH inasema "Connection refused" wakati sshd inafanya kazi?

Kwa sababu kukataliwa huku kunatoka kwenye socket, si kwenye huduma yenyewe, na sshd inayofanya kazi inaweza bado kukukataa. Fungua console ya mtoa huduma wako na uendeshe sudo ss -tlnp. Socket iliyo kwenye 127.0.0.1:22 hukataa kila mteja wa mbali, kwa sababu imefungwa kwenye loopback pekee. Socket iliyo kwenye port nyingine itakataa kila mtu anayeendelea kutumia 22. Ikiwa systemd socket activation inatumika, port inatoka kwenye ssh.socket na si kwenye sshd_config, kwa hivyo kagua systemctl is-enabled ssh.socket pia. Sheria ya ufw reject pia hurejesha kukataliwa kwa niaba ya host, kwa hivyo soma sudo ufw status verbose kabla ya kuhitimisha jambo lolote.

Kwa nini SSH inakata muda (time out) wakati ufw tayari inaruhusu port 22?

Kwa sababu timeout inamaanisha hakuna jibu lililorejea, na ufw si firewall pekee iliyo kwenye njia. Paneli nyingi za VPS huendesha network firewall mbele ya instance, na mfumo wa uendeshaji haoni kamwe kile ambacho firewall hiyo inakizuia. Kutoka kwenye console, endesha sudo tcpdump -ni any tcp port 22 na ujaribu kuunganisha kutoka kwenye laptop yako wakati inaendelea kufanya kazi. Hakuna pakiti zinazofika inamaanisha kizuizi kiko juu (upstream), kwenye paneli. Pakiti zinazofika bila jibu kutoka inamaanisha kizuizi kiko ndani, kwenye ufw au nftables.

Je, ping iliyoshindwa inamaanisha VPS yangu imezimika?

Hapana. Watoa huduma wengi huchuja ICMP kwenye ukingo wa mtandao, kwa hivyo seva inayohudumia trafiki kawaida inaweza kupuuza kila ping unayotuma. Ping iliyofanikiwa ni dhaifu vilevile katika mwelekeo mwingine, kwa sababu haisemi chochote kuhusu kama port 22 iko wazi. Jaribu port yenyewe kwa kutumia nc -vz -w 5 203.0.113.10 22 kutoka kwenye mashine yako, au kwa kutumia Test-NetConnection 203.0.113.10 -Port 22 katika PowerShell kwenye Windows.

Nilibadilisha port ya SSH na sasa hakuna kinachounganishwa. Nini kilienda vibaya?

Mpangilio wa mambo mawili husababisha hili. Ikiwa firewall haijawahi kupata sheria ya port mpya, majaribio ya kuunganisha kwenye port mpya hupata timeout wakati port 22 inakataa, kwa hivyo sudo ufw allow 2222/tcp inapaswa kufanyika kabla ya mabadiliko ya port na si baada yake. Ikiwa sanduku linatumia systemd socket activation kwa ajili ya SSH, Port 2222 katika sshd_config hupuuzwa na systemd huendelea kushikilia port ya zamani, jambo ambalo unaweza kulithibitisha kwa systemctl is-enabled ssh.socket. Rekebisha kupitia console ya mtoa huduma, sahihisha kile kinachohusika, kisha unganisha kwa ssh -p 2222 user@203.0.113.10 mara tu sudo ss -tlnp itakapoonyesha socket mpya.