وصل نشدن SSH به سرور را از متن خطا دسته‌بندی کنید: timeout معمولاً بررسی مسیر و فیلتر شبکه را می‌طلبد؛ Connection refused بیشتر به نبود listener یا رد فعال اتصال اشاره دارد؛ Permission denied یعنی به مرحله احراز هویت رسیده‌اید. راه‌حل این سه حالت یکسان نیست و تغییر تصادفی رمز، پورت و فایروال می‌تواند دسترسی را سخت‌تر کند.
این راهنما برای مالک VPS یا مدیری است که مجوز دسترسی به سرور دارد. قبل از تغییر تنظیمات، از وجود کنسول پنل یا مسیر دسترسی جایگزین مطمئن شوید و اگر نشست سالمی دارید آن را باز نگه دارید. تمام فرمان‌ها فقط برای مقصد متعلق به خودتان هستند. نام کاربری، IP و پورت نمونه را از اطلاعات واقعی سرویس جایگزین کنید.
نقشه سریع تشخیص خطای اتصال SSH
| پیام یا نشانه | کدام مرحله؟ | بررسی بعدی |
|---|---|---|
| Could not resolve hostname | پیداکردن مقصد | املای نام و پاسخ DNS |
| Connection timed out | برقراری اتصال شبکه | IP، پورت، مسیر و فیلترها |
| Connection refused | اتصال رد شده | listener و سرویس یا قانون رد فعال |
| Permission denied | احراز هویت | کاربر، کلید و سیاست ورود |
| Host key verification failed | تطبیق هویت سرور | اثر انگشت از مسیر مورد اعتماد |
این جدول راهنمای انتخاب قدم بعدی است، نه تشخیص قطعی همه معماری‌ها. برای نمونه، یک تجهیز میان مسیر می‌تواند اتصال را رد کند؛ بنابراین refused الزاماً ثابت نمی‌کند که پاسخ از خود VPS آمده است. زمان دقیق و نتیجه آزمون از یک شبکه مستقل، به محدودکردن مسئله کمک می‌کند.
۱. IP، نام کاربری و پورت واقعی را دوباره تطبیق دهید
اطلاعات را از پنل رسمی سرویس یا مستندات تحویل بگیرید. پس از نصب مجدد یا تغییر IP، میانبر قدیمی ممکن است به مقصد قبلی اشاره کند. نام کاربر پیش‌فرض در همه توزیع‌ها یکسان نیست. اگر ارائه‌دهنده ورود root را مجاز ندانسته، اصرار بر همان نام کاربری کمکی نمی‌کند؛ کاربر مجاز تحویل‌داده‌شده را استفاده کنید.
اگر با دامنه وصل می‌شوید، پاسخ DNS را با IP مورد انتظار مقایسه کنید. برای دامنه دارای A و AAAA، کلاینت ممکن است مسیر IPv6 را امتحان کند. تفاوت رفتار دو مسیر را از اطلاعات اتصال ببینید و به‌جای حذف عمومی IPv6، رکورد و مسیر واقعی را بررسی کنید. برای عیب‌یابی DNS، راهنمای NXDOMAIN مسیر مکملی ارائه می‌کند.
ssh -p 22 USER@SERVER_IPدر فرمان نمونه، 22 را فقط اگر پورت واقعی شماست نگه دارید. گزینه -p با حرف کوچک در ssh برای پورت است. از کپی‌کردن IP داخل یک مقاله به‌عنوان مقصد آزمایش خودداری کنید؛ مقدارهای بزرگ‌نویسی‌شده این راهنما جای‌نگهدارند و باید تعویض شوند.
۲. پورت TCP را از دستگاه خودتان بررسی کنید
در ویندوز، Test-NetConnection در PowerShell می‌تواند برقراری اتصال TCP به پورت موردنظر را بررسی کند. این آزمون ورود به حساب را انجام نمی‌دهد و موفقیت آن به معنی معتبر بودن کلید یا مجازبودن کاربر نیست. نتیجه TcpTestSucceeded را در کنار آدرس مقصد و شبکه‌ای که از آن وصل هستید بخوانید.
Test-NetConnection -ComputerName SERVER_IP -Port 22اگر آزمون موفق نشد، IP و پورت را دوباره تطبیق دهید و در صورت امکان از یک اتصال مستقل مجاز مقایسه کنید. پاسخ ping برای SSH کافی نیست و نبود پاسخ ping نیز بازنبودن TCP را ثابت نمی‌کند؛ ممکن است ICMP محدود شده باشد. به‌جای بازکردن همه پورت‌ها، همان پورت و مبدأ مشخص را در مسیر بررسی کنید.
۳. برای timeout، فیلترهای مسیر را مرحله‌به‌مرحله ببینید
محدودیت می‌تواند در شبکه محلی، فایروال سیستم‌عامل VPS، فایروال پنل ارائه‌دهنده یا قانون مبدأ مجاز باشد. اگر IP اینترنت شما عوض شده، allowlist قدیمی ممکن است دیگر با مبدأ شما تطبیق نداشته باشد. وجود یک قانون در UFW، سلامت فایروال بیرونی را اثبات نمی‌کند؛ هر لایه مسئولیت جدا دارد.
از کنسول رسمی سرور، فقط وضعیت را بخوانید و قوانین مؤثر همان پورت را بررسی کنید. خاموش‌کردن کامل فایروال یا سرویس تشخیص تلاش ورود، آزمونی بسیار گسترده است. اگر محدودیت موقت ضدحدس‌زدن رمز اعمال شده، پس از احراز مالکیت، علت و زمان آن را پیگیری کنید؛ تکرار ورود ناموفق می‌تواند مدت مشکل را بیشتر کند.
۴. برای refused، listener و سرویس را از کنسول بررسی کنید
اگر SSH تنها راه دسترسی شماست و اکنون قطع است، کنسول وب یا سریال ارائه‌دهنده نقطه شروع است. در سیستم دارای systemd، وضعیت واحد SSH را بخوانید. نام سرویس در برخی توزیع‌ها ssh و در برخی sshd است. از نام واقعی نصب خودتان استفاده کنید. در معماری socket activation، وضعیت socket نیز باید در نظر گرفته شود.
sudo ss -lntp
systemctl status ssh --no-pager
sudo journalctl -u ssh --since "30 minutes ago"در خروجی ss، پورت و آدرس bind را ببینید. گوش‌دادن فقط روی loopback با دسترسی از اینترنت یکسان نیست. اگر سرویس متوقف است، خطای شروع آن را بخوانید؛ شاید فایل تنظیمات یا مسیر کلید میزبان مشکل داشته باشد. قبل از هر reload یا restart، صحت پیکربندی را با روش رسمی نصب بررسی کنید.
sudo /usr/sbin/sshd -tاین مسیر در بسیاری از نصب‌ها رایج است، اما باید با محل واقعی باینری مطابقت داشته باشد. خروجی خالی و موفق آزمون، مجازبودن ورود کاربر یا عبور فایروال را ثابت نمی‌کند. اگر خطا گزارش شد، همان خط را اصلاح و دوباره آزمون کنید؛ سرویس سالم را با پیکربندی نامعتبر بازراه‌اندازی نکنید.
۵. برای Permission denied، کلید و سیاست ورود را بررسی کنید
وقتی به این مرحله می‌رسید، تغییر فایروال معمولاً پاسخ مسئله احراز هویت نیست. نام کاربر را کنترل کنید، مطمئن شوید کلید عمومی درست برای همان حساب نصب است و کلاینت کلید خصوصی موردنظر را ارائه می‌دهد. در دستگاهی با چند کلید، انتخاب صریح کلید به تشخیص کمک می‌کند. کلید خصوصی را برای پشتیبانی ارسال نکنید.
ssh -vv -o IdentitiesOnly=yes -i /path/to/private_key -p 22 USER@SERVER_IPخروجی verbose نشان می‌دهد کدام روش و کلید امتحان شده است. لاگ را پیش از اشتراک‌گذاری از نام‌ها، مسیرهای خصوصی و نشانی‌های حساس پاک کنید. در سمت سرور، مالکیت و مجوز پوشه خانه، .ssh و authorized_keys و تنظیمات Match را بررسی کنید. مجوز 777 برای حل مشکل، نه لازم است و نه جایگزین اصلاح مالکیت و سیاست درست می‌شود.
با هشدار تغییر کلید میزبان چه کنیم؟
پس از نصب مجدد، تغییر کلید می‌تواند طبیعی باشد، اما نباید آن را بدون تطبیق بپذیرید. اثر انگشت جدید را از کنسول رسمی یا مسیر مورد اعتماد ارائه‌دهنده بگیرید و با هشدار کلاینت مقایسه کنید. اگر تطبیق ندارید، اتصال را ادامه ندهید و بررسی کنید به IP درست وصل می‌شوید. پاک‌کردن کامل known_hosts صرفاً برای حذف هشدار، هویت مقصد را اثبات نمی‌کند.
معیار رفع مشکل و گزارش مناسب برای پشتیبانی
پس از اصلاح، یک نشست جدید باز کنید، هویت سرور را تطبیق دهید و با کاربر مجاز وارد شوید. نشست قدیمی را تا پایان آزمون نگه دارید. اگر پورت یا قانون مبدأ تغییر کرده، مستندات دسترسی تیم را نیز اصلاح کنید. یک اتصال موفق از شبکه داخلی، الزاماً مسیر خارجی موردنیاز شما را بررسی نکرده است.
گزارش مناسب شامل IP مقصد، پورت، زمان و منطقه زمانی، متن دقیق خطا و نتیجه TCP از شبکه شماست. رمز و کلید خصوصی لازم نیست. برای انتخاب زیرساخت، مشخصات سرور مجازی ایران و برای نگهداری و بررسی تکرار اختلال، خدمات مدیریت سرور آفاق هاست را ببینید.
پرسش‌های رایج
آیا عوض‌کردن پورت SSH مشکل timeout را حل می‌کند؟
اگر علت مشخصی در مسیر پورت قبلی وجود داشته باشد شاید لازم شود، اما تغییر پورت بدون اصلاح listener و فایروال می‌تواند دسترسی را قطع‌تر کند. ابتدا علت را پیدا کنید.
چرا ping موفق است اما SSH وصل نمی‌شود؟
ICMP و TCP پورت SSH دو آزمون متفاوت‌اند. سرویس، پورت و قوانین TCP را جدا بررسی کنید.
آیا برای Permission denied باید ورود رمزی یا root را فعال کنم؟
خیر. ابتدا نام کاربر، کلید و سیاست موجود را بررسی کنید. کاهش حفاظت ورود، جای تشخیص علت رد احراز هویت نیست.
منابع رسمی
سرویس‌های مرتبط با این مطلب
برای بررسی راهکار مناسب، مشخصات و شرایط این خدمات را ببینید.
پرسش‌ها و دیدگاه‌های شما
سؤال یا تجربه مرتبط با این مطلب دارید؟ با ما و خوانندگان مجله آفاق هاست در میان بگذارید.