SSH Connection Refused और Timed Out में क्या अंतर है

SSH में "Connection refused" और "Connection timed out" का क्या अर्थ है

SSH connection refused और SSH connection timed out विपरीत प्रकार की विफलताएं हैं, इसलिए एक का समाधान दूसरे के लिए कभी काम नहीं आता। Refused का अर्थ है कि आपका पैकेट सर्वर तक पहुँच गया और सर्वर के kernel ने जवाब दिया कि "यहाँ कोई service listening मोड में नहीं है"। Timed out का अर्थ है कि आपका पैकेट किसी ऐसे व्यक्ति तक नहीं पहुँचा जो जवाब दे सके, इसलिए आपके client ने प्रतीक्षा की और अंततः प्रयास छोड़ दिया। Refused सर्वर पर मौजूद service की समस्या है। Timed out उसके सामने आने वाली path की समस्या है।

अपने client द्वारा प्रिंट की गई सटीक लाइन को पढ़ें, क्योंकि उसका शब्द-विन्यास ही पूरा निदान है।

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 प्रिंट होने से पहले कई सेकंड तक रुका रहता है, क्योंकि client हार मानने से पहले बार-बार retransmit करता रहता है। macOS इसी स्थिति के लिए Operation timed out प्रिंट करता है। यदि आप इस protocol से परिचित नहीं हैं, तो SSH कैसे काम करता है और sshd क्या करता है वह पृष्ठभूमि है जिसे यह गाइड मानकर चलती है।

"Connection refused" अच्छी खबर क्यों है

Refused एक TCP (transmission control protocol) रिसेट है। आपका क्लाइंट port 22 पर एक SYN पैकेट भेजता है। यह इंटरनेट से होकर सर्वर के नेटवर्क स्टैक तक पहुँचता है, और kernel को उस port पर कोई socket listening नहीं मिलता, इसलिए वह एक RST (reset) पैकेट के साथ जवाब देता है। आपका SSH क्लाइंट उस RST को Connection refused शब्दों में बदल देता है।

वह एक वापस आने वाला पैकेट बहुत कुछ साबित करता है। पता सही है। host चालू है और routing कर रहा है। रास्ते में कोई भी चीज़ उस port पर traffic को चुपचाप discard नहीं कर रही है, क्योंकि दूर के छोर से कुछ वापस आया है। इसलिए बाकी सभी संदेह सर्वर पर ही स्थित हैं।

• sshd नहीं चल रहा है, क्योंकि यह start होने में विफल रहा या इसे कभी enable नहीं किया गया था।
• sshd किसी अन्य port पर listening है, आमतौर पर hardening बदलाव के बाद।
• sshd एक पते से बंधा है, जैसे कि ListenAddress 127.0.0.1, इसलिए केवल सर्वर ही इसे access कर सकता है।
• एक firewall को drop करने के बजाय reject करने के लिए set किया गया है, इसलिए firewall host की ओर से RST भेजता है। ufw reject action और reject with tcp reset पर समाप्त होने वाला nftables rule दोनों ऐसा ही करते हैं।

एक और मामला इनके जैसा दिखता है लेकिन है नहीं: आपने एक ऐसा पता टाइप किया जो किसी अन्य live host का है। वह host आपके SYN का जवाब देता है, port 22 पर कोई SSH नहीं है, और आपको विनम्रतापूर्वक मना कर देता है। गलत सर्वर पर एक घंटा बिताने से पहले पते की पुष्टि करें। Linux पर listening port वास्तव में क्या होता है यह जानने से इस अनुभाग का बाकी हिस्सा तेजी से समझ में आता है।

Connection refused को कैसे ठीक करें

आप इसे SSH के माध्यम से ठीक नहीं कर सकते, क्योंकि SSH ही वह सेवा है जो खराब हो चुकी है। अपने प्रदाता के वेब कंसोल या सीरियल कंसोल को खोलें, वहां साइन इन करें, और फिर नीचे दिए गए commands का पालन करें।

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

systemctl status ssh Ubuntu और Debian पर unit name का उपयोग करता है। RHEL और इसके rebuilds जैसे AlmaLinux पर, unit sshd है। ss -tlnp listening state में मौजूद हर TCP socket को उस process के साथ सूचीबद्ध करता है जो उसका स्वामी है, और यह सबसे सटीक जानकारी है: यदि कोई भी line sshd का उल्लेख नहीं करती है, तो कुछ भी listen नहीं कर रहा है, चाहे configuration file में कुछ भी दावा किया गया हो। sshd -T हर Include file के merge होने के बाद प्रभावी configuration को print करता है, जहाँ /etc/ssh/sshd_config.d/ में भूली हुई port दिखाई देती है।

Address column को ध्यान से पढ़ें। 0.0.0.0:22 का अर्थ है box पर मौजूद हर IPv4 address। [::]:22 का अर्थ है हर IPv6 address। 127.0.0.1:22 का अर्थ है केवल loopback, इसलिए इस पर आने वाला हर remote connection अस्वीकार (refused) कर दिया जाता है जबकि स्थानीय ssh localhost पूरी तरह से काम करता है।

यदि कुछ भी listen नहीं कर रहा है, तो service को start करें और start न होने पर आने वाली त्रुटि (failure) को पढ़ें।

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

sshd -t configuration को parse करता है और चल रही service को प्रभावित किए बिना एक गलत directive की file और line number को print करता है। इसे हर restart से पहले चलाएं, क्योंकि एक rejected config का मतलब है कि sshd start होते ही exit हो जाएगा और आपका अगला connection अस्वीकार (refused) कर दिया जाएगा।

Ubuntu पर socket activation की समस्या

Ubuntu 24.04 में OpenSSH के लिए एक systemd socket unit शामिल है। जहाँ यह unit enabled होती है, वहाँ systemd listening port को नियंत्रित करता है और प्रत्येक connection के लिए sshd को start करता है। इस स्थिति में Port 2222 को sshd_config में बदलने से कोई प्रभाव नहीं पड़ता और सर्वर पुराने port पर ही जवाब देता रहता है। किसी भी बदलाव से पहले यह जाँच लें कि आपका सिस्टम किस mode में है।

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

यदि socket enabled है, तो port को sshd_config के बजाय socket unit में set करें।

sudo systemctl edit ssh.socket

[Socket]
ListenStream=
ListenStream=2222

खाली ListenStream= line आवश्यक है, क्योंकि systemd list settings पहले से कॉन्फ़िगर की गई सेटिंग्स में जुड़ जाती हैं। यदि आप इसे हटा देंगे, तो सर्वर दोनों ports पर listen करेगा। बदलावों को sudo systemctl daemon-reload और sudo systemctl restart ssh.socket के साथ लागू करें, फिर sudo ss -tlnp के साथ पुष्टि करें कि नया port ही active है। Port बदलना VPS पर SSH को सुरक्षित करने का एक सामान्य चरण है, और यही वह चरण है जिससे लोग सबसे अधिक बार खुद को सर्वर से बाहर लॉक कर लेते हैं।

"Connection timed out" का अर्थ यह क्यों है कि कोई उत्तर नहीं मिला

Timeout का अर्थ है चुप्पी। आपके client ने एक SYN भेजा, उसे एक या दो मिनट में कई बार retransmit किया, और बदले में एक भी packet प्राप्त नहीं हुआ। यहाँ server के बारे में कुछ भी सिद्ध नहीं होता है, क्योंकि server से कुछ भी नहीं सुना गया।

चुप्पी ठीक वही है जो एक DROP नियम उत्पन्न करता है, और dropping जानबूझकर की जाती है। एक rejection किसी भी scanning करने वाले को यह बता देता है कि host मौजूद है, इसलिए ufw और हर cloud provider का network firewall अवांछित packets को discard कर देता है और वापस कुछ नहीं भेजता। आपका timeout आमतौर पर एक firewall होता है जो उस port पर अपना काम कर रहा है जिसे आप open रखना चाहते थे।

• पता गलत है: एक DNS record अभी भी उस server की ओर इशारा कर रहा है जिसे आपने rebuild किया है, या कोई typo जो ऐसे पते पर ले जाता है जिसका कोई उपयोग नहीं करता।
• host चालू नहीं है: बंद है, या reboot होने की प्रक्रिया में है। billing के कारण provider द्वारा suspension बाहर से बिल्कुल वैसा ही दिखता है।
• host firewall port 22 को drop करता है, अक्सर इसलिए क्योंकि किसी भी allow नियम के मौजूद होने से पहले ufw enable चल गया था।
• instance के सामने मौजूद एक provider firewall इसे drop कर देता है, और operating system को packet कभी दिखाई ही नहीं देता।
• आपका अपना network outbound port 22 को block करता है, जो office और hotel connections पर आम है।

कनेक्शन के दाईं ओर से टेस्ट चलाएं

यह वह गलती है जिसमें सबसे अधिक समय बर्बाद होता है। आप उस बॉक्स के अंदर से पैकेट ड्रॉप होने का निदान नहीं कर सकते जहाँ पैकेट पहुँच ही नहीं रहे हैं। यदि आप कमांड चलाने के लिए लॉग इन कर सकते, तो आपको यह समस्या होती ही नहीं। इस अनुभाग की प्रत्येक कमांड आपकी अपनी मशीन पर चलती है।

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 वह पता दिखाता है जिसका उपयोग आपकी मशीन वास्तव में करेगी, जो पुराने DNS रिकॉर्ड को सेकंडों में पकड़ लेता है। ssh -G उन सेटिंग्स को प्रिंट करता है जिन्हें आपका क्लाइंट ~/.ssh/config पढ़ने के बाद लागू करता है, इसलिए यह एक पुराने Host ब्लॉक को पकड़ लेता है जो चुपचाप होस्टनेम, पोर्ट या यूजर को फिर से लिख देता है। ssh -vvv दिखाता है कि प्रयास कहाँ तक पहुँचा: पते से कनेक्ट होने के बारे में अंतिम पंक्ति के बाद लंबा ठहराव एक टाइमआउट है, जबकि रिमोट OpenSSH संस्करण की रिपोर्ट करने वाली पंक्ति का मतलब है कि TCP पहले ही सफल हो चुका है और आपकी वास्तविक समस्या ऑथेंटिकेशन है। Windows पर, PowerShell में Test-NetConnection 203.0.113.10 -Port 22, nc की जगह लेता है।

होस्ट को नहीं, पोर्ट को टेस्ट करें। एक विफल ping कुछ भी साबित नहीं करता, क्योंकि कई प्रदाता किनारे (edge) पर ICMP (internet control message protocol) को फिल्टर करते हैं। एक सफल पिंग भी कुछ साबित नहीं करता, क्योंकि यह पोर्ट 22 के बारे में कुछ नहीं बताता।

फिर उस एक वेरिएबल को बदलें जिसे कोई भी कमांड आपके लिए नहीं बदल सकती: आपका नेटवर्क। फोन हॉटस्पॉट से पुनः प्रयास करें। यदि हॉटस्पॉट कनेक्ट हो जाता है और आपका डेस्क नहीं, तो ब्लॉक इंटरनेट के आपकी तरफ है, या आपके ऑफिस के पते को सर्वर पर बैन कर दिया गया है।

वह provider firewall जिसे आप सर्वर से नहीं देख सकते

अधिकांश VPS panels एक network firewall प्रदान करते हैं, जिसे कभी-कभी security group या cloud firewall कहा जाता है। यह आपके instance के upstream चलता है और अपनी स्वयं की rule list रखता है। सर्वर पर मौजूद ufw status इसे नहीं देख सकता, इसीलिए "लेकिन मैंने port 22 पहले ही allow कर दिया है" एक बहुत ही सामान्य वाक्य है। सर्वर पर कोई भी 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 local है और यह ufw या nftables से संबंधित है। वह एक परीक्षण timeout की स्थिति को दो भागों में विभाजित कर देता है, इसीलिए console तक जाना सार्थक है।

ufw ऑर्डरिंग, IPv6, और खुद को ब्लॉक करना

ufw ऑर्डरिंग की गलती यहाँ सबसे अधिक लोगों को लॉक-आउट करती है। sudo ufw enable तुरंत incoming के लिए default policy को deny पर सेट कर देता है, इसलिए यदि SSH नियम पहले से मौजूद नहीं है, तो आपका वर्तमान सेशन established state के कारण चलता रहेगा, लेकिन हर नया कनेक्शन टाइम-आउट हो जाएगा। पहले Allow करें, फिर enable करें।

sudo ufw allow OpenSSH
sudo ufw status verbose

OpenSSH एप्लिकेशन प्रोफाइल केवल port 22 को कवर करती है। यदि आप SSH को 2222 पर ले जाने की योजना बना रहे हैं, तो आपको sudo ufw allow 2222/tcp नियम की आवश्यकता होगी, जिसे पोर्ट बदलने से पहले ही जोड़ना होगा। नियमों का विस्तृत सेट ufw फायरवॉल बेसिक्स फॉर ए VPS में दिया गया है, और सुरक्षित ऑर्डरिंग नए VPS पर पहले दस मिनट में क्या करें का हिस्सा है।

IPv6 एक ऐसा टाइम-आउट पैदा करता है जो असामान्य लगता है। यदि होस्टनेम में AAAA रिकॉर्ड है, तो आपका क्लाइंट पहले IPv6 का प्रयास करेगा, इसलिए जिस सर्वर पर IPv6 नियम नहीं हैं, वह हैंग हो जाएगा जबकि सामान्य IPv4 प्रयास काम करेगा। दोनों को मैन्युअल रूप से अलग करें।

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

यदि -4 कनेक्ट होता है और -6 नहीं, तो समाधान सर्वर के IPv6 नियमों में है, और ufw में IPv6 के लिए समान पोर्ट खोलना इसे विस्तार से समझाता है।

हो सकता है कि आपने खुद को ही ब्लॉक कर लिया हो। fail2ban ऑथेंटिकेशन लॉग को मॉनिटर करता है और बार-बार विफल होने वाले एड्रेस के खिलाफ फायरवॉल नियम डाल देता है, इसलिए गलत की (key) या बैकग्राउंड में रिट्राई करने वाली स्क्रिप्ट पूरे ऑफिस के एड्रेस को लॉक कर सकती है। जो बैन कनेक्शन को ड्रॉप करता है, वह टाइम-आउट जैसा दिखता है। जो बैन रिजेक्ट करता है, वह No route to host रिटर्न करता है। कंसोल से:

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

अपने एड्रेस को ignoreip में जोड़ना Ubuntu 24.04 पर एक वर्किंग fail2ban सेटअप का हिस्सा है।

ऐसी त्रुटियाँ जो न तो रिफ्यूज्ड हैं और न ही टाइम आउट

No route to host का अर्थ है कि एक ICMP unreachable संदेश वापस आया है। या तो आपकी अपनी मशीन के पास उस नेटवर्क के लिए कोई रूट नहीं है, या रास्ते में किसी चीज़ ने प्रशासनिक अस्वीकृति (administrative rejection) के साथ उत्तर दिया है, जो कि iptables REJECT नियम द्वारा भेजा जाता है।

Network is unreachable आपकी अपनी मशीन द्वारा दिया गया उत्तर है। इसके पास उस एड्रेस फैमिली के लिए कोई रूट नहीं है, और यह आमतौर पर तब होता है जब कोई होस्टनेम केवल IPv6 पते पर रिज़ॉल्व होता है, जबकि कनेक्शन केवल IPv4 का है।

kex_exchange_identification: Connection closed by remote host का अर्थ है कि TCP कनेक्शन स्थापित हो गया था, लेकिन की-एक्सचेंज (key exchange) पूरा होने से पहले ही सर्वर ने कनेक्शन काट दिया। पोर्ट खुला है और sshd सक्रिय है, इसलिए सर्वर लोड, MaxStartups, या कनेक्शन के दौरान लागू हुए किसी बैन (ban) की जाँच करें।

Permission denied (publickey) का अर्थ है कि आप ऑथेंटिकेशन तक पहुँच गए थे और वहाँ विफल रहे। नेटवर्क और फायरवाल ठीक हैं, इसलिए इस गाइड की कोई भी बात यहाँ लागू नहीं होती। इसके बजाय SSH पर Permission denied (publickey) को ठीक करना पर जाएँ।

वापस कैसे प्रवेश करें, और दोबारा लॉकआउट से कैसे बचें

प्रत्येक गंभीर VPS होस्ट आपको एक ऐसा कंसोल देता है जो गेस्ट के नेटवर्क पर निर्भर नहीं होता: एक सीरियल कंसोल, या ब्राउज़र-आधारित VNC स्क्रीन। यह कंसोल इस गाइड की दोनों शाखाओं के लिए रिकवरी का रास्ता है, क्योंकि यह तब भी काम करता है जब sshd बंद हो और तब भी जब कोई firewall rule सब कुछ डिस्कॉर्ड कर रहा हो। इसे अपने पैनल में खोजें, root या अपने सामान्य उपयोगकर्ता के रूप में साइन इन करें, और फिर ऊपर दिए गए चेक चलाएँ। यदि आपने कभी root पासवर्ड सेट नहीं किया है, तो अधिकांश पैनल आपके लिए इसे रीसेट कर सकते हैं।

जहाँ कोई कंसोल मौजूद नहीं है, वहाँ फॉलबैक प्रदाता का rescue mode है। यह एक छोटा रिकवरी सिस्टम बूट करता है और आपकी डिस्क को माउंट करता है, ताकि आप /etc/ssh/sshd_config को एडिट कर सकें या किसी firewall rule को ऑफलाइन डिलीट कर सकें और रीबूट कर सकें।

दो आदतें अगले लॉकआउट को रोकती हैं। जब भी आप sshd या firewall को एडिट करें, तो एक दूसरा SSH सेशन खुला रखें, क्योंकि वह सेशन स्थापित स्टेट पर बना रहता है जबकि आप एक नया सेशन टेस्ट करते हैं। और किसी जोखिम भरे firewall बदलाव से पहले खुद को एक स्वचालित 'undo' दें।

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

पहली लाइन ufw को दस मिनट में खुद को बंद करने के लिए शेड्यूल करती है। अपने नए रूल्स लागू करें, यह साबित करने के लिए कि वे काम करते हैं, एक नया SSH सेशन खोलें, फिर रोलबैक को रद्द करने के लिए दूसरी लाइन चलाएँ। यदि आप खुद को लॉक कर लेते हैं, तो दस मिनट प्रतीक्षा करें और firewall अपने आप बंद हो जाएगा। यह बॉक्स को तब तक अनफिल्टर्ड छोड़ देता है जब तक आप ufw को फिर से इनेबल नहीं करते, इसलिए इसका उपयोग तब करें जब आप कीबोर्ड पर हों, न कि इसे स्थायी व्यवस्था के रूप में रखें।

कार्य करने का क्रम

1. error text को पढ़ें और ध्यान दें कि इसे आने में कितना समय लगा।
2. Refused: console पर जाएँ और listening socket, उसके port, और जिस address पर वह bound है, उसे जाँचने के लिए sudo ss -tlnp का उपयोग करें।
3. Timed out: अपनी machine से address की पुष्टि करें, फिर provider firewall को panel में जाँचें, और उसके बाद host firewall को server पर देखें।
4. यदि इनमें से कोई भी string न हो: तो आपके पास पहले से ही TCP connection है, इसलिए इसे network की समस्या के बजाय authentication या server-load की समस्या मानें।

FAQ

sshd चलने के बावजूद SSH "Connection refused" क्यों कहता है?

क्योंकि कनेक्शन अस्वीकार (refusal) सॉकेट से आता है, न कि सर्विस से, और एक चल रही sshd सर्विस भी आपको अस्वीकार कर सकती है। प्रोवाइडर कंसोल खोलें और sudo ss -tlnp चलाएं। 127.0.0.1:22 पर मौजूद सॉकेट हर रिमोट क्लाइंट को अस्वीकार कर देता है, क्योंकि यह केवल loopback पर बाउंड है। किसी अन्य पोर्ट पर मौजूद सॉकेट उन सभी को अस्वीकार कर देता है जो अभी भी 22 का उपयोग कर रहे हैं। यदि systemd सॉकेट एक्टिवेशन का उपयोग किया जा रहा है, तो पोर्ट ssh.socket से आता है, न कि sshd_config से, इसलिए systemctl is-enabled ssh.socket की भी जांच करें। एक ufw reject नियम भी होस्ट की ओर से अस्वीकृति (refusal) लौटाता है, इसलिए किसी भी निष्कर्ष पर पहुंचने से पहले sudo ufw status verbose पढ़ें।

ufw द्वारा पोर्ट 22 की अनुमति देने के बाद भी SSH टाइम आउट क्यों होता है?

क्योंकि टाइम आउट का मतलब है कि कोई जवाब वापस नहीं आया, और ufw रास्ते में एकमात्र फायरवॉल नहीं है। अधिकांश VPS पैनल इंस्टेंस के सामने एक नेटवर्क फायरवॉल चलाते हैं, और ऑपरेटिंग सिस्टम कभी नहीं देख पाता कि वह फायरवॉल क्या ड्रॉप कर रहा है। कंसोल से, sudo tcpdump -ni any tcp port 22 चलाएं और इसके चलते समय अपने लैपटॉप से कनेक्ट करने का प्रयास करें। यदि कोई पैकेट नहीं पहुंच रहा है, तो इसका मतलब है कि ड्रॉप अपस्ट्रीम (पैनल में) है। यदि पैकेट पहुंच रहे हैं लेकिन कोई जवाब नहीं जा रहा है, तो ड्रॉप लोकल है, यानी ufw या nftables में है।

क्या विफल पिंग का मतलब है कि मेरा VPS डाउन है?

नहीं। कई प्रोवाइडर नेटवर्क एज पर ICMP को फिल्टर करते हैं, इसलिए जो सर्वर सामान्य रूप से ट्रैफिक सर्व कर रहा है, वह आपके द्वारा भेजे गए हर पिंग को अनदेखा कर सकता है। सफल पिंग भी दूसरी दिशा में उतना ही कमजोर है, क्योंकि यह इस बारे में कुछ नहीं बताता कि पोर्ट 22 खुला है या नहीं। अपनी मशीन से nc -vz -w 5 203.0.113.10 22 के साथ, या विंडोज पर PowerShell में Test-NetConnection 203.0.113.10 -Port 22 के साथ पोर्ट का परीक्षण करें।

मैंने SSH पोर्ट बदल दिया और अब कुछ भी कनेक्ट नहीं हो रहा है। क्या गलत हुआ?

दो क्रम इसके कारण बनते हैं। यदि फायरवॉल में नए पोर्ट के लिए कोई नियम नहीं जोड़ा गया है, तो नए पोर्ट पर किए गए प्रयास टाइम आउट हो जाएंगे जबकि पोर्ट 22 अस्वीकार (refuse) करेगा, इसलिए sudo ufw allow 2222/tcp को पोर्ट बदलने से पहले लागू करना चाहिए, बाद में नहीं। यदि बॉक्स SSH के लिए systemd सॉकेट एक्टिवेशन का उपयोग करता है, तो sshd_config में Port 2222 को अनदेखा कर दिया जाता है और systemd पुराने पोर्ट को ही होल्ड रखता है, जिसे आप systemctl is-enabled ssh.socket के साथ सत्यापित कर सकते हैं। प्रोवाइडर कंसोल के माध्यम से रिकवर करें, जो भी लागू हो उसे ठीक करें, और फिर sudo ss -tlnp के नए सॉकेट दिखाने के बाद ssh -p 2222 user@203.0.113.10 के साथ कनेक्ट करें।