محتوای آموزشی وبلاگ نت‌آرام
به سرور SSH می‌زنید؛ ارتباط برقرار می‌شود، اما چند ثانیه تا دیدن درخواست رمز یا ظاهر شدن خط فرمان منتظر می‌مانید. کندی می‌تواند پیش از اتصال، هنگام احراز هویت یا بعد از ورود رخ دهد. DNS، روش احراز هویت سازمانی، منبع حساب‌ها و فایل‌های آغاز پوسته فقط چند علت ممکن‌اند.
در بسیاری از راهنماها فوراً پیشنهاد می‌شود
UseDNS no یا GSSAPIAuthentication no را برای همه فعال کنید. این تغییرها برای همه سرورها لازم نیستند و در شبکه‌هایی که از نام میزبان یا Kerberos استفاده می‌کنند ممکن است دسترسی را مختل کنند. ابتدا محل تأخیر را اندازه می‌گیریم، سپس فقط همان علت را اصلاح می‌کنیم.در مثال‌ها
server.example، adminuser و آدرس‌های مستندات نمونه‌اند. از رایانه‌ای که با آن SSH می‌زنید و همچنین از یک نشست مدیریتی باز روی سرور استفاده کنید. پیش از تغییر تنظیم SSH، کنسول ارائه‌دهنده و یک نشست دیگر را آماده نگه دارید.۱. تأخیر در کدام مرحله است؟
روی رایانه مشتری، نه روی سرور، اتصال را با پیام‌های تشخیصی اجرا کنید:
کد / دستورssh -vvv adminuser@server.example
پورت غیرپیش‌فرض را با
-p مشخص کنید. به آخرین پیام قبل از مکث و زمانی که اتصال دوباره پیش می‌رود توجه کنید. شکل پیام‌ها بر اساس نسخه OpenSSH و روش ورود فرق می‌کند. گزارش می‌تواند نام کاربر، IP، نام کلید و اطلاعات داخلی را نشان دهد؛ آن را بدون پاک کردن اطلاعات حساس برای دیگران نفرستید.به این سه حالت توجه کنید:
۱. پیش از اتصال به آدرس: حل نام سرور، مسیر شبکه یا پورت می‌تواند مشکل داشته باشد.
۲. پس از اتصال و پیش از پایان احراز هویت: ممکن است DNS معکوس، Kerberos/GSSAPI، منبع کاربر سازمانی یا پاسخ روش ورود زمان‌بر باشد.
۳. پس از ورود موفق و پیش از نمایش خط فرمان: راه‌اندازی پوسته، home شبکه‌ای یا کارهای آغاز نشست می‌توانند علت باشند.
پیام قبلی الزاماً مقصر قطعی نیست. چند بار آزمایش کنید و هم‌زمان ساعت را ثبت کنید؛ کش DNS و شرایط شبکه ممکن است زمان آزمایش‌ها را تغییر دهند.
۲. زمان اتصال بدون استفاده از نشست مشترک را بسنجید
در ترمینال Linux یا macOS مشتری:
کد / دستورtime ssh -o ControlMaster=no -o ControlPath=none adminuser@server.example true
این دستور پس از ورود، دستور ساده
true را روی سرور اجرا و خارج می‌شود. ControlPath=none کمک می‌کند اتصال قبلیِ اشتراکی نتیجه را مخفی نکند. مقدار real زمان کل است؛ اگر رمز لازم باشد، زمان تایپ شما هم در آن حساب می‌شود. برای مقایسه، هر بار با همان روش ورود و شرایط مشابه تست کنید.روی Windows PowerShell، در صورت نصب OpenSSH client می‌توانید زمان را این‌طور ببینید:
کد / دستورMeasure-Command { ssh -o ControlMaster=no -o ControlPath=none adminuser@server.example true }
اگر سیاست ورود شما اجرای دستور از راه دور را نمی‌پذیرد، همین آزمون ممکن است شکست بخورد؛ از روش مجاز سازمان استفاده کنید.
true نیز از مسیر اجرای فرمان حساب و پوسته آن عبور می‌کند، پس مقایسه آن با نشست تعاملی یک سرنخ است نه تفکیک قطعی همه مراحل.۳. نام سرور روی رایانه مشتری کند حل می‌شود؟
روی مشتری لینوکسی:
کد / دستورtime getent ahosts server.example
اگر این دستور خودش چند ثانیه طول می‌کشد یا خطا می‌دهد، حل نام مقصد را بررسی کنید.
کد / دستورgetent از تنظیم نام‌سرویس سیستم استفاده می‌کند و لزوماً فقط DNS خام را آزمایش نمی‌کند. روی Windows:Resolve-DnsName server.example
اگر دامنه به IP اشتباه اشاره دارد، رکورد صحیح و DNS مورد استفاده مشتری را با مدیر دامنه بررسی کنید. استفاده آزمایشی از IP می‌تواند یک سرنخ باشد، اما نام و IP ممکن است در
known_hosts به عنوان هویت‌های متفاوت دیده شوند؛ اثرانگشت کلید میزبان را از مسیر مطمئن تطبیق دهید و هشدار تغییر کلید را نادیده نگیرید.اگر حل نام سریع است ولی پیش از برقراری اتصال مکث دارید، مسیر شبکه و در دسترس بودن پورت SSH را جداگانه بررسی کنید. تغییر
UseDNS در این مرحله مشکل DNS مشتری یا مسدود بودن پورت را برطرف نمی‌کند.۴. آیا تلاش GSSAPI باعث مکث می‌شود؟
GSSAPI یکی از روش‌های احراز هویت است که در بعضی محیط‌های سازمانی با Kerberos استفاده می‌شود. اگر در خروجی
کد / دستورssh -vvv مکث نزدیک تلاش gssapi-with-mic دیده می‌شود و می‌دانید حساب شما روش ورود مجاز دیگری مانند کلید SSH دارد، این بار فقط برای همان اتصال آزمایش کنید:time ssh -o ControlMaster=no -o ControlPath=none -o GSSAPIAuthentication=no adminuser@server.example true
زمان را با آزمون قبلی در شرایط مشابه مقایسه کنید. اگر تفاوت تکرارپذیر و بزرگ است، تأخیر در مسیر GSSAPI محتمل است. در سازمانی که به Kerberos وابسته است، به جای خاموش کردن آن برای همه، تنظیم DNS، دسترسی به سرویس هویت و زمان سیستم را با مدیر شبکه اصلاح کنید.
اگر برای همین مقصد و همین مشتری سازمان تأیید کرده به GSSAPI نیاز ندارید، می‌توانید در فایل
کد / دستور~/.ssh/config کاربر مشتری یک بخش اختصاصی اضافه کنید:Host netaram-vps
HostName server.example
User adminuser
GSSAPIAuthentication no
این نام فقط یک میانبر است و آدرس واقعی خودتان باید جایگزین شود. اگر فایل تنظیمات از قبل وجود دارد، از آن نسخه بگیرید و بخش تازه را طوری قرار دهید که تنظیم‌های قبلی آن را بی‌اثر نکنند؛ در OpenSSH معمولاً اولین مقدار به‌دست‌آمده برای هر گزینه اعمال می‌شود. برای دیدن مقدار مؤثر بدون اتصال:
کد / دستورssh -G netaram-vps | grep -i '^gssapiauthentication '
اگر خروجی
no است، با ssh netaram-vps آزمون را تکرار کنید. این تنظیم روی مشتری فقط برای میزبان تعیین‌شده است؛ سرور و روش‌های ورود دیگر را تغییر نمی‌دهد.۵. DNS معکوس کدام IP را باید بررسی کنیم؟
وقتی صحبت از
UseDNS در SSH سرور است، موضوع معمولاً تبدیل IP رایانه‌ای است که به سرور وصل می‌شود به نام میزبان؛ این با رکورد دامنه خود سرور یا PTR سرور یک موضوع یکسان نیست. اگر اتصال از NAT یا VPN عبور می‌کند، IP مشاهده‌شده در گزارش سرور ممکن است IP دروازه باشد.روی سرور، آدرس مشتری را از گزارش همان اتصال پیدا کنید. برای یک IP نمونه:
کد / دستورtime getent hosts 192.0.2.10
عدد را با IP واقعی مشتری جایگزین کنید. اگر نتیجه کند است، ممکن است مسیر نام‌سرویس سرور یا PTR در تأخیر نقش داشته باشد؛ اما
کد / دستورgetent می‌تواند از hosts و کش هم استفاده کند و این آزمایش به‌تنهایی اثبات نمی‌کند SSH دقیقاً همین lookup را انجام داده است. وضعیت resolver را با ابزار مناسب توزیع و شبکه بررسی کنید. اگر dig نصب دارید، پرس‌وجوی DNS معکوس را نیز می‌توانید جداگانه ببینید:dig -x 192.0.2.10 +time=2 +tries=1
وجود PTR معتبر، پاسخ سریع resolver و تطبیق رکورد رو‌به‌جلو با آدرس مشتری را در صورت نیاز سیاست سازمان بررسی کنید. ثبت یا اصلاح PTR معمولاً باید توسط دارنده شبکه یا ارائه‌دهنده IP مشتری انجام شود.
برای دیدن مقدار مؤثر SSH server:
کد / دستورsudo /usr/sbin/sshd -T | grep -i '^usedns '
در نسخه‌های جدید OpenSSH مقدار پیش‌فرض اغلب
no است، اما تنظیم توزیع یا نسخه شما ممکن است فرق کند. اگر همین حالا usedns no است، تکرار همان تغییر درمان مشکل نیست.۶. اگر واقعاً لازم است UseDNS را تغییر دهید
فقط اگر می‌دانید سیاست‌های شما به نام میزبان مشتری در
Match Host یا محدودیت‌های نام‌محور کلیدها وابسته نیستند و مدیر سازمان تأیید کرده است، می‌توانید مقدار مؤثر را به UseDNS no تغییر دهید. این گزینه بر کاربرد نام میزبان در برخی قواعد SSH اثر دارد؛ تغییر آن ممکن است قانون دسترسی را عوض کند.از فایل پیکربندی مرتبط نسخه پشتیبان بگیرید و با آگاهی از
کد / دستورInclude و ترتیب فایل‌ها، مقدار موجود را در محل مناسب اصلاح کنید. افزودن یک خط تکراری در انتهای فایل همیشه مقدار مؤثر را تغییر نمی‌دهد. قبل از اعمال:sudo /usr/sbin/sshd -t
اگر خروجی خطا دارد، reload نکنید و تنظیم را اصلاح کنید. دوباره با
کد / دستورsshd -T مقدار مؤثر را ببینید. سپس در Ubuntu با سرویس فعال ssh:sudo systemctl reload ssh
در AlmaLinux معمولاً نام سرویس
کد / دستورsshd است:sudo systemctl reload sshd
فقط دستور مربوط به سرویس واقعی خود را اجرا کنید. نشست مدیریتی قبلی را باز نگه دارید و یک اتصال تازه را با همان حساب و سیاست معمول آزمایش کنید. اگر نتیجه یا دسترسی نامطلوب بود، تنظیم تأییدشده قبلی را برگردانید،
sshd -t و reload را تکرار کنید.۷. اگر مکث بعد از ورود موفق است
اگر پیام احراز هویت موفق ظاهر می‌شود ولی خط فرمان دیر می‌آید، روی سرور با یک نشست سالم، وضعیت منبع حساب را بسنجید:
کد / دستورtime getent passwd adminuser
اگر حساب از LDAP یا Active Directory می‌آید و این دستور کند است، مسیر سرویس هویت و DNS سازمان را با مدیر آن بررسی کنید. همچنین home روی NFS، اسکریپت‌های ورود و دستورهای سنگین فایل‌های راه‌اندازی پوسته می‌توانند تأخیر ایجاد کنند. پیش از تغییر این فایل‌ها نسخه پشتیبان بگیرید و با غیرفعال کردن موقت فقط بخش شناخته‌شده در محیط آزمایشی زمان را مقایسه کنید.
در پایان چند اتصال تازه با نام، پورت و روش ورود معمول بگیرید. موفقیت یعنی مرحله مشکل‌دار سریع‌تر شود و سیاست امنیتی و دسترسی کاربران همچنان درست کار کند. این بررسی برای سرور مجازی ایران و سرور اختصاصی ایران کاربرد دارد. جزئیات گزینه‌های مشتری و سرور را در مستند ssh_config و مستند sshd_config ببینید.
برچسب‌ها:
اشتراک‌گذاری:
لینکدینتلگرامایکس
مقاله قبلی
مقاله بعدی
دیدگاه‌ها (۰)
دیدگاه‌های تاییدشده و پاسخ‌های تیم نت‌آرام