محتوای آموزشی وبلاگ نت‌آرام
SSH به سرور مجازی ایران وصل می‌شود و کلید یا رمز پذیرفته می‌شود، اما پنجره فوراً بسته می‌شود یا پیام
Connection closed می‌بینید. احراز هویت تنها یکی از مراحل ورود است. بعد از آن سرور باید نشست، مجوزهای حساب و برنامه‌ای به نام shell یا فرمان تعیین‌شده را اجرا کند. مشکل در هر یک از این مرحله‌ها می‌تواند نشست را ببندد.این راهنما مخصوص قطع بلافاصله پس از احراز هویت موفق است. اگر از ابتدا timeout یا
Permission denied دارید، باید شبکه یا احراز هویت را جدا بررسی کنید. اگر اتصال بعد از چند دقیقه بیکاری قطع می‌شود، راهنمای قطع SSH در زمان بیکاری مناسب‌تر است. پیش از تغییر تنظیم SSH حتماً کنسول یا نشست مدیریتی دیگری نگه دارید.۱. مرحله قطع را از سمت کلاینت مشخص کنید
روی رایانه‌ای که از آن وصل می‌شوید، نام کاربر و سرور واقعی را جایگزین کنید:
کد / دستورssh -vvv alice@example.com
خروجی جزئیات اتصال، تأیید هویت و ایجاد کانال را نشان می‌دهد. عبارت
Authenticated to نشانه پذیرش احراز هویت است، اما الزاماً موفقیت بازشدن نشست یا مجوز ورود کامل را ثابت نمی‌کند. متن نزدیک لحظه قطع و زمان آن را یادداشت کنید. گزارش ممکن است نام حساب، IP و مسیر کلید را داشته باشد؛ قبل از ارسال بخش‌های حساس را حذف کنید. اگر اثر انگشت کلید میزبان تغییر غیرمنتظره کرده است، پیش از ادامه هویت سرور را از مسیر مستقل تأیید کنید.برای مقایسه، اگر سیاست حساب اجازه اجرای فرمان می‌دهد، از کلاینت امتحان کنید:
کد / دستورssh -T alice@example.com 'id'
این فرمان بدون درخواست ترمینال تعاملی،
id را اجرا می‌کند و باید شناسه حساب را نشان دهد. موفقیت آن و شکست ورود تعاملی می‌تواند به تنظیم ترمینال یا فایل‌های شروع shell اشاره کند. شکست آن علت را به‌تنهایی مشخص نمی‌کند؛ حساب محدود به SFTP یا ForceCommand ممکن است عمداً اجرای فرمان را ممنوع کرده باشد. هیچ محدودیت امنیتی را صرفاً برای موفقیت این آزمون حذف نکنید.۲. لاگ همان تلاش را در سرور پیدا کنید
از کنسول پنل یا یک حساب مدیر دیگر به سرور وصل شوید. در لینوکس اجرا کنید:
کد / دستورsudo journalctl -u ssh --since '30 minutes ago' --no-pager
sudo journalctl -u sshd --since '30 minutes ago' --no-pager
نام سرویس به توزیع وابسته است و ممکن است یکی از دو دستور لاگی نداشته باشد. در توزیع‌هایی که لاگ فایل جدا دارند،
/var/log/auth.log یا /var/log/secure را با مجوز مناسب بررسی کنید. زمان، کاربر و IP همان تلاش را تطبیق دهید. دنبال خطایی پس از Accepted بگردید: خطای بازکردن session توسط PAM، shell ناموجود، محدودیت منابع یا فرمان اجباری ناموفق. خطای تلاش قدیمی کاربر دیگر را علت این رخداد فرض نکنید.۳. حساب و shell را بررسی کنید
کد / دستورgetent passwd alice
id alice
نام
کد / دستورalice نمونه است. خروجی دستور اول معمولاً نام حساب، UID، خانه و shell را نشان می‌دهد؛ حساب ممکن است از سرویس دایرکتوری بیاید. فرمان دوم شناسه و گروه‌های همان حساب را نمایش می‌دهد. مسیر shell درج‌شده در خروجی را با فایل واقعی و سیاست حساب تطبیق دهید. برای نمونه اگر shell /bin/bash است:ls -l /bin/bash
ls -ld /home/alice
مسیرها مثال‌اند. shell ناموجود یا خانه نامعتبر می‌تواند مشکل بسازد، اما حساب سرویس ممکن است عمداً
nologin داشته باشد یا اجازه shell تعاملی نداشته باشد. تغییر shell با chsh بدون دانستن نقش حساب یک محدودیت امنیتی را از بین می‌برد. اگر بسته shell حذف شده، ابتدا علت و بسته معتبر توزیع را بررسی کنید؛ اگر حساب فقط برای SFTP طراحی شده، روش دسترسی مورد تأیید همان سرویس را به کار ببرید.۴. تنظیم‌های وابسته به حساب و نشست را بخوانید
در سرور، تنظیم‌های مؤثر SSH را برای مشخصات اتصال نمونه بخوانید:
کد / دستورsudo sshd -T -C user=alice,host=client.example,addr=192.0.2.50 | grep -i -E 'forcecommand|chrootdirectory|permittty|usepam'
در این فرمان نام حساب، نام و IP کلاینت را با مقادیر واقعی جایگزین کنید؛ مقدارها برای ارزیابی قواعد
Match هستند. نسخه و گزینه‌های پشتیبانی‌شده را با man sshd بررسی کنید. ForceCommand، chroot و عدم اجازه TTY ممکن است عمداً برای حساب تعیین شده باشند. کلید عمومی همان کاربر نیز می‌تواند محدودیت فرمان داشته باشد؛ پیش از اصلاح، مالک حساب و سیاست دسترسی را بشناسید. مستند sshd_config معنی این تنظیم‌ها را توضیح می‌دهد.اگر لاگ PAM دلیل مشخصی مانند حساب منقضی یا محدودیت session دارد، همان مورد را با سیاست سازمان بررسی کنید. PAM، MFA یا کنترل حساب را برای امتحان خاموش نکنید. اگر فقط ورود تعاملی مشکل دارد، خطاهای فایل‌های شروع shell مانند
.profile یا .bashrc را در کنسول بخوانید؛ از دست‌کاری فایل‌های حساب دیگر بدون هماهنگی خودداری کنید.۵. فضای دیسک و منابع را نیز بسنجید
کد / دستورdf -h
df -i
پرشدن فضا یا inode می‌تواند ایجاد فایل‌های موقت یا ثبت نشست را مختل کند. خروجی هر فایل‌سیستم را برای مسیر مرتبط بخوانید؛ فضای خالی یک دیسک دیگر مشکل ریشه یا خانه کاربر را رفع نمی‌کند. اگر inode پر است، راهنمای خطای No space با وجود فضای خالی روش تشخیص را توضیح می‌دهد. از حذف لاگ‌ها یا فایل‌های کاربر بدون شناخت مالک و نیاز بازیابی پرهیز کنید.
۶. تغییر را امن اعمال و نتیجه را تأیید کنید
پس از اصلاح علت مشخص، اگر فایل تنظیم sshd تغییر کرده، قبل از اعمال اجرا کنید:
کد / دستورsudo sshd -t
sudo systemctl reload ssh
اگر اعتبارسنجی خطا داد reload نکنید. نام سرویس در بعضی توزیع‌ها
sshd است. نشست قدیمی و کنسول را باز نگه دارید و از یک اتصال جدا با همان حساب، روش احراز هویت و شبکه قبلی ورود را آزمایش کنید. اگر تنظیم جدید دسترسی را خراب کرد، فایل ثبت‌شده قبلی را از کنسول برگردانید، دوباره sshd -t و سپس reload سرویس صحیح را انجام دهید.در پایان بررسی کنید هم ورود مجاز و هم محدودیت حساب‌های دیگر طبق سیاست قبلی عمل می‌کنند. اگر قطع همچنان فقط از یک شبکه رخ می‌دهد و لاگ سرور نشست را طبیعی نشان می‌دهد، تجهیز میانی یا کلاینت را با زمان دقیق و گزارش دو طرف بررسی کنید؛ نباید هر reset شبکه را به shell نسبت داد.
برچسب‌ها:
اشتراک‌گذاری:
لینکدینتلگرامایکس
مقاله قبلی
مقاله بعدی
دیدگاه‌ها (۰)
دیدگاه‌های تاییدشده و پاسخ‌های تیم نت‌آرام