بعد از ویرایش SSH، ورود تازه قطع شد؛ جلسه قبلی را نبند

موقعیت بحرانی: تنظیم SSH را تغییر داده‌اید. پنجره فعلی هنوز کار می‌کند، اما ورود از یک پنجره تازه شکست می‌خورد. وسوسه ری‌استارت کل سرور وجود دارد؛ درحالی‌که شاید تنها مسیر مدیریت باقی‌مانده همان جلسه باز باشد.

مسیر نجات را حفظ کنیم

جلسه قدیمی را نبندید. اگر تمام اتصال‌ها قطع شده‌اند، از کنسول مدیریتیِ از قبل مجاز، مثل کنسول ماشین مجازی یا مدیریت خارج از باند، استفاده کنید. این یادداشت درباره اصلاح تنظیم سرور تحت مدیریت خودتان است؛ ورود بدون مجوز یا دورزدن احراز هویت راه بازیابی نیست.

نوع خطا را از روی شاهد جدا کنیم

Timeout، ردشدن اتصال و خطای احراز هویت علت یکسان ندارند. پورت واقعی را از پیکربندی و Listener بررسی کنید؛ پیش‌فرض‌گرفتن پورت می‌تواند شما را سراغ سرویس اشتباه ببرد. مثال‌های زیر برای Ubuntu با systemd هستند و وضعیت را می‌خوانند یا اعتبار پیکربندی را بررسی می‌کنند:

sudo /usr/sbin/sshd -t
sudo systemctl status ssh.service ssh.socket --no-pager
sudo journalctl -u ssh.service -n 50 --no-pager
sudo ss -ltnp

خروجی موفق و بدون پیامِ sshd -t به معنی معتبر بودن آزمون نحوی و بررسی کلیدهاست؛ تضمین نمی‌کند کاربر موردنظر اجازه ورود دارد یا فایروال مسیر را باز گذاشته است.

تغییر آخر را دقیق برگردانیم

فایل و خطی را که در خطا آمده بررسی کنید. تنظیم ممکن است در فایل اصلی یا یک فایل Include داخل sshd_config.d باشد؛ جایگزین‌کردن فایل اصلی الزاماً اثر تغییر جدید را خنثی نمی‌کند. نسخه سالمِ شناخته‌شده یا همان تغییر مشخص را برگردانید، دوباره اعتبارسنجی کنید و فقط پس از موفقیت، روش اعمال متناسب با پیکربندی سرویس را انجام دهید.

در نصب‌هایی که Socket activation دارند، تغییر Port یا ListenAddress به گردش جداگانه مربوط است؛ صرف Reload سرویس را نسخه عمومی برای چنین تغییری ندانید. این راهنما عمداً مشکل نحوی و سیاست ورود را از جابه‌جایی پورت و تنظیم Listener جدا می‌کند.

اگر آزمون نحوی موفق است اما ورود رد می‌شود، حساب، کلید، مجوز فایل‌های مرتبط و قواعد Match را با لاگ همان تلاش بررسی کنید. برای بازکردن سریع راه ورود، احراز هویت یا محدودیت‌های کل سرور را یکجا ضعیف نکنید.

آزمونی که باید قبل از خروج انجام شود

از یک پنجره تازه، با همان روش ورود مجاز، اتصال جدید بسازید و یک فرمان بی‌اثر مثل نمایش نام میزبان را اجرا کنید. اگر مدیریت شما به sudo نیاز دارد، همان دسترسی موردنیاز را نیز کنترل کنید. تنها بعد از موفقیت این مسیر، جلسه قدیمی را ببندید.

تصمیم نجات‌دهنده: معتبر بودن فایل با قابل‌استفاده بودن راه ورود یکسان نیست؛ هر دو را پیش از قطع مسیر قبلی امتحان کنیم.

منابع: راهنمای OpenSSH در Ubuntu، رفتار آزمون پیکربندی در sshd.