SSH میں Connection refused اور timed out کا فرق

SSH میں "Connection refused" اور "Connection timed out" کا مطلب

SSH connection refused اور SSH connection timed out ایک دوسرے کے برعکس failures ہیں، اس لیے ایک کے لیے کیا گیا fix دوسرے کے لیے کبھی درست نہیں ہوتا۔ Refused کا مطلب ہے کہ آپ کا packet server تک پہنچا اور server کے kernel نے جواب دیا: "یہاں کچھ بھی listening نہیں کر رہا"۔ Timed out کا مطلب ہے کہ آپ کا packet ایسے کسی فریق تک نہیں پہنچا جو جواب دیتا، اس لیے آپ کے client نے انتظار کیا اور پھر کوشش ترک کر دی۔ Refused server پر service کا مسئلہ ہے۔ Timed out اس کے سامنے network path کا مسئلہ ہے۔

اپنے client کی دکھائی ہوئی exact line پڑھیں، کیونکہ پوری diagnosis اسی wording میں موجود ہوتی ہے۔

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 دوسرا clue ہے۔ Refused فوراً واپس آتا ہے، تقریباً اتنے وقت میں جتنا ایک round trip کو لگتا ہے۔ Timed out کا پیغام ظاہر ہونے سے پہلے کئی seconds گزر جاتے ہیں، کیونکہ client ترک کرنے سے پہلے packet دوبارہ بھیجتا رہتا ہے۔ macOS اسی condition کے لیے 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 نہیں ملتا۔ اس لیے kernel ایک RST (reset) packet کے ذریعے جواب دیتا ہے۔ آپ کا SSH client اس RST کو Connection refused کے الفاظ میں تبدیل کر دیتا ہے۔

واپس آنے والا یہ ایک packet بہت کچھ ثابت کرتا ہے۔ address درست ہے۔ host آن ہے اور routing کام کر رہی ہے۔ راستے میں کوئی چیز اس port کی طرف جانے والے traffic کو خاموشی سے discard نہیں کر رہی، کیونکہ دور موجود host سے جواب واپس آیا ہے۔ اس لیے باقی تمام ممکنہ وجوہات خود server پر موجود ہیں۔

• sshd چل نہیں رہا، کیونکہ یہ start ہونے میں ناکام رہا یا کبھی enabled ہی نہیں کیا گیا۔
• sshd کسی دوسرے port پر listening کر رہا ہے، عموماً hardening change کے بعد۔
• sshd صرف ایک address، مثلاً ListenAddress 127.0.0.1، پر bound ہے، اس لیے صرف server خود اس تک پہنچ سکتا ہے۔
• Firewall کو drop کے بجائے reject کرنے کے لیے set کیا گیا ہے، اس لیے firewall host کی طرف سے RST بھیجتا ہے۔ ufw کا reject action اور reject with tcp reset پر ختم ہونے والا nftables rule، دونوں یہی کرتے ہیں۔

ایک اور صورت بظاہر ایسی ہی لگتی ہے، لیکن حقیقت میں مختلف ہوتی ہے: آپ نے ایسا address درج کیا ہے جو کسی دوسرے live host کا ہے۔ وہ host آپ کے SYN کا جواب دیتا ہے، اس کے port 22 پر SSH نہیں چل رہا، اور وہ آپ کی درخواست مسترد کر دیتا ہے۔ غلط server پر ایک گھنٹہ صرف کرنے سے پہلے address کی تصدیق کریں۔ Linux میں listening port کی اصل نوعیت جاننے سے اس section کا باقی حصہ زیادہ تیزی سے سمجھ آتا ہے۔

Connection refused کو کیسے درست کریں

آپ اسے 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 اور اس کے rebuilds، مثلاً AlmaLinux، میں unit sshd ہے۔ ss -tlnp listening state میں موجود تمام TCP sockets اور انہیں own کرنے والے processes کی فہرست دکھاتا ہے۔ یہی حتمی تصدیق ہے: اگر کسی line میں sshd کا ذکر نہیں ہے تو کوئی بھی چیز listen نہیں کر رہی، خواہ configuration file کچھ بھی کہتی ہو۔ sshd -T تمام Include files merge ہونے کے بعد مؤثر configuration دکھاتا ہے۔ اسی output میں /etc/ssh/sshd_config.d/ میں بھولا ہوا port نظر آتا ہے۔

address column کو غور سے پڑھیں۔ 0.0.0.0:22 کا مطلب ہے کہ server کے تمام IPv4 addresses پر service دستیاب ہے۔ [::]:22 کا مطلب ہے کہ service تمام IPv6 addresses پر دستیاب ہے۔ 127.0.0.1:22 کا مطلب ہے کہ service صرف loopback پر دستیاب ہے۔ اس صورت میں ہر remote connection refused ہو گا، جبکہ مقامی ssh localhost بالکل درست کام کرے گا۔

اگر کوئی چیز listen نہیں کر رہی تو service شروع کریں اور start نہ ہونے کی صورت میں failure پڑھیں۔

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 سے پہلے اسے چلائیں، کیونکہ rejected configuration کی صورت میں sshd start ہوتے ہی exit کر جاتا ہے اور اگلا connection refused ہو جاتا ہے۔

Ubuntu پر socket activation کا مسئلہ

Ubuntu 24.04، OpenSSH کے لیے ایک systemd socket unit جاری کرتا ہے۔ جہاں یہ unit enabled ہو، وہاں systemd listening port کو سنبھالتا ہے اور ہر connection کے لیے sshd شروع کرتا ہے، اس لیے Port 2222 میں sshd_config تبدیل کرنے سے کچھ نہیں بدلتا اور server پرانے port پر جواب دیتا رہتا ہے۔ کسی بھی تبدیلی سے پہلے معلوم کریں کہ آپ کا server کس 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= لائن ضروری ہے، کیونکہ systemd کی list settings پہلے سے configured settings میں شامل ہو جاتی ہیں۔ اسے چھوڑنے پر server دونوں ports پر listening کرتا ہے۔ تبدیلی کو sudo systemctl daemon-reload اور sudo systemctl restart ssh.socket سے apply کریں، پھر sudo ss -tlnp سے تصدیق کریں کہ نیا port hold کیا جا رہا ہے۔ port تبدیل کرنا VPS پر SSH کو harden کرنے کا عام مرحلہ ہے، اور یہی وہ مرحلہ ہے جو اکثر لوگوں کو server سے lock out کر دیتا ہے۔

"Connection timed out" کا مطلب ہے کہ کسی طرف سے جواب نہیں آیا

Timeout خاموشی ہوتی ہے۔ آپ کے client نے SYN بھیجا، اسے ایک یا دو منٹ کے دوران کئی بار دوبارہ بھیجا، لیکن جواب میں ایک بھی packet موصول نہیں ہوا۔ اس سے server کے بارے میں کچھ ثابت نہیں ہوتا، کیونکہ server کی طرف سے کوئی packet موصول ہی نہیں ہوا۔

خاموشی بالکل وہی نتیجہ ہے جو DROP rule پیدا کرتا ہے، اور packet drop کرنا دانستہ عمل ہے۔ Rejection سے scanning کرنے والے کو معلوم ہو جاتا ہے کہ host موجود ہے، اس لیے ufw اور ہر cloud provider کا network firewall ناپسندیدہ packets کو discard کر دیتا ہے اور کوئی جواب واپس نہیں بھیجتا۔ آپ کا timeout عموماً اس port پر firewall کے کام کرنے کی علامت ہوتا ہے جسے آپ کھولنا چاہتے تھے۔

• Address غلط ہے: DNS record اب بھی اس server کی طرف اشارہ کر رہا ہے جسے آپ نے دوبارہ build کیا، یا ایسی typo ہے جو کسی غیر مستعمل address تک پہنچتی ہے۔
• Host فعال نہیں ہے: وہ بند ہے یا reboot کے دوران نامکمل حالت میں ہے۔ Billing کی وجہ سے provider کی suspension بھی باہر سے بالکل ایسی ہی دکھائی دیتی ہے۔
• Host firewall port 22 کے packets drop کر رہا ہے۔ عموماً ایسا اس لیے ہوتا ہے کہ کوئی allow rule بنانے سے پہلے ufw enable چل گیا تھا۔
• Instance کے سامنے موجود provider firewall packet drop کر رہا ہے، اس لیے operating system کو packet بالکل موصول نہیں ہوتا۔
• آپ کا اپنا network outbound port 22 کو block کر رہا ہے۔ Office اور hotel connections میں یہ عام ہے۔

کنکشن کے درست سرے سے ٹیسٹ چلائیں

یہ وہ غلطی ہے جس میں سب سے زیادہ وقت ضائع ہوتا ہے۔ جس سرور تک packets پہنچ ہی نہیں رہے، اسی سرور کے اندر سے 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 وہ address دکھاتا ہے جسے آپ کی machine حقیقت میں استعمال کرے گی۔ اس سے stale DNS record چند seconds میں سامنے آ جاتا ہے۔ ssh -G وہ settings دکھاتا ہے جو آپ کا client ~/.ssh/config پڑھنے کے بعد لاگو کرتا ہے۔ اس سے پرانا Host block سامنے آ جاتا ہے جو خاموشی سے hostname، port یا user تبدیل کر رہا ہو۔ ssh -vvv دکھاتا ہے کہ attempt کہاں تک پہنچا: address سے connect ہونے کے بارے میں آخری line کے بعد طویل وقفہ timeout کی علامت ہے، جبکہ remote OpenSSH version رپورٹ کرنے والی line کا مطلب ہے کہ TCP پہلے ہی کامیاب ہو چکا ہے اور اصل مسئلہ authentication ہے۔ Windows میں PowerShell کے اندر Test-NetConnection 203.0.113.10 -Port 22، nc کی جگہ استعمال ہوتا ہے۔

Host نہیں، port کو test کریں۔ ناکام ping سے کچھ ثابت نہیں ہوتا، کیونکہ بہت سے providers edge پر ICMP (internet control message protocol) filter کرتے ہیں۔ کامیاب ping بھی کچھ ثابت نہیں کرتا، کیونکہ اس سے port 22 کے بارے میں کچھ معلوم نہیں ہوتا۔

اس کے بعد وہ واحد variable تبدیل کریں جسے کوئی command آپ کی طرف سے تبدیل نہیں کر سکتی: اپنا network۔ Phone hotspot سے دوبارہ کوشش کریں۔ اگر hotspot سے connection ہو جاتا ہے اور آپ کے desk کے network سے نہیں، تو block internet کے آپ کے side پر ہے، یا server پر آپ کا office address ban کر دیا گیا ہے۔

سرور سے نظر نہ آنے والا 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 مقامی ہے اور اس کی وجہ ufw یا nftables ہے۔ یہ واحد test timeout کی ممکنہ وجہ کو دو حصوں میں تقسیم کر دیتا ہے۔ اسی لیے console تک رسائی حاصل کرنا مفید ہے۔

ufw کی ترتیب، IPv6، اور خود کو لگائی گئی پابندی

ufw کی ترتیب میں غلطی یہاں کی ہر دوسری وجہ سے زیادہ لوگوں کو سرور سے باہر کر دیتی ہے۔ sudo ufw enable فوراً آنے والی connections کے لیے default policy کو deny پر set کرتا ہے۔ اس لیے SSH rule موجود نہ ہو تو آپ کا موجودہ session established state کی وجہ سے چلتا رہتا ہے، جبکہ ہر نئی connection timeout ہو جاتی ہے۔ پہلے allow کریں، پھر 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 کی بنیادی باتیں میں ہے، جبکہ درست ترتیب نئے VPS کے پہلے دس منٹ میں کیا کرنا ہے کا حصہ ہے۔

IPv6 ایسی timeout پیدا کرتا ہے جو غیر معمولی محسوس ہوتی ہے۔ اگر hostname کے ساتھ AAAA record موجود ہو تو client پہلے IPv6 آزما لیتا ہے۔ اس لیے IPv6 rules کے بغیر server رک جاتا ہے، جبکہ سادہ IPv4 کوشش کامیاب ہو جاتی ہے۔ دونوں کو دستی طور پر الگ الگ جانچیں۔

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

اگر -4 connect ہو جاتا ہے لیکن -6 نہیں ہوتا تو مسئلہ server کے IPv6 rules میں ہے۔ ufw میں IPv6 کے لیے وہی port کھولنے کی ہدایات اس عمل کی وضاحت کرتی ہیں۔

ممکن ہے آپ نے خود کو بھی ban کر دیا ہو۔ fail2ban authentication log کو monitor کرتا ہے اور بار بار ناکام ہونے والے addresses کے خلاف firewall rule شامل کرتا ہے۔ اس لیے غلط key یا پس منظر میں retry کرنے والی script پورے office address کو lock out کر سکتی ہے۔ ایسی ban جو packets کو drop کرتی ہے، timeout جیسی دکھائی دیتی ہے۔ جو ban packets کو 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 رد ہو اور نہ timeout ہو

No route to host کا مطلب ہے کہ ICMP unreachable پیغام واپس آیا ہے۔ یا تو آپ کی اپنی مشین کے پاس اس network تک جانے کا کوئی route نہیں، یا راستے میں موجود کسی چیز نے administrative rejection کے ساتھ جواب دیا ہے۔ iptables کی REJECT rule یہی جواب بھیجتی ہے۔

Network is unreachable آپ کی اپنی مشین کی طرف سے جاری کردہ پیغام ہے۔ اس 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، یا connection قائم کرتے وقت لاگو ہونے والی کسی ban کو دیکھیں۔

Permission denied (publickey) کا مطلب ہے کہ آپ authentication مرحلے تک پہنچے، لیکن وہاں ناکام ہوئے۔ network اور firewall دونوں درست ہیں، اس لیے اس guide میں موجود کوئی چیز لاگو نہیں ہوتی۔ اس کے بجائے SSH میں Permission denied (publickey) درست کرنے پر جائیں۔

دوبارہ رسائی کیسے حاصل کریں، اور دوسری بار لاک آؤٹ سے کیسے بچیں

ہر سنجیدہ VPS میزبان آپ کو ایسا console فراہم کرتا ہے جو guest کے network پر منحصر نہیں ہوتا: serial console یا browser-based VNC screen۔ یہ console اس guide کی دونوں شاخوں کے لیے recovery route ہے، کیونکہ sshd بند ہونے پر بھی کام کرتا ہے اور firewall rule کی وجہ سے تمام traffic رد ہونے پر بھی۔ اسے panel میں تلاش کریں، root یا اپنے عام user کے طور پر sign in کریں، پھر اوپر دیے گئے checks چلائیں۔ اگر آپ نے کبھی root password مقرر نہیں کیا تو اکثر panels آپ کے لیے نیا password reset کر سکتے ہیں۔

جہاں console موجود نہ ہو، وہاں provider کا rescue mode متبادل ہے۔ یہ ایک چھوٹا recovery system boot کرتا ہے اور آپ کی disk mount کرتا ہے، تاکہ آپ /etc/ssh/sshd_config میں ترمیم کر سکیں یا offline حالت میں firewall rule حذف کرکے reboot کر سکیں۔

دو عادتیں اگلے lockout سے بچاتی ہیں۔ جب بھی آپ sshd یا firewall میں ترمیم کریں تو دوسری SSH session کھلی رکھیں، کیونکہ نئی session کو test کرتے وقت وہ session established state کی وجہ سے برقرار رہتی ہے۔ اس کے علاوہ، خطرناک firewall change سے پہلے automatic undo کا انتظام کریں۔

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

پہلی line دس منٹ بعد ufw کو خود بند کرنے کا schedule بناتی ہے۔ اپنے نئے rules apply کریں، ان کے کام کرنے کی تصدیق کے لیے نئی SSH session کھولیں، پھر rollback منسوخ کرنے کے لیے دوسری line چلائیں۔ اگر آپ خود کو lock out کر دیں تو دس منٹ انتظار کریں؛ firewall خود بخود غیر فعال ہو جائے گا۔ اس کے بعد box پر network filtering نہیں رہے گی، جب تک آپ ufw دوبارہ enable نہ کریں۔ اس لیے اسے keyboard کے سامنے موجود ہوتے وقت استعمال کریں، مستقل configuration کے طور پر نہیں۔

کام کرنے کی ترتیب

1. خرابی کا متن پڑھیں اور نوٹ کریں کہ یہ ظاہر ہونے میں کتنا وقت لیتی ہے۔
2. Refused: console پر جائیں اور sudo ss -tlnp میں listening socket، اس کا port، اور وہ address دیکھیں جس پر یہ bind ہے۔
3. Timed out: اپنی مشین سے address کی تصدیق کریں، پھر panel میں provider firewall چیک کریں، اور اس کے بعد host پر firewall چیک کریں۔
4. ان دونوں میں سے کوئی string موجود نہ ہو: TCP connection پہلے ہی قائم ہے، اس لیے اسے authentication یا server load کا مسئلہ سمجھیں، network کا نہیں۔

FAQ

SSH، sshd کے چلنے کے باوجود "Connection refused" کیوں کہتا ہے؟

کیونکہ refusal سروس سے نہیں بلکہ socket سے آتا ہے، اور چلتا ہوا sshd بھی آپ کی درخواست مسترد کر سکتا ہے۔ provider console کھولیں اور sudo ss -tlnp چلائیں۔ 127.0.0.1:22 پر موجود socket ہر remote client کو مسترد کرتا ہے، کیونکہ یہ صرف loopback سے bind ہے۔ کسی دوسرے port پر موجود socket ان تمام clients کو مسترد کرتا ہے جو اب بھی 22 استعمال کر رہے ہیں۔ اگر systemd socket activation استعمال ہو رہی ہو تو port ssh.socket سے آتا ہے، sshd_config سے نہیں؛ اس لیے systemctl is-enabled ssh.socket بھی چیک کریں۔ ufw کا reject rule بھی host کی طرف سے refusal واپس کر سکتا ہے، اس لیے کوئی نتیجہ اخذ کرنے سے پہلے sudo ufw status verbose پڑھیں۔

ufw میں port 22 کی اجازت ہونے کے باوجود SSH timeout کیوں ہو جاتا ہے؟

کیونکہ timeout کا مطلب ہے کہ کوئی جواب واپس نہیں آیا، اور راستے میں صرف ufw واحد firewall نہیں ہے۔ زیادہ تر VPS panels instance کے سامنے network firewall چلاتے ہیں، اور operating system کو وہ traffic نظر ہی نہیں آتا جسے یہ firewall drop کر دیتا ہے۔ console سے sudo tcpdump -ni any tcp port 22 چلائیں اور اسے چلتے ہوئے اپنے laptop سے connect کرنے کی کوشش کریں۔ کوئی packet موصول نہ ہونے کا مطلب ہے کہ drop upstream، یعنی panel میں ہو رہا ہے۔ packets موصول ہوں لیکن کوئی reply باہر نہ جائے تو drop local ہے، یعنی ufw یا nftables میں۔

کیا failed ping کا مطلب ہے کہ میرا VPS down ہے؟

نہیں۔ بہت سے providers network edge پر ICMP filter کرتے ہیں، اس لیے معمول کے مطابق traffic serve کرنے والا server آپ کے بھیجے ہوئے ہر ping کو نظرانداز کر سکتا ہے۔ کامیاب ping بھی اسی طرح محدود معلومات دیتا ہے، کیونکہ اس سے یہ معلوم نہیں ہوتا کہ port 22 کھلا ہے یا نہیں۔ اپنے machine سے nc -vz -w 5 203.0.113.10 22 کے ذریعے port کو خود test کریں، یا Windows پر PowerShell میں Test-NetConnection 203.0.113.10 -Port 22 چلائیں۔

میں نے SSH port تبدیل کیا اور اب کوئی connection نہیں بن رہا۔ کیا خرابی ہوئی؟

اس کی دو ممکنہ وجوہات ہیں۔ اگر firewall میں نئے port کے لیے rule شامل نہیں کیا گیا تو نئے port پر کی جانے والی کوششیں timeout ہوں گی، جبکہ port 22 refusal دے گا؛ اس لیے sudo ufw allow 2222/tcp کو port تبدیل کرنے سے پہلے چلانا چاہیے، بعد میں نہیں۔ اگر box SSH کے لیے systemd socket activation استعمال کرتا ہے تو sshd_config میں Port 2222 نظرانداز ہو جاتا ہے، اور systemd پرانا port برقرار رکھتا ہے؛ اس کی تصدیق systemctl is-enabled ssh.socket سے کی جا سکتی ہے۔ provider console کے ذریعے بحال کریں، جو وجہ لاگو ہو اسے درست کریں، پھر sudo ss -tlnp میں نیا socket دکھائی دینے کے بعد ssh -p 2222 user@203.0.113.10 کے ذریعے connect کریں۔