SSH: Connection refused বনাম timed out কীভাবে বুঝবেন

SSH-তে "Connection refused" এবং "Connection timed out"-এর অর্থ

SSH connection refused এবং SSH connection timed out—এগুলো পরস্পর বিপরীত ব্যর্থতা। তাই একটির সমাধান কখনোই অন্যটির সমাধান নয়। Refused-এর অর্থ আপনার packet সার্ভারে পৌঁছেছে এবং সার্ভারের kernel উত্তর দিয়েছে, "এখানে কিছুই listen করছে না"। Timed out-এর অর্থ আপনার packet এমন কারও কাছে পৌঁছায়নি যে উত্তর দেবে। তাই client অপেক্ষা করতে করতে শেষ পর্যন্ত থেমে গেছে। Refused সার্ভারের service-সংক্রান্ত সমস্যা। Timed out সার্ভারের আগের 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

সময়ও দ্বিতীয় গুরুত্বপূর্ণ clue। Refused সঙ্গে সঙ্গে ফিরে আসে, সাধারণত একটি round trip সম্পন্ন হতে যত সময় লাগে ততটুকু সময়ে। Timed out দেখাতে অনেক সেকেন্ড লাগে, কারণ client থেমে যাওয়ার আগে বারবার packet retransmit করে। একই condition-এর জন্য macOS Operation timed out দেখায়। Protocolটি আপনার কাছে নতুন হলে, SSH কীভাবে কাজ করে এবং sshd কী করে এই guide-এ ধরা নেওয়া background ব্যাখ্যা করে।

“Connection refused” কেন ভালো লক্ষণ

Refused হলো একটি TCP (transmission control protocol) reset। আপনার client port 22-এ একটি SYN packet পাঠায়। এটি Internet পার হয়ে server-এর network stack-এ পৌঁছায়। এরপর kernel দেখে যে ওই port-এ কোনো socket listening অবস্থায় নেই। তাই kernel একটি RST (reset) packet দিয়ে উত্তর দেয়। আপনার SSH client সেই RST-কে Connection refused বার্তায় রূপান্তর করে।

ফিরে আসা ওই একটি packet অনেক তথ্য নিশ্চিত করে। Address সঠিক। Host চালু আছে এবং routing কাজ করছে। ওই port-এর traffic path-এর কোথাও নীরবে বাতিল হচ্ছে না, কারণ দূরবর্তী প্রান্ত থেকে একটি উত্তর ফিরে এসেছে। তাই বাকি সব সম্ভাব্য কারণ server-এর মধ্যেই রয়েছে।

• sshd চলমান নয়, কারণ এটি start হতে ব্যর্থ হয়েছে অথবা কখনও enabled করা হয়নি।
• sshd অন্য একটি port-এ listening অবস্থায় আছে, সাধারণত hardening পরিবর্তনের পরে।
• sshd একটি নির্দিষ্ট address-এ bind করা আছে, যেমন ListenAddress 127.0.0.1। তাই শুধু server নিজেই এতে পৌঁছাতে পারে।
• একটি firewall traffic drop না করে reject করার জন্য configured আছে। তাই firewall host-এর পক্ষ থেকে RST পাঠায়। ufw-এর reject action এবং reject with tcp reset দিয়ে শেষ হওয়া একটি nftables rule—উভয়ই এভাবে কাজ করে।

আরও একটি অবস্থা দেখতে একই রকম, কিন্তু আসলে তা নয়: আপনি এমন একটি address লিখেছেন, যা অন্য একটি চালু host-এর। সেই host আপনার SYN-এর উত্তর দেয়, port 22-এ কোনো SSH service নেই, এবং ভদ্রভাবে connection প্রত্যাখ্যান করে। ভুল server-এ এক ঘণ্টা ব্যয় করার আগে address নিশ্চিত করুন। Linux-এ listening port আসলে কী জানলে এই section-এর বাকি অংশ দ্রুত বোঝা যায়।

Connection refused ঠিক করার পদ্ধতি

SSH-এর মাধ্যমে এটি ঠিক করা যাবে না, কারণ SSH-ই কাজ করছে না। আপনার provider-এর web console বা serial console খুলে সেখানে sign in করুন। এরপর নিচের command-গুলো ধারাবাহিকভাবে চালান।

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

Ubuntu এবং Debian-এ systemctl status ssh unit-এর নাম ব্যবহার করে। RHEL এবং AlmaLinux-এর মতো তার rebuild-গুলোতে unit হলো sshd। ss -tlnp listening state-এ থাকা প্রতিটি TCP socket এবং সেটির মালিক process দেখায়। এটিই নির্ভরযোগ্য তথ্যের উৎস: কোনো line-এ sshd না থাকলে কিছুই listening করছে না, configuration file-এ যা-ই লেখা থাকুক। sshd -T প্রতিটি Include file merge করার পর কার্যকর configuration দেখায়। /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। তাই কোনো local ssh localhost পুরোপুরি কাজ করলেও সব remote connection প্রত্যাখ্যাত হবে।

কিছুই listening না করলে service start করুন। Start না হলে failure message পরীক্ষা করুন।

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

sshd -t configuration parse করে এবং কোনো ভুল directive থাকলে file ও line number দেখায়, কিন্তু চলমান service-এ কোনো পরিবর্তন করে না। প্রতিটি restart-এর আগে এটি চালান। কারণ configuration প্রত্যাখ্যাত হলে sshd start-এর সময় বন্ধ হয়ে যায় এবং পরবর্তী connection প্রত্যাখ্যাত হয়।

Ubuntu-তে socket activation-এর ফাঁদ

Ubuntu 24.04 OpenSSH-এর জন্য একটি systemd socket unit সরবরাহ করে। সেই unit সক্রিয় থাকলে systemd listening port ধরে রাখে এবং প্রতিটি connection অনুযায়ী sshd চালু করে। তাই sshd_config-এ Port 2222 পরিবর্তন করলে কোনো প্রভাব পড়ে না, এবং server পুরোনো port-এই connection গ্রহণ করতে থাকে। কোনো কিছু সম্পাদনা করার আগে আপনার server কোন mode-এ চলছে তা পরীক্ষা করুন।

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

socket সক্রিয় থাকলে port-টি sshd_config-এ নয়, socket unit-এ নির্ধারণ করুন।

sudo systemctl edit ssh.socket

[Socket]
ListenStream=
ListenStream=2222

ফাঁকা ListenStream= line-টি প্রয়োজনীয়, কারণ systemd-এর list setting আগে থেকে configured মানের সঙ্গে নতুন মান যোগ করে। এটি বাদ দিলে server উভয় port-এই listen করবে। sudo systemctl daemon-reload এবং sudo systemctl restart ssh.socket দিয়ে পরিবর্তনটি প্রয়োগ করুন। এরপর sudo ss -tlnp দিয়ে নিশ্চিত করুন যে নতুন port-টিই systemd ধরে রেখেছে। VPS-এ SSH hardening করা-র এটি একটি স্বাভাবিক ধাপ, এবং এই ধাপেই সবচেয়ে বেশি মানুষ server-এ প্রবেশাধিকার হারায়।

“Connection timed out” কেন বোঝায় যে কোনো উত্তর আসেনি

Timeout মানে নীরবতা। আপনার client একটি SYN পাঠিয়েছে, এক বা দুই মিনিট ধরে কয়েকবার retransmit করেছে, কিন্তু বিনিময়ে একটি packet-ও পায়নি। এখানে server সম্পর্কে কিছুই নিশ্চিত নয়, কারণ server থেকে কোনো packet পাওয়া যায়নি।

একটি DROP rule ঠিক এই নীরবতাই তৈরি করে, এবং packet drop করা ইচ্ছাকৃত। Rejection জানিয়ে দেয় যে host-টি বিদ্যমান। তাই ufw এবং প্রতিটি cloud provider-এর network firewall অনাকাঙ্ক্ষিত packet discard করে এবং কোনো উত্তর পাঠায় না। আপনি যে port-টি open রাখতে চেয়েছিলেন, সেখানে কোনো firewall তার কাজ করায় সাধারণত এই timeout দেখা যায়।

• Address ভুল: DNS record এখনও এমন একটি server-এ নির্দেশ করছে যেটি আপনি পুনর্নির্মাণ করেছেন, অথবা typo-এর কারণে এমন address-এ যাচ্ছে যা কেউ ব্যবহার করে না।
• Host চালু নেই: এটি powered off, অথবা reboot-এর মাঝামাঝি অবস্থায় আছে। Billing-এর কারণে provider suspension বাইরের দিক থেকে একই রকম দেখায়।
• Host firewall port 22-এর packet drop করছে। সাধারণত কোনো allow rule তৈরি হওয়ার আগে ufw enable চালানো হলে এটি ঘটে।
• Instance-এর সামনে থাকা provider firewall packet-টি drop করছে, ফলে operating system packet-টি একেবারেই দেখতে পাচ্ছে না।
• আপনার নিজের network outbound port 22 block করছে। Office এবং hotel connection-এ এটি সাধারণ ঘটনা।

সংযোগের সঠিক দিক থেকে পরীক্ষা চালান

এটি এমন একটি ভুল, যাতে সবচেয়ে বেশি সময় নষ্ট হয়। যে box-এ packet পৌঁছাচ্ছে না, সেই box-এর ভেতর থেকে dropped packet নির্ণয় করা যায় না। command চালানোর জন্য সেখানে login করতে পারলে সমস্যাটিই থাকত না। এই section-এর প্রতিটি command আপনার নিজের 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 ধরা যায়। ssh -G দেখায় ~/.ssh/config পড়ার পর আপনার client যে settings প্রয়োগ করে। তাই hostname, port বা user নীরবে পরিবর্তন করে দেওয়া পুরোনো Host block-ও এটি শনাক্ত করতে পারে। ssh -vvv দেখায় সংযোগের চেষ্টা কতদূর এগিয়েছে। address-এ সংযোগের কথা জানানো শেষ line-এর পর দীর্ঘ বিরতি হলে সেটি timeout। আর remote OpenSSH version দেখানো line-এর অর্থ TCP ইতিমধ্যে সফল হয়েছে এবং প্রকৃত সমস্যা authentication-এ। Windows-এ PowerShell-এর Test-NetConnection 203.0.113.10 -Port 22, nc-এর বিকল্প।

host নয়, port পরীক্ষা করুন। ping ব্যর্থ হলে কিছুই প্রমাণ হয় না, কারণ অনেক provider edge-এ ICMP (internet control message protocol) filter করে। ping সফল হলেও কিছু প্রমাণ হয় না, কারণ এতে port 22 সম্পর্কে কিছু জানা যায় না।

এরপর সেই একটি variable পরিবর্তন করুন, যা কোনো command আপনার হয়ে পরিবর্তন করতে পারে না: আপনার network। ফোনের hotspot থেকে আবার চেষ্টা করুন। hotspot থেকে সংযোগ হলে কিন্তু আপনার desk থেকে না হলে, বাধাটি Internet-এর আপনার পাশের অংশে রয়েছে, অথবা server-এ আপনার office address block করা হয়েছে।

সার্ভার থেকে দেখা যায় না এমন provider firewall

বেশিরভাগ VPS panel-এ একটি network firewall থাকে। একে কখনও security group বা cloud firewall বলা হয়। এটি আপনার instance-এর upstream-এ চলে এবং নিজস্ব rule list সংরক্ষণ করে। ufw status সার্ভারে এটি দেখতে পারে না। তাই “কিন্তু আমি তো port 22 আগেই অনুমোদন করেছি”—এই কথাটি এত সাধারণ। সার্ভারে একটি rule-ও পরিবর্তন করার আগে panel খুলে ওই list পরীক্ষা করুন।

একটি command দিয়েই বিষয়টি নিশ্চিত করা যায়, তবে এর জন্য console access প্রয়োজন। সার্ভারে command-টি চালু রাখুন। এরপর এটি চলার সময় আপনার laptop থেকে সংযোগের চেষ্টা করুন।

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-এর rule ordering, IPv6 এবং নিজের ঠিকানায় ban

ufw-এর rule ordering-এর ভুলে এই সমস্যার অন্য যেকোনো কারণের তুলনায় বেশি ব্যবহারকারী সিস্টেম থেকে বিচ্ছিন্ন হন। sudo ufw enable সঙ্গে সঙ্গে incoming connection-এর জন্য default policy হিসেবে deny প্রয়োগ করে। তাই SSH rule না থাকলে বর্তমান session established state-এর কারণে চালু থাকে, কিন্তু প্রতিটি নতুন connection timeout হয়। আগে allow rule যোগ করুন, তারপর ufw enable করুন।

sudo ufw allow OpenSSH
sudo ufw status verbose

OpenSSH application profile শুধু port 22 কভার করে। SSH 2222-এ সরানোর পরিকল্পনা থাকলে প্রয়োজনীয় rule হলো sudo ufw allow 2222/tcp। port পরিবর্তনের পরে নয়, তার আগে এটি যোগ করুন। বিস্তৃত rule set একটি VPS-এর ufw firewall-এর মৌলিক বিষয়-এ ব্যাখ্যা করা হয়েছে। নিরাপদ ordering নতুন VPS পাওয়ার পর প্রথম দশ মিনিটে করণীয়-এরও অংশ।

IPv6-এর কারণে এমন timeout দেখা দিতে পারে, যার কারণ প্রথমে বোঝা কঠিন। hostname-এ AAAA record থাকলে client প্রথমে IPv6 ব্যবহার করার চেষ্টা করে। তাই server-এ IPv6 rule অনুপস্থিত থাকলে connection ঝুলে থাকে, যদিও সরাসরি IPv4 ব্যবহার করলে connection কাজ করে। দুটি protocol আলাদাভাবে পরীক্ষা করুন।

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

-4 দিয়ে connection হলে কিন্তু -6 দিয়ে না হলে সমস্যাটি server-এর IPv6 rule-এ। ufw-তে IPv6-এর জন্য একই port খোলা-এ এর সমাধানের ধাপ দেখানো হয়েছে।

আপনি নিজের ঠিকানাতেও ban প্রয়োগ করে থাকতে পারেন। fail2ban authentication log monitor করে এবং বারবার ব্যর্থ হওয়া address-এর বিরুদ্ধে firewall rule যোগ করে। তাই ভুল key বা background-এ retry করা কোনো script-এর কারণে পুরো office-এর address block হয়ে যেতে পারে। যে ban packet drop করে, সেটি timeout-এর মতো দেখায়। যে ban packet reject করে, সেটি এর পরিবর্তে 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-এর একটি অংশ।

যে ত্রুটিগুলো connection refused বা timeout নয়

No route to host মানে একটি ICMP unreachable message ফেরত এসেছে। আপনার নিজের মেশিনের ওই network-এর দিকে কোনো route নেই, অথবা পথের কোনো উপাদান administrative rejection জানিয়েছে। iptables-এর REJECT rule এমন response পাঠায়।

Network is unreachable আপনার নিজের মেশিনের response। ওই address family-এর জন্য মেশিনটির কোনো route নেই। IPv4-only connection-এ hostname শুধু IPv6 address-এ resolve হলে সাধারণত এই response দেখা যায়।

kex_exchange_identification: Connection closed by remote host মানে TCP connection স্থাপিত হয়েছে, কিন্তু key exchange শেষ হওয়ার আগে server connection বন্ধ করে দিয়েছে। port খোলা এবং sshd চালু আছে। তাই server load, MaxStartups অথবা connection স্থাপনের সময় কার্যকর হওয়া কোনো ban পরীক্ষা করুন।

Permission denied (publickey) মানে আপনি authentication পর্যায়ে পৌঁছেছেন এবং সেখানে ব্যর্থ হয়েছেন। network এবং firewall ঠিক আছে, তাই এই guide-এর কোনো নির্দেশনা প্রযোজ্য নয়। এর পরিবর্তে SSH-তে Permission denied (publickey) ঠিক করা দেখুন।

কীভাবে আবার প্রবেশ করবেন এবং দ্বিতীয়বার লকআউট এড়াবেন

প্রতিটি নির্ভরযোগ্য VPS host এমন একটি console দেয়, যা guest-এর network-এর ওপর নির্ভর করে না: একটি serial console অথবা browser-based VNC screen। এই guide-এর উভয় branch-এর জন্য console-ই recovery route, কারণ sshd বন্ধ থাকলেও এটি কাজ করে এবং firewall rule সবকিছু discard করলেও এটি সচল থাকে। Panel-এ console খুঁজে নিন, root অথবা আপনার স্বাভাবিক user হিসেবে sign in করুন, তারপর ওপরের check-গুলো চালান। আপনি যদি কখনো root password set না করে থাকেন, বেশিরভাগ panel আপনার জন্য একটি password reset করতে পারে।

যেখানে কোনো console নেই, সেখানে fallback হিসেবে provider-এর rescue mode ব্যবহার করুন। এটি একটি ছোট recovery system boot করে এবং আপনার disk mount করে। ফলে আপনি offline অবস্থায় /etc/ssh/sshd_config edit করতে, অথবা firewall rule delete করে reboot করতে পারবেন।

পরবর্তী lockout এড়াতে দুটি অভ্যাস গড়ে তুলুন। sshd অথবা firewall edit করার সময় একটি দ্বিতীয় SSH session খোলা রাখুন, কারণ নতুন session পরীক্ষা করার সময় established state-এর ওপর থাকা ওই session সচল থাকে। আর ঝুঁকিপূর্ণ firewall পরিবর্তনের আগে automatic undo ব্যবস্থা রাখুন।

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

প্রথম line-টি দশ মিনিট পরে ufw নিজে থেকে বন্ধ হওয়ার সময় নির্ধারণ করে। নতুন rule প্রয়োগ করুন, সেগুলো কাজ করছে কি না নিশ্চিত করতে একটি নতুন SSH session খুলুন, তারপর rollback বাতিল করতে দ্বিতীয় line-টি চালান। এর পরিবর্তে আপনি নিজেকেই lock out করে ফেললে দশ মিনিট অপেক্ষা করুন; firewall নিজে থেকেই নিষ্ক্রিয় হয়ে যাবে। ufw আবার enable না করা পর্যন্ত এটি box-টিকে unfiltered অবস্থায় রাখবে। তাই keyboard-এর সামনে থাকা অবস্থায় এই পদ্ধতি ব্যবহার করুন; permanent arrangement হিসেবে ব্যবহার করবেন না।

কাজ করার ক্রম

1. ত্রুটির লেখা পড়ুন এবং এটি দেখা দিতে কত সময় লেগেছে তা লক্ষ্য করুন।
2. “Refused” হলে: কনসোলে যান এবং listening socket, তার port এবং যে address-এ এটি bind করা আছে, সেগুলোর জন্য sudo ss -tlnp পরীক্ষা করুন।
3. “Timed out” হলে: নিজের machine থেকে address নিশ্চিত করুন। এরপর panel-এ provider firewall পরীক্ষা করুন। তারপর box-এ host firewall পরীক্ষা করুন।
4. এই দুটির কোনোটিই না থাকলে: আপনার কাছে ইতিমধ্যে একটি TCP connection আছে। তাই এটিকে network সমস্যা হিসেবে নয়, authentication বা server load-এর বিষয় হিসেবে বিবেচনা করুন।

FAQ

SSH চলমান থাকা সত্ত্বেও কেন "Connection refused" দেখায়?

কারণ refusal socket থেকে আসে, service থেকে নয়। sshd চলমান থাকলেও এটি সংযোগ প্রত্যাখ্যান করতে পারে। provider console খুলে sudo ss -tlnp চালান। 127.0.0.1:22-এ থাকা socket প্রতিটি remote client-এর সংযোগ প্রত্যাখ্যান করে, কারণ এটি শুধু loopback-এ bind করা। অন্য কোনো port-এ থাকা socket এখনও 22 ব্যবহারকারী সবাইকে প্রত্যাখ্যান করে। systemd socket activation ব্যবহৃত হলে port-এর মান sshd_config থেকে নয়, ssh.socket থেকে আসে। তাই systemctl is-enabled ssh.socket-ও পরীক্ষা করুন। একটি ufw reject rule-ও host-এর পক্ষ থেকে refusal ফেরাতে পারে। তাই কোনো সিদ্ধান্তে পৌঁছানোর আগে sudo ufw status verbose-এর output পড়ুন।

ufw ইতিমধ্যে port 22 অনুমোদন করলেও SSH কেন timeout হয়?

কারণ timeout-এর অর্থ কোনো উত্তর ফেরত আসেনি। ufw network path-এর একমাত্র firewall নয়। অধিকাংশ VPS panel instance-এর সামনে একটি network firewall চালায়। সেই firewall যা drop করে, operating system তা কখনো দেখতে পায় না। console থেকে sudo tcpdump -ni any tcp port 22 চালান এবং এটি চলার সময় laptop থেকে সংযোগের চেষ্টা করুন। কোনো packet না এলে drop upstream-এ, অর্থাৎ panel-এ হচ্ছে। packet এলে কিন্তু কোনো reply বের না হলে drop local-এ, অর্থাৎ ufw বা nftables-এ হচ্ছে।

ping ব্যর্থ হলে কি আমার VPS down বোঝায়?

না। অনেক provider network edge-এ ICMP filter করে। তাই স্বাভাবিকভাবে traffic পরিবেশন করা server-ও আপনার পাঠানো প্রতিটি ping উপেক্ষা করতে পারে। বিপরীত দিক থেকেও সফল ping-এর তথ্য খুব সীমিত। এটি port 22 খোলা কি না, তা জানায় না। নিজের machine থেকে nc -vz -w 5 203.0.113.10 22 দিয়ে port-টি পরীক্ষা করুন। Windows-এ PowerShell ব্যবহার করলে Test-NetConnection 203.0.113.10 -Port 22 চালান।

SSH port পরিবর্তন করার পর এখন কোনো সংযোগ হচ্ছে না। কী ভুল হয়েছে?

দুটি ক্রমগত ভুলের কারণে এটি হতে পারে। firewall-এ নতুন port-এর জন্য rule না থাকলে নতুন port-এ করা প্রচেষ্টা timeout হবে, আর port 22 refusal দেবে। তাই sudo ufw allow 2222/tcp port পরিবর্তনের আগে চালাতে হবে, পরে নয়। server-এ SSH-এর জন্য systemd socket activation ব্যবহৃত হলে sshd_config-এর Port 2222 উপেক্ষিত হয়। systemd তখন পুরোনো port ধরে রাখে। systemctl is-enabled ssh.socket দিয়ে এটি নিশ্চিত করতে পারেন। provider console-এর মাধ্যমে recovery করুন। প্রযোজ্য সমস্যাটি ঠিক করুন। এরপর sudo ss -tlnp নতুন socket দেখালে ssh -p 2222 user@203.0.113.10 দিয়ে সংযোগ করুন।