توسط تفاوت خطای Connection refused و Connection timed out در
خطای Connection refused یعنی سرویس sshd در سرور پاسخ داده اما رد کرده است، در حالی که Connection timed out نشان میدهد بستههای شما در مسیر شبکه گم شدهاند.
معنای "Connection refused" و "Connection timed out" در SSH
خطای Connection refused و Connection timed out در SSH دو شکست کاملاً متفاوت هستند، بنابراین راهحل یکی هرگز برای دیگری کارساز نیست. خطای Refused به این معناست که بستهٔ ارسالی شما به سرور رسیده و هستهٔ سیستمعامل سرور پاسخ داده است که «هیچ سرویسی در اینجا گوش نمیدهد». خطای Timed out به این معناست که بستهٔ شما به هیچ مقصدی که پاسخگو باشد نرسیده است، بنابراین کلاینت شما منتظر مانده و در نهایت تسلیم شده است. خطای Refused یک مشکل سرویس در سمت سرور است. خطای Timed out یک مشکل در مسیر شبکه پیش از رسیدن به سرور است.
دقیقاً همان خطی را که کلاینت شما چاپ کرده است بخوانید، زیرا متن آن تمام تشخیص مشکل است.
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زمانبندی، دومین سرنخ است. خطای Refused بلافاصله و تقریباً در مدت زمان یک رفتوبرگشت (round trip) شبکه بازمیگردد. خطای Timed out برای چندین ثانیه متوقف میماند و سپس پیام را چاپ میکند، زیرا کلاینت پیش از تسلیم شدن، بارها تلاش به ارسال مجدد (retransmit) میکند. سیستمعامل macOS برای همین وضعیت عبارت Operation timed out را چاپ میکند. اگر با خود پروتکل آشنا نیستید، نحوه عملکرد SSH و وظایف sshd پیشزمینهای است که این راهنما فرض میکند آن را میدانید.
چرا خطای "Connection refused" خبر خوبی است
خطای Refused در واقع یک ریست در پروتکل TCP (Transmission Control Protocol) است. کلاینت شما یک بسته SYN به پورت 22 ارسال میکند. این بسته از اینترنت عبور کرده و به پشته شبکه سرور میرسد، اما هسته سیستمعامل (kernel) هیچ سوکتی را در حال گوش دادن (listening) روی آن پورت پیدا نمیکند؛ بنابراین با یک بسته RST (reset) پاسخ میدهد. کلاینت SSH شما این RST را به عبارت Connection refused تبدیل میکند.
همین یک بسته بازگشتی، نکات زیادی را اثبات میکند. آدرس مقصد درست است. میزبان روشن است و مسیریابی بهدرستی انجام میشود. هیچچیز در مسیر، ترافیک آن پورت را بهصورت بیصدا دور نمیریزد (discard)، زیرا پاسخی از سمت مقصد دریافت شده است. بنابراین، تمام مظنونین باقیمانده روی خودِ سرور قرار دارند:
- سرویس
sshdدر حال اجرا نیست، زیرا در شروع کار شکست خورده یا هرگز فعال (enable) نشده است. - سرویس
sshdروی پورت دیگری گوش میدهد که معمولاً پس از تغییرات امنیتی (hardening) رخ میدهد. - سرویس
sshdفقط به یک آدرس خاص مانندListenAddress 127.0.0.1متصل (bind) شده است، بنابراین فقط خودِ سرور میتواند به آن دسترسی داشته باشد. - یک فایروال طوری تنظیم شده که بهجای دور ریختن (drop) بستهها، آنها را رد (reject) کند؛ در نتیجه فایروال از طرف میزبان، بسته RST را ارسال میکند. دستور ufw با اکشن
rejectو قوانین nftables که بهreject with tcp resetختم میشوند، هر دو این کار را انجام میدهند.
یک مورد دیگر نیز وجود دارد که شبیه به موارد بالاست اما متفاوت است: شما آدرسی را وارد کردهاید که متعلق به یک میزبان فعال دیگر است. آن میزبان به SYN شما پاسخ میدهد، اما چون سرویس SSH روی پورت 22 ندارد، مؤدبانه درخواست شما را رد میکند. پیش از آنکه یک ساعت وقت خود را روی سرور اشتباه هدر دهید، آدرس را تأیید کنید. دانستن اینکه یک پورت در حال گوش دادن در لینوکس واقعاً چیست، باعث میشود ادامه این بخش را سریعتر درک کنید.
نحوه رفع خطای Connection refused
شما نمیتوانید این مشکل را از طریق SSH حل کنید، زیرا خودِ SSH دچار اختلال شده است. کنسول وب یا کنسول سریال ارائهدهنده سرور خود را باز کنید، وارد شوید و سپس دستورات زیر را به ترتیب اجرا کنید.
systemctl status ssh
sudo ss -tlnp
sudo sshd -T | grep -Ei '^(port|listenaddress|addressfamily)'systemctl status ssh نام واحد (unit) در توزیعهای Ubuntu و Debian است. در RHEL و توزیعهای مبتنی بر آن مانند AlmaLinux، این واحد sshd نام دارد. دستور ss -tlnp تمام سوکتهای TCP در وضعیت listening را به همراه پردازشی که مالک آنهاست فهرست میکند و منبع اصلی برای بررسی وضعیت است: اگر هیچ خطی به sshd اشاره نکند، یعنی هیچ سرویسی در حال گوش دادن نیست، فارغ از اینکه فایل پیکربندی چه چیزی را نشان میدهد. دستور sshd -T پیکربندی نهایی و اعمالشده را پس از ادغام تمام فایلهای Include چاپ میکند؛ این همان جایی است که یک پورت فراموششده در /etc/ssh/sshd_config.d/ خود را نشان میدهد.
ستون آدرس را با دقت بخوانید. عبارت 0.0.0.0:22 به معنای تمام آدرسهای IPv4 روی سرور است. عبارت [::]:22 به معنای تمام آدرسهای IPv6 است. عبارت 127.0.0.1:22 به معنای محدود بودن به loopback است، بنابراین هر اتصال از راه دور به آن رد میشود در حالی که یک دستور ssh localhost محلی به درستی کار میکند.
اگر هیچ سرویسی در حال گوش دادن نیست، آن را استارت کنید و در صورت عدم اجرا، پیام خطا را بخوانید.
sudo sshd -t
sudo systemctl enable --now ssh
sudo journalctl -u ssh -n 50 --no-pagerدستور sshd -t پیکربندی را تحلیل کرده و نام فایل و شماره خطِ دستورات نادرست را بدون ایجاد تغییر در سرویس در حال اجرا، چاپ میکند. پیش از هر بار راهاندازی مجدد (restart)، این دستور را اجرا کنید، زیرا پیکربندیِ ردشده باعث میشود sshd در هنگام شروع متوقف شود و اتصال بعدی شما رد (refuse) شود.
دام تلهٔ فعالسازی سوکت در Ubuntu
نسخه Ubuntu 24.04 بهصورت پیشفرض یک unit سوکت systemd برای OpenSSH ارائه میدهد. در جایی که این unit فعال باشد، systemd پورت شنود را در اختیار میگیرد و sshd را به ازای هر اتصال اجرا میکند؛ بنابراین تغییر Port 2222 در sshd_config هیچ تأثیری ندارد و سرور همچنان روی پورت قدیمی پاسخ میدهد. پیش از هرگونه ویرایش، بررسی کنید که سیستم شما در کدام حالت قرار دارد.
systemctl is-enabled ssh.socket
systemctl status ssh.socketاگر سوکت فعال است، پورت را بهجای sshd_config در فایل unit سوکت تنظیم کنید.
sudo systemctl edit ssh.socket[Socket]
ListenStream=
ListenStream=2222خط خالی ListenStream= الزامی است، زیرا تنظیمات لیستی در systemd به مقادیر قبلی اضافه میشوند. اگر این خط را حذف کنید، سرور روی هر دو پورت گوش میدهد. تغییرات را با sudo systemctl daemon-reload و sudo systemctl restart ssh.socket اعمال کنید، سپس با sudo ss -tlnp تأیید کنید که پورت جدید توسط سیستم در حال استفاده است. تغییر پورت یک گام معمول در ایمنسازی SSH روی VPS است و همان مرحلهای است که بیشترین آمار قفل شدن کاربران از سیستم را به همراه دارد.
چرا خطای "Connection timed out" به معنای عدم دریافت پاسخ است
وقتی با خطای timeout مواجه میشوید، یعنی سکوت برقرار است. کلاینت شما یک بسته SYN ارسال کرده، آن را طی یک یا دو دقیقه چندین بار بازنشر (retransmit) کرده، اما حتی یک بسته هم در پاسخ دریافت نکرده است. در این حالت هیچ چیزی درباره وضعیت سرور اثبات نمیشود، زیرا هیچ پاسخی از سمت سرور شنیده نشده است.
سکوت دقیقاً همان چیزی است که یک قانون DROP ایجاد میکند و دور انداختن (drop) بستهها یک اقدام عمدی است. ریجکت کردن (rejection) به هر کسی که در حال اسکن شبکه باشد میگوید که این میزبان وجود دارد، بنابراین ufw و فایروالهای شبکه در تمامی سرویسدهندگان ابری، بستههای ناخواسته را دور میاندازند و هیچ پاسخی ارسال نمیکنند. خطای timeout شما معمولاً به این معناست که یک فایروال در حال انجام وظیفه خود روی پورتی است که شما میخواستید باز باشد.
- آدرس اشتباه است: یک رکورد DNS که هنوز به سروری اشاره میکند که آن را بازسازی کردهاید، یا یک غلط تایپی که باعث میشود درخواست به آدرسی ارسال شود که هیچکس از آن استفاده نمیکند.
- میزبان بالا نیست: خاموش است یا در میانه فرآیند reboot قرار دارد. تعلیق سرویس توسط ارائهدهنده به دلیل مسائل مالی نیز از بیرون دقیقاً به همین شکل دیده میشود.
- فایروال میزبان پورت 22 را drop میکند، که معمولاً به این دلیل است که
ufw enableپیش از ایجاد هرگونه قانون allow اجرا شده است. - فایروال ارائهدهنده که در مقابل instance قرار دارد، بسته را drop میکند و سیستمعامل اصلاً بسته را دریافت نمیکند.
- شبکه خودتان پورت خروجی 22 را مسدود کرده است، که در اتصالات اداری و هتلها رایج است.
اجرای تست از سمت درست اتصال
این اشتباهی است که بیشترین زمان را هدر میدهد. شما نمیتوانید بستههای گمشده را از داخل جعبهای که بستهها به آن نمیرسند عیبیابی کنید. اگر میتوانستید برای اجرای دستور وارد سیستم شوید، اصلاً مشکلی نداشتید. هر دستوری در این بخش باید روی دستگاه خودتان اجرا شود.
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 نشان میدهد که تلاش اتصال تا کجا پیش رفته است: آخرین خطی که درباره اتصال به آدرس است و به دنبال آن وقفهای طولانی میآید، نشاندهنده timeout است؛ در حالی که خطی که نسخه OpenSSH راه دور را گزارش میکند، به این معنی است که TCP قبلاً با موفقیت انجام شده و مشکل واقعی شما احراز هویت است. در ویندوز، دستور Test-NetConnection 203.0.113.10 -Port 22 در PowerShell جایگزین nc میشود.
پورت را تست کنید، نه میزبان را. یک ping ناموفق چیزی را ثابت نمیکند، زیرا بسیاری از ارائهدهندگان، پروتکل ICMP (پروتکل پیام کنترل اینترنت) را در لبه شبکه فیلتر میکنند. یک ping موفق نیز چیزی را ثابت نمیکند، زیرا هیچ اطلاعاتی درباره پورت 22 نمیدهد.
سپس تنها متغیری را تغییر دهید که هیچ دستوری نمیتواند برای شما تغییر دهد: شبکه خودتان. از طریق هاتاسپات گوشی دوباره تلاش کنید. اگر هاتاسپات متصل شد و شبکه میز کار شما متصل نشد، مسدودسازی در سمت شما از اینترنت است یا آدرس دفتر شما در سرور مسدود شده است.
فایروال ارائهدهنده که از داخل سرور قابل مشاهده نیست
بیشتر پنلهای VPS یک فایروال شبکه ارائه میدهند که گاهی به آن security group یا فایروال ابری گفته میشود. این فایروال در بالادست instance شما اجرا میشود و لیست قوانین خاص خود را دارد. ufw status روی سرور نمیتواند آن را ببیند؛ به همین دلیل است که جمله «اما من قبلاً پورت 22 را باز کردهام» بسیار رایج است. پیش از آنکه حتی یک قانون را در داخل سرور بازنویسی کنید، پنل را باز کرده و آن لیست را مطالعه کنید.
یک دستور این مسئله را حل میکند و برای اجرای آن به دسترسی کنسول نیاز دارید. آن را روی سرور اجرا کنید و سپس در حین اجرا، سعی کنید از لپتاپ خود متصل شوید.
sudo tcpdump -ni any tcp port 22اگر در حین تلاش کلاینت شما برای اتصال، هیچ چیزی ظاهر نشد، بستهها پیش از رسیدن به سیستمعامل دور ریخته میشوند؛ بنابراین نقص از فایروال ارائهدهنده یا مسیر منتهی به میزبان است. اگر بستههای SYN میرسند اما پاسخی ارسال نمیشود، حذف بسته در سطح محلی رخ میدهد و مربوط به ufw یا nftables است. این تست واحد، شاخه timeout را به دو نیم تقسیم میکند و به همین دلیل ارزش رفتن به کنسول را دارد.
ترتیب قوانین ufw، پروتکل IPv6 و مسدودسازی خودخواسته
اشتباه در ترتیب قوانین ufw بیش از هر مورد دیگری در اینجا باعث قطع دسترسی کاربران میشود. sudo ufw enable بلافاصله سیاست پیشفرض deny incoming را اعمال میکند؛ بنابراین اگر قانون SSH را از قبل تنظیم نکرده باشید، نشست فعلی شما به دلیل وضعیت established برقرار میماند، اما تمام اتصالات جدید با timeout مواجه میشوند. ابتدا دسترسی را مجاز کنید و سپس فایروال را فعال نمایید.
sudo ufw allow OpenSSH
sudo ufw status verboseپروفایل برنامه OpenSSH فقط پورت 22 را پوشش میدهد. اگر قصد دارید SSH را به پورت 2222 منتقل کنید، قانونی که نیاز دارید sudo ufw allow 2222/tcp است که باید پیش از تغییر پورت و نه پس از آن اضافه شود. مجموعه قوانین گستردهتر در اصول اولیه فایروال ufw برای VPS پوشش داده شده و ترتیب ایمن در اقدامات ده دقیقه اول در یک VPS جدید آمده است.
پروتکل IPv6 باعث ایجاد timeout میشود که رفتاری غیرعادی به نظر میرسد. اگر نام میزبان دارای رکورد AAAA باشد، کلاینت شما ابتدا IPv6 را امتحان میکند؛ بنابراین اگر قوانین IPv6 سرور ناقص باشد، اتصال معلق میماند در حالی که تلاش از طریق IPv4 به درستی کار میکند. این دو را بهصورت دستی از هم تفکیک کنید.
ssh -4 user@vps.example.com
ssh -6 user@vps.example.comاگر -4 متصل میشود اما -6 خیر، راهحل در اصلاح قوانین IPv6 سرور است و باز کردن همان پورت برای IPv6 در ufw مراحل آن را توضیح میدهد.
ممکن است خودتان را نیز مسدود کرده باشید. fail2ban لاگهای احراز هویت را مانیتور میکند و علیه آدرسهایی که مکرراً شکست میخورند، یک قانون فایروال اعمال میکند؛ بنابراین یک کلید اشتباه یا اسکریپتی که در پسزمینه تلاش مجدد میکند، میتواند آدرس کل یک دفتر را مسدود کند. مسدودسازی از نوع drop مانند timeout به نظر میرسد. مسدودسازی از نوع reject نیز خطای No route to host را برمیگرداند. از طریق کنسول:
sudo fail2ban-client status sshd
sudo fail2ban-client set sshd unbanip 198.51.100.24افزودن آدرس خود به ignoreip بخشی از راهاندازی صحیح fail2ban در Ubuntu 24.04 است.
خطاهایی که نه رد شدهاند و نه با اتمام زمان (timeout) مواجه شدهاند
No route to host به این معنی است که یک پیام ICMP unreachable بازگشته است. یا دستگاه شما مسیری به آن شبکه ندارد، یا چیزی در طول مسیر با یک ردِ اداری (administrative rejection) پاسخ داده است؛ این همان چیزی است که یک قانون REJECT در iptables ارسال میکند.
Network is unreachable توسط دستگاه خود شما اعلام میشود. این دستگاه اصلاً مسیری برای آن خانوادهٔ آدرس ندارد و معمولاً زمانی رخ میدهد که یک نام دامنه فقط به یک آدرس IPv6 ترجمه شود، در حالی که اتصال شما فقط IPv4 است.
kex_exchange_identification: Connection closed by remote host به این معنی است که اتصال TCP برقرار شده، اما سرور پیش از پایان تبادل کلید، ارتباط را قطع کرده است. پورت باز است و sshd فعال است؛ بنابراین بار کاری سرور، MaxStartups یا بن شدن (ban) در حین برقراری اتصال را بررسی کنید.
Permission denied (publickey) به این معنی است که شما به مرحلهٔ احراز هویت رسیدهاید و در آنجا شکست خوردهاید. شبکه و فایروال مشکلی ندارند، بنابراین هیچکدام از موارد این راهنما در اینجا صدق نمیکند. به جای آن به رفع خطای Permission denied (publickey) در SSH مراجعه کنید.
نحوه دسترسی مجدد و جلوگیری از قفل شدن دوباره
هر میزبان VPS معتبر، کنسولی ارائه میدهد که به شبکه سیستمعامل مهمان وابسته نیست: یک کنسول سریال یا یک صفحه VNC مبتنی بر مرورگر. این کنسول مسیر بازیابی برای هر دو بخش این راهنما است، زیرا زمانی که sshd متوقف شده یا یک قانون فایروال همه بستهها را دور میریزد، همچنان کار میکند. آن را در پنل کاربری پیدا کنید، با کاربر root یا کاربر عادی خود وارد شوید و سپس بررسیهای ذکر شده در بالا را انجام دهید. اگر هرگز رمز عبور root را تنظیم نکردهاید، اکثر پنلها میتوانند آن را برای شما بازنشانی کنند.
در مواردی که کنسولی وجود ندارد، راهکار جایگزین، حالت rescue mode ارائهدهنده است. این حالت یک سیستم بازیابی کوچک را بوت کرده و دیسک شما را mount میکند، بنابراین میتوانید فایل /etc/ssh/sshd_config را ویرایش کنید یا یک قانون فایروال را به صورت آفلاین حذف کرده و سیستم را reboot کنید.
دو عادت از قفل شدن مجدد جلوگیری میکنند. همیشه هنگام ویرایش sshd یا فایروال، یک نشست SSH دوم باز نگه دارید، زیرا آن نشست به دلیل وضعیت برقرار شده (established state) باقی میماند و به شما اجازه میدهد نشست جدید را تست کنید. همچنین، پیش از اعمال تغییرات پرخطر در فایروال، یک دستور بازگشت خودکار (undo) برای خود تنظیم کنید.
sudo systemd-run --unit=ufw-rollback --on-active=10min /usr/sbin/ufw disable
sudo systemctl stop ufw-rollback.timerخط اول به ufw دستور میدهد که پس از 10 دقیقه خود را غیرفعال کند. قوانین جدید خود را اعمال کنید، یک نشست SSH جدید باز کنید تا مطمئن شوید قوانین کار میکنند، سپس خط دوم را اجرا کنید تا دستور بازگشت لغو شود. اگر به جای آن، خود را از سیستم قفل کردید، 10 دقیقه صبر کنید تا فایروال به طور خودکار غیرفعال شود. این کار باعث میشود سرور تا زمانی که دوباره ufw را فعال کنید بدون فیلتر باقی بماند، بنابراین از این روش فقط زمانی که پشت کیبورد هستید استفاده کنید و نه به عنوان یک تنظیم دائمی.
ترتیب انجام کار
- متن خطا را بخوانید و توجه کنید که چقدر طول کشید تا ظاهر شود.
- خطای Refused: به کنسول بروید و
sudo ss -tlnpرا برای یافتن سوکت در حال گوش دادن، پورت آن و آدرسی که به آن متصل است، بررسی کنید. - خطای Timed out: از دستگاه خود آدرس را تأیید کنید، سپس فایروال ارائهدهنده در پنل و بعد فایروال میزبان روی سرور را بررسی کنید.
- هیچکدام از این موارد: شما هماکنون یک اتصال TCP دارید، بنابراین آن را به عنوان یک مسئله احراز هویت یا بار کاری سرور در نظر بگیرید، نه یک مسئله شبکه.
FAQ
چرا با وجود اجرای sshd، پیام "Connection refused" در SSH دریافت میشود؟
زیرا رد اتصال (refusal) از سمت سوکت صادر میشود، نه از سمت سرویس؛ و یک sshd در حال اجرا همچنان میتواند اتصال شما را رد کند. کنسول ارائهدهنده را باز کرده و دستور sudo ss -tlnp را اجرا کنید. سوکتی که روی 127.0.0.1:22 قرار دارد، تمام کلاینتهای راه دور را رد میکند، زیرا فقط به loopback متصل (bind) شده است. سوکتی که روی پورت دیگری است، همچنان اتصالات پورت 22 را رد میکند. اگر از قابلیت systemd socket activation استفاده میکنید، پورت از ssh.socket تعیین میشود و نه از sshd_config، بنابراین systemctl is-enabled ssh.socket را نیز بررسی کنید. یک قانون reject در ufw نیز میتواند از طرف میزبان پاسخ رد (refusal) ارسال کند، پس پیش از هر نتیجهگیری، sudo ufw status verbose را مطالعه کنید.
چرا با وجود باز بودن پورت 22 در ufw، اتصال SSH دچار timeout میشود؟
زیرا timeout به این معناست که هیچ پاسخی دریافت نشده است و ufw تنها فایروال موجود در مسیر نیست. اکثر پنلهای VPS یک فایروال شبکه در مقابل instance اجرا میکنند و سیستمعامل هرگز بستههایی که توسط آن فایروال drop میشوند را نمیبیند. از طریق کنسول، دستور sudo tcpdump -ni any tcp port 22 را اجرا کنید و همزمان از لپتاپ خود برای اتصال تلاش کنید. اگر هیچ بستهای دریافت نشد، یعنی drop در لایه بالادستی (پنل) رخ میدهد. اگر بستهها دریافت شدند اما پاسخی ارسال نشد، یعنی drop در سطح محلی و توسط ufw یا nftables انجام میشود.
آیا ناموفق بودن ping به معنای خاموش بودن VPS است؟
خیر. بسیاری از ارائهدهندگان، ترافیک ICMP را در لبه شبکه فیلتر میکنند؛ بنابراین سروری که در حال سرویسدهی عادی است، میتواند تمام pingهای ارسالی شما را نادیده بگیرد. موفقیتآمیز بودن ping نیز در جهت مخالف چندان معتبر نیست، زیرا هیچ اطلاعاتی درباره باز بودن پورت 22 ارائه نمیدهد. پورت را با استفاده از nc -vz -w 5 203.0.113.10 22 از سیستم خود یا با Test-NetConnection 203.0.113.10 -Port 22 در PowerShell ویندوز تست کنید.
پورت SSH را تغییر دادم و اکنون هیچ اتصالی برقرار نمیشود. چه مشکلی پیش آمده است؟
دو مورد باعث این اتفاق میشود. اگر فایروال قانونی برای پورت جدید دریافت نکرده باشد، تلاشها برای اتصال به پورت جدید دچار timeout میشوند در حالی که پورت 22 اتصال را رد میکند؛ بنابراین sudo ufw allow 2222/tcp باید پیش از تغییر پورت اعمال شود، نه پس از آن. اگر سرور از systemd socket activation برای SSH استفاده میکند، Port 2222 در sshd_config نادیده گرفته میشود و systemd همچنان پورت قدیمی را نگه میدارد که میتوانید این موضوع را با systemctl is-enabled ssh.socket تأیید کنید. از طریق کنسول ارائهدهنده بازیابی را انجام دهید، مورد مربوطه را اصلاح کنید و سپس با ssh -p 2222 user@203.0.113.10 متصل شوید، به شرطی که sudo ss -tlnp سوکت جدید را نشان دهد.