SSHలో Connection Refused vs Timed Out: తేడా ఏమిటి?

SSHలో “Connection refused” మరియు “Connection timed out” అర్థం

SSH connection refused మరియు SSH connection timed out అనేవి పరస్పర విరుద్ధమైన వైఫల్యాలు. అందువల్ల ఒకదానికి పనిచేసే పరిష్కారం మరొకదానికి ఎప్పుడూ పనిచేయదు. Refused అంటే మీ packet server‌‍కు చేరింది, కానీ “ఇక్కడ ఏదీ listeningలో లేదు” అని server kernel సమాధానం ఇచ్చింది. Timed out అంటే సమాధానం ఇచ్చే ఎవరినీ మీ packet చేరుకోలేదు. అందువల్ల మీ client వేచి చూసి చివరకు విఫలమైంది. Refused అనేది server‌లోని service సమస్య. Timed out అనేది server‌కు ముందున్న network path సమస్య.

మీ client ముద్రించిన ఖచ్చితమైన line‌ను చదవండి. ఎందుకంటే ఆ wording‌నే పూర్తి 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

Timing రెండవ సూచన. Refused వెంటనే తిరిగి వస్తుంది. సాధారణంగా ఒక round trip పట్టేంత సమయం మాత్రమే పడుతుంది. Timed out మాత్రం ముద్రించడానికి ముందు అనేక seconds వేచి ఉంటుంది. Client విఫలమయ్యే ముందు packet‌ను మళ్లీ మళ్లీ పంపుతుంది. అదే condition‌కు macOS Operation timed out ను ముద్రిస్తుంది. Protocol మీకు కొత్తదైతే, SSH ఎలా పనిచేస్తుంది మరియు sshd ఏమి చేస్తుంది అనే విభాగం ఈ guide‌లో భావించిన ప్రాథమిక నేపథ్యాన్ని అందిస్తుంది.

“Connection refused” అనేది శుభవార్త ఎందుకు

Refused అనేది TCP (transmission control protocol) reset. మీ client port 22 కు SYN packet పంపుతుంది. అది internet మీదుగా ప్రయాణించి server network stack కు చేరుతుంది. Kernel ఆ port పై listening చేస్తున్న socket ఏదీ లేదని గుర్తించి, RST (reset) packet తో సమాధానం ఇస్తుంది. మీ SSH client ఆ RST ను Connection refused అనే సందేశంగా చూపిస్తుంది.

తిరిగి వచ్చిన ఆ ఒక్క packet చాలా విషయాలను నిర్ధారిస్తుంది. Address సరైనదే. Host ఆన్‌లో ఉంది మరియు routing పనిచేస్తోంది. ఆ port కు వెళ్లే traffic ను మార్గమధ్యంలోని ఏదీ మౌనంగా discard చేయడం లేదు, ఎందుకంటే దూరంలోని host నుంచి సమాధానం వచ్చింది. కాబట్టి మిగిలిన అనుమానాలన్నీ server లోపలే ఉంటాయి.

• sshd నడవడం లేదు. అది start కావడంలో విఫలమై ఉండవచ్చు లేదా ఎప్పుడూ enable చేయబడకపోవచ్చు.
• sshd మరొక port పై listening చేస్తోంది. సాధారణంగా ఇది hardening మార్పు తర్వాత జరుగుతుంది.
• sshd ఒకే address కు bind అయింది, ఉదాహరణకు ListenAddress 127.0.0.1. అందువల్ల server స్వయంగా మాత్రమే దాన్ని చేరుకోగలదు.
• Firewall drop కు బదులుగా reject కు సెట్ అయింది. అందువల్ల firewall host తరఫున RST పంపుతుంది. ufw reject action మరియు reject with tcp reset తో ముగిసే nftables rule రెండూ ఇదే విధంగా పనిచేస్తాయి.

ఇవన్నీ పోలి కనిపించే మరో పరిస్థితి ఉంది, కానీ అది వేరైనది: మీరు వేరే live host కు చెందిన address ను టైప్ చేసి ఉండవచ్చు. ఆ host మీ SYN కు సమాధానం ఇస్తుంది, port 22 పై SSH ఉండదు, కాబట్టి మిమ్మల్ని మర్యాదపూర్వకంగా నిరాకరిస్తుంది. తప్పు server పై ఒక గంట వెచ్చించే ముందు address ను నిర్ధారించండి. Linux లో listening port వాస్తవంగా ఏమిటో తెలుసుకుంటే, ఈ section లోని మిగిలిన విషయం వేగంగా అర్థమవుతుంది.

కనెక్షన్ నిరాకరించబడితే ఎలా సరిచేయాలి

SSH ద్వారా దీన్ని సరిచేయలేరు, ఎందుకంటే సమస్య SSHలోనే ఉంది. మీ provider యొక్క web console లేదా serial console తెరిచి, అక్కడ sign in చేసి, తరువాత ఈ commands ను క్రమంగా అమలు చేయండి.

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

Ubuntu మరియు Debianలో systemctl status ssh unit name ను ఉపయోగిస్తుంది. RHEL మరియు AlmaLinux వంటి దాని rebuildsలో unit sshd. Listening stateలో ఉన్న ప్రతి TCP socketను, దాన్ని కలిగి ఉన్న processతో పాటు ss -tlnp చూపిస్తుంది. ఇదే ఖచ్చితమైన ఆధారం. ఏ lineలోనూ sshd కనిపించకపోతే, config file వేరే విషయం చెబుతున్నా ఏదీ listening చేయడం లేదు. ప్రతి Include file merge చేసిన తరువాత effective configurationను sshd -T చూపిస్తుంది. /etc/ssh/sshd_config.d/లో మరచిపోయిన port ఎక్కడ కనిపిస్తుందో ఇదే చోటు.

Address columnను జాగ్రత్తగా పరిశీలించండి. 0.0.0.0:22 అంటే serverలోని ప్రతి IPv4 address. [::]:22 అంటే ప్రతి IPv6 address. 127.0.0.1:22 అంటే loopbackకు మాత్రమే bind అయి ఉందని అర్థం. అందువల్ల ప్రతి remote connection నిరాకరించబడుతుంది, అయితే local ssh localhost సరిగ్గా పనిచేస్తుంది.

ఏదీ listening చేయకపోతే serviceను start చేసి, అది start కాకపోయినప్పుడు వచ్చే failureను చదవండి.

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

sshd -t configurationను parse చేసి, running serviceను ప్రభావితం చేయకుండా తప్పు directive ఉన్న file మరియు line numberను చూపిస్తుంది. ప్రతి restartకు ముందు దీన్ని అమలు చేయండి. తిరస్కరించబడిన config కారణంగా sshd start సమయంలోనే exit అవుతుంది. అప్పుడు మీ తదుపరి connection నిరాకరించబడుతుంది.

Ubuntuలో socket activation ఉచ్చు

Ubuntu 24.04 OpenSSH కోసం systemd socket unit ను అందిస్తుంది. ఆ unit enable అయి ఉంటే, systemd listening port ను తన ఆధీనంలో ఉంచి, ప్రతి connection కోసం sshd ను ప్రారంభిస్తుంది. అందువల్ల Port 2222 లోని మార్పు sshd_config లో ఎలాంటి ప్రభావం చూపదు, server పాత port పైనే స్పందిస్తుంది. ఏదైనా సవరించే ముందు మీ server ఏ mode లో ఉందో పరిశీలించండి.

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

socket enable అయి ఉంటే, port ను sshd_config లో కాకుండా socket unit లో సెట్ చేయండి.

sudo systemctl edit ssh.socket

[Socket]
ListenStream=
ListenStream=2222

ఖాళీ ListenStream= line అవసరం, ఎందుకంటే systemd list settings ఇప్పటికే configure చేసిన విలువలకు జత అవుతాయి. దీన్ని వదిలేస్తే server రెండు ports పై listen చేస్తుంది. sudo systemctl daemon-reload మరియు sudo systemctl restart ssh.socket తో మార్పును అమలు చేయండి. తరువాత కొత్త port ఆధీనంలో ఉందని sudo ss -tlnp తో నిర్ధారించండి. VPSలో SSH ను harden చేయడంలో port మార్చడం సాధారణ దశ. వ్యక్తులను server నుంచి బయటకు lock చేసే అవకాశం ఎక్కువగా ఉన్న దశ కూడా ఇదే.

“Connection timed out” అంటే ఏదీ సమాధానం ఇవ్వలేదని అర్థం

Timeout అంటే నిశ్శబ్దం. మీ client ఒక SYN పంపి, ఒకటి లేదా రెండు నిమిషాలపాటు అనేకసార్లు మళ్లీ పంపినా, ప్రతిగా ఒక్క packet కూడా అందుకోలేదు. ఇక్కడ server గురించి ఏదీ నిర్ధారించలేం, ఎందుకంటే server నుంచి ఎలాంటి ప్రతిస్పందన వినిపించలేదు.

DROP rule సృష్టించేది ఇదే నిశ్శబ్దం; packets ను drop చేయడం ఉద్దేశపూర్వకమే. Rejection పంపితే host ఉందని scanning చేస్తున్న వారికి తెలుస్తుంది. అందుకే ufw మరియు ప్రతి cloud provider యొక్క network firewall అనవసర packets ను discard చేసి, తిరిగి ఏమీ పంపవు. మీరు తెరిచి ఉండాలని కోరుకున్న port పై firewall తన పని చేయడం వల్లే సాధారణంగా timeout వస్తుంది.

• Address తప్పుగా ఉంది: మీరు rebuild చేసిన server వైపు DNS record ఇంకా చూపుతూ ఉండవచ్చు, లేదా ఎవరూ ఉపయోగించని address కు తీసుకెళ్లే typo ఉండవచ్చు.
• Host ప్రారంభించి ఉండకపోవచ్చు: అది power off అయి ఉండవచ్చు లేదా reboot మధ్యలో ఉండవచ్చు. Billing సమస్య కారణంగా provider suspension చేసినా, బయట నుంచి చూస్తే ఇదే విధంగా కనిపిస్తుంది.
• Host firewall port 22 ను drop చేస్తోంది. సాధారణంగా ఏ allow rule ఉండకముందే ufw enable అమలు చేసినప్పుడు ఇది జరుగుతుంది.
• Instance ముందు ఉన్న provider firewall packet ను drop చేస్తోంది. అందువల్ల operating system కు packet అసలు కనిపించదు.
• మీ స్వంత network outbound port 22 ను block చేస్తోంది. Office మరియు hotel connections లో ఇది సాధారణం.

కనెక్షన్‌కు సరైన వైపు నుంచి పరీక్షను అమలు చేయండి

ఎక్కువ సమయం వృథా చేసే పొరపాటు ఇదే. ప్యాకెట్లు చేరని సర్వర్‌లోనే ఉండి dropped packet సమస్యను నిర్ధారించలేరు. ఆదేశాన్ని అమలు చేయడానికి మీరు login చేయగలిగితే, అసలు ఈ సమస్య ఉండేది కాదు. ఈ విభాగంలోని ప్రతి ఆదేశాన్ని మీ స్వంత 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

getent hosts మీ machine వాస్తవంగా ఉపయోగించే addressను చూపుతుంది. దీనివల్ల పాత DNS recordను కొన్ని secondsలో గుర్తించవచ్చు. ssh -G, ~/.ssh/config ను చదివిన తర్వాత మీ client వర్తింపజేసే settingsను చూపుతుంది. అందువల్ల hostname, port లేదా userను నిశ్శబ్దంగా మార్చే పాత Host blockను గుర్తించవచ్చు. ప్రయత్నం ఎంతవరకు సాగిందో ssh -vvv చూపుతుంది: addressకు connecting చేస్తున్నట్లు చూపిన చివరి line తర్వాత ఎక్కువసేపు వేచి ఉంటే అది timeout. అయితే remote OpenSSH versionను చూపించే line కనిపిస్తే TCP ఇప్పటికే విజయవంతమైంది. అప్పుడు అసలు సమస్య authenticationలో ఉంటుంది. Windowsలో PowerShellలో Test-NetConnection 203.0.113.10 -Port 22, nc కు ప్రత్యామ్నాయం.

hostను కాదు, portను పరీక్షించండి. ping విఫలమైందని మాత్రమే చూస్తే ఏ విషయం నిర్ధారించలేరు. చాలా providers అంచు వద్ద ICMP (internet control message protocol)ను filter చేస్తాయి. ping విజయవంతమైనా ఏ విషయమూ నిర్ధారించలేరు, ఎందుకంటే అది port 22 గురించి ఏమీ చెప్పదు.

తర్వాత మీ కోసం ఏ command మార్చలేని ఒక variableను మార్చండి: మీ network. phone hotspot నుంచి మళ్లీ ప్రయత్నించండి. hotspot ద్వారా connection ఏర్పడి, మీ desk network ద్వారా ఏర్పడకపోతే, block internetలో మీ వైపునే ఉంది. లేదా మీ office address serverలో ban అయి ఉండవచ్చు.

సర్వర్‌ నుంచి కనిపించని provider firewall

చాలా VPS panels లో network firewall ఉంటుంది. దీనిని security group లేదా cloud firewall అని కూడా పిలుస్తారు. ఇది మీ instance కంటే upstream లో అమలవుతుంది మరియు సొంత rule list ను నిర్వహిస్తుంది. సర్వర్‌లోని ufw status దాన్ని చూడలేరు. అందుకే “నేను ఇప్పటికే port 22 ను అనుమతించాను” అనే మాట తరచుగా వినిపిస్తుంది. సర్వర్‌లో ఒక్క rule ను కూడా మార్చే ముందు panel తెరిచి ఆ list ను పరిశీలించండి.

ఒక command తో విషయం నిర్ధారించవచ్చు. దీనికి console access అవసరం. సర్వర్‌లో దీన్ని ప్రారంభించి, ఇది నడుస్తున్నప్పుడు మీ laptop నుంచి connect కావడానికి ప్రయత్నించండి.

sudo tcpdump -ni any tcp port 22

మీ client ప్రయత్నిస్తున్న సమయంలో ఏమీ కనిపించకపోతే, packets operating system కు చేరకముందే discard అవుతున్నాయి. అప్పుడు సమస్య provider firewall లో లేదా host కు వెళ్లే route లో ఉంటుంది. SYN packets చేరి, ఎలాంటి reply బయటకు వెళ్లకపోతే, drop స్థానికంగానే జరుగుతోంది. దానికి ufw లేదా nftables బాధ్యత వహిస్తుంది. ఈ ఒక్క పరీక్ష timeout సమస్యను రెండు భాగాలుగా విభజిస్తుంది. అందుకే console access కోసం వెళ్లడం ఉపయోగకరం.

ufw నియమాల క్రమం, IPv6 మరియు మీరే మీకు విధించిన ban

ఇక్కడి ఇతర సమస్యలకన్నా ufw నియమాల క్రమంలో చేసే పొరపాటు ఎక్కువ మందిని సర్వర్‌ నుంచి బయటకు నెట్టేస్తుంది. sudo ufw enable వెంటనే incoming కనెక్షన్లకు default deny policy ను వర్తింపజేస్తుంది. అందువల్ల SSH rule లేకపోతే, established state కారణంగా ప్రస్తుత session కొనసాగుతుంది. అయితే ప్రతి కొత్త కనెక్షన్ timeout అవుతుంది. ముందుగా allow rule జోడించండి. తరువాత enable చేయండి.

sudo ufw allow OpenSSH
sudo ufw status verbose

OpenSSH application profile కేవలం port 22 ను మాత్రమే కవర్ చేస్తుంది. SSH ను 2222 కు మార్చాలని ఉంటే, port మార్పు చేసిన తరువాత కాకుండా ముందుగానే sudo ufw allow 2222/tcp rule ను జోడించాలి. విస్తృత rule set గురించి VPS కోసం ufw firewall ప్రాథమికాలు లో వివరించబడింది. సురక్షితమైన క్రమం కొత్త VPSలో మొదటి పది నిమిషాల్లో చేయాల్సినవి లో భాగంగా ఉంది.

IPv6 వల్ల అర్థంకాని timeout వచ్చినట్లు అనిపించవచ్చు. hostname కు AAAA record ఉంటే, మీ client ముందుగా IPv6 ద్వారా ప్రయత్నిస్తుంది. అందువల్ల serverలో IPv6 rules లేకపోతే కనెక్షన్ నిలిచిపోతుంది. సాధారణ IPv4 ప్రయత్నం మాత్రం పనిచేస్తుంది. రెండింటినీ చేతితో వేరు చేసి పరీక్షించండి.

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

-4 కనెక్ట్ అయి, -6 కనెక్ట్ కాకపోతే, సమస్య serverలోని IPv6 rulesలో ఉంది. ufwలో IPv6 కోసం అదే portను తెరవడం దానికి సంబంధించిన దశలను వివరిస్తుంది.

మీరు మీరే ban చేసుకుని ఉండవచ్చు. fail2ban authentication log ను monitor చేసి, పలుమార్లు విఫలమయ్యే addresses కు వ్యతిరేకంగా firewall rule ను జోడిస్తుంది. అందువల్ల తప్పు key లేదా backgroundలో మళ్లీ మళ్లీ ప్రయత్నించే script మొత్తం office address ను lock out చేయవచ్చు. కనెక్షన్‌ను drop చేసే ban timeout లా కనిపిస్తుంది. reject చేసే ban బదులుగా No route to host ను తిరిగి ఇస్తుంది. Console నుంచి:

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

మీ స్వంత address ను ignoreip కు జోడించడం Ubuntu 24.04లో పనిచేసే fail2ban setup లోని ఒక భాగం.

తిరస్కరించబడని లేదా సమయం ముగియని లోపాలు

No route to host అంటే ICMP unreachable సందేశం తిరిగి వచ్చింది. మీ స్వంత machine కు ఆ network వైపు route లేకపోవచ్చు, లేదా మార్గంలోని ఏదైనా పరికరం administrative rejection తో స్పందించి ఉండవచ్చు. iptables REJECT rule పంపేది ఇదే.

Network is unreachable మీ స్వంత machine స్పందిస్తోందని అర్థం. ఆ address family కోసం దానికి ఎలాంటి route లేదు. IPv4-only connection పై hostname కేవలం IPv6 address కు resolve అయినప్పుడు సాధారణంగా కనిపించే సమాధానం ఇదే.

kex_exchange_identification: Connection closed by remote host అంటే TCP connection ఏర్పడింది, కానీ key exchange పూర్తయ్యేలోపు server connection ను మూసివేసింది. Port open గా ఉంది మరియు sshd అమలులో ఉంది. కాబట్టి server load, MaxStartups లేదా మీరు connect అవుతున్న సమయంలో అమలులోకి వచ్చిన ban ను పరిశీలించండి.

Permission denied (publickey) అంటే మీరు authentication దశకు చేరుకుని అక్కడ విఫలమయ్యారు. Network మరియు firewall సరిగానే ఉన్నాయి. కాబట్టి ఈ guide లోని విషయాలు ఇక్కడ వర్తించవు. బదులుగా SSHలో Permission denied (publickey) సమస్యను పరిష్కరించడం కు వెళ్లండి.

తిరిగి యాక్సెస్ పొందడం, రెండోసారి లాక్‌అవుట్‌ను నివారించడం

ప్రతి విశ్వసనీయ VPS హోస్ట్ guest యొక్క network పై ఆధారపడని console ను అందిస్తుంది. ఇది serial console లేదా browser ఆధారిత VNC screen కావచ్చు. ఈ guide లోని రెండు మార్గాలకూ ఆ console recovery మార్గంగా పనిచేస్తుంది. sshd ఆపివేసినా, firewall rule అన్ని network traffic ను discard చేసినా అది పనిచేస్తుంది. దాన్ని panel లో కనుగొని, root గా లేదా మీ సాధారణ user గా sign in చేసి, పైన ఉన్న తనిఖీలను అమలు చేయండి. మీరు root password ఎప్పుడూ set చేయకపోతే, చాలా panels మీ కోసం దాన్ని reset చేయగలవు.

Console అందుబాటులో లేని చోట provider యొక్క rescue mode ప్రత్యామ్నాయంగా ఉపయోగించాలి. ఇది చిన్న recovery system ను boot చేసి, మీ disk ను mount చేస్తుంది. అందువల్ల మీరు /etc/ssh/sshd_config ను edit చేయవచ్చు లేదా firewall rule ను offline లో delete చేసి reboot చేయవచ్చు.

తదుపరి lockout ను రెండు అలవాట్లు నివారిస్తాయి. sshd లేదా firewall ను edit చేస్తున్నప్పుడు ఎల్లప్పుడూ రెండో SSH session ను తెరిచి ఉంచండి. మీరు కొత్త session ను పరీక్షిస్తున్నప్పుడు established state పై ఉన్న ఆ session కొనసాగుతుంది. అలాగే ప్రమాదకరమైన firewall మార్పుకు ముందు స్వయంచాలకంగా undo అయ్యే విధానాన్ని ఏర్పాటు చేయండి.

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

మొదటి line పది నిమిషాల్లో ufw తానే off అయ్యేలా schedule చేస్తుంది. మీ కొత్త rules ను apply చేసి, అవి పనిచేస్తున్నాయని నిర్ధారించడానికి కొత్త SSH session ను open చేయండి. తరువాత rollback ను cancel చేయడానికి రెండో line ను run చేయండి. బదులుగా మీరు lockout అయితే, పది నిమిషాలు వేచి ఉండండి. అప్పుడు firewall స్వయంగా నిలిచిపోతుంది. మీరు ufw ను మళ్లీ enable చేసే వరకు ఇది box ను filtering లేకుండా ఉంచుతుంది. కాబట్టి keyboard వద్ద ఉన్నప్పుడు మాత్రమే దీన్ని ఉపయోగించండి; శాశ్వత ఏర్పాటుగా ఉపయోగించవద్దు.

పరిశీలించాల్సిన క్రమం

1. Error text చదివి, అది కనిపించడానికి ఎంత సమయం పట్టిందో గమనించండి.
2. Refused: console కు వెళ్లి, listening socket, దాని port, అలాగే అది bind అయిన address కోసం sudo ss -tlnp ను తనిఖీ చేయండి.
3. Timed out: మీ స్వంత machine నుంచి address ను నిర్ధారించండి. తరువాత panel లోని provider firewall ను, ఆపై box లోని host firewall ను తనిఖీ చేయండి.
4. ఈ రెండు strings లో ఏదీ లేకపోతే: మీకు ఇప్పటికే TCP connection ఉంది. కాబట్టి దీన్ని network సమస్యగా కాకుండా authentication లేదా server-load సమస్యగా పరిగణించండి.

FAQ

SSH నడుస్తున్నప్పటికీ "Connection refused" అని ఎందుకు చూపిస్తుంది?

ఈ refusal సేవ నుంచి కాకుండా socket నుంచి వస్తుంది. కాబట్టి sshd నడుస్తున్నా connection ను తిరస్కరించవచ్చు. provider console ను తెరిచి sudo ss -tlnp ను అమలు చేయండి. 127.0.0.1:22 పై ఉన్న socket ప్రతి remote client ను తిరస్కరిస్తుంది, ఎందుకంటే అది loopback కు మాత్రమే bind అయి ఉంటుంది. మరో port పై ఉన్న socket ను ఇప్పటికీ 22 ఉపయోగిస్తున్న clients అందరూ చేరుకోలేరు. systemd socket activation ఉపయోగిస్తే port sshd_config నుంచి కాకుండా ssh.socket నుంచి వస్తుంది. అందువల్ల systemctl is-enabled ssh.socket ను కూడా పరిశీలించండి. ufw లోని reject rule కూడా host తరఫున refusal పంపవచ్చు. కాబట్టి ఏదైనా నిర్ణయానికి ముందు sudo ufw status verbose ను చదవండి.

ufw ఇప్పటికే port 22 ను అనుమతిస్తున్నప్పుడు SSH ఎందుకు timeout అవుతుంది?

Timeout అంటే ఎటువంటి సమాధానం తిరిగి రాలేదని అర్థం. మార్గంలో ఉన్న ఏకైక firewall ufw కాదు. చాలా VPS panels instance ముందు network firewall ను అమలు చేస్తాయి. ఆ firewall drop చేసిన traffic operating system కు కనిపించదు. console నుంచి sudo tcpdump -ni any tcp port 22 ను అమలు చేసి, అది నడుస్తున్నప్పుడు మీ laptop నుంచి connect చేయడానికి ప్రయత్నించండి. ఏ packets కూడా చేరకపోతే drop upstream లో, అంటే panel లో జరుగుతోంది. Packets చేరుతున్నా reply బయటకు వెళ్లకపోతే drop local గా, అంటే ufw లేదా nftables లో జరుగుతోంది.

ping విఫలమైందంటే నా VPS down అయిందని అర్థమా?

లేదు. చాలా providers network edge వద్ద ICMP ను filter చేస్తాయి. అందువల్ల traffic ను సాధారణంగా అందిస్తున్న server మీరు పంపే ప్రతి ping ను పట్టించుకోకపోవచ్చు. Ping విజయవంతమైనా దాని ద్వారా port 22 open ఉందో లేదో తెలియదు. మీ స్వంత machine నుంచి nc -vz -w 5 203.0.113.10 22 తో port ను నేరుగా test చేయండి. Windows లో PowerShell ఉపయోగిస్తే Test-NetConnection 203.0.113.10 -Port 22 తో test చేయండి.

SSH port ను మార్చిన తర్వాత ఏదీ connect కావడం లేదు. ఏం తప్పు జరిగింది?

ఇక్కడ రెండు క్రమపద్ధతి సమస్యలు కారణం కావచ్చు. కొత్త port కు firewall rule ను ముందుగా జోడించకపోతే, కొత్త port కు చేసిన ప్రయత్నాలు timeout అవుతాయి, port 22 refusal ఇస్తుంది. కాబట్టి sudo ufw allow 2222/tcp ను port మార్చే ముందు అమలు చేయాలి, తరువాత కాదు. ఈ system SSH కోసం systemd socket activation ఉపయోగిస్తే, sshd_config లోని Port 2222 పట్టించుకోబడదు. systemd పాత port ను ఉపయోగిస్తూనే ఉంటుంది. దీనిని systemctl is-enabled ssh.socket తో నిర్ధారించవచ్చు. provider console ద్వారా system కు తిరిగి చేరి, వర్తించే సమస్యను సరిచేయండి. తరువాత sudo ss -tlnp కొత్త socket ను చూపించినప్పుడు ssh -p 2222 user@203.0.113.10 తో connect చేయండి.