محتوای آموزشی وبلاگ نت‌آرام
می‌خواهید با SSH به یک سرور وصل شوید، اما پیش از درخواست رمز پیام
no matching host key type found نمایش داده می‌شود. گاهی انتهای پیام نوشته است Their offer: ssh-rsa. معنی ساده آن این است که کلاینت و سرور برای روشی که سرور با آن هویت خود را ثابت می‌کند، گزینه مشترک قابل استفاده پیدا نکرده‌اند.کلید میزبان برای شناخت خود سرور است؛ با کلید خصوصی کاربر که برای ورود استفاده می‌کنید فرق دارد. حذف فایل
known_hosts، خاموش‌کردن بررسی هویت سرور یا ساخت دوباره کلید ورود کاربر معمولاً این ناسازگاری را حل نمی‌کند و می‌تواند شما را در معرض اتصال به سرور اشتباه قرار دهد.در این راهنما ابتدا خطا و گزینه‌های دو طرف را می‌خوانیم، سپس راه پایدار در سمت سرور و یک راه موقت محدود به همان مقصد را توضیح می‌دهیم. این وضعیت ممکن است هنگام مدیریت سرور مجازی ایران، سرور اختصاصی ایران یا تجهیزات قدیمی شبکه رخ دهد. مثال‌ها از کلاینت OpenSSH در ترمینال لینوکس، macOS یا Windows با OpenSSH استفاده می‌کنند؛ عبارت
admin@example.com نمونه است.۱. ببینید دقیقاً کدام مرحله شکست خورده است
در رایانه خود، نه لزوماً داخل سرور، نسخه و جزئیات اتصال را ببینید:
کد / دستورssh -V
ssh -vv admin@example.com
اگر سرور پورت متفاوتی دارد، با
-p پورت واقعی را مشخص کنید. در خروجی دنبال جمله no matching host key type found و متن پس از Their offer: بگردید. گزارش پرجزئیات ممکن است نام کاربر، مسیر کلید یا نشانی زیرساخت را نشان دهد؛ قبل از اشتراک‌گذاری اطلاعات حساس را حذف کنید.اگر خطا به‌جای host key درباره
no matching key exchange method، no matching cipher یا Permission denied (publickey) است، مسئله همان مرحله نیست. تبادل کلید، رمزگذاری ارتباط و تأیید کلید کاربر تنظیمات متفاوتی دارند. برای خطای شما باید گزینه متناسب با همان پیام بررسی شود؛ فعال‌کردن تصادفی چند الگوریتم قدیمی راه‌حل دقیقی نیست.۲. معنی ssh-rsa را با خود کلید RSA اشتباه نگیرید
در این پیام،
ssh-rsa معمولاً به روش امضای قدیمی RSA با SHA-1 اشاره دارد. این به معنی بلااستفاده‌شدن تمام کلیدهای RSA نیست: اگر دو طرف از rsa-sha2-256 یا rsa-sha2-512 پشتیبانی کنند، یک کلید RSA سازگار ممکن است با امضای جدیدتر استفاده شود. OpenSSH در یادداشت انتشار نسخه ۸٫۸ دلیل غیرفعال‌شدن پیش‌فرض امضای قدیمی و جایگزین‌ها را توضیح داده است.برای دیدن الگوریتم‌هایی که نسخه کلاینت شما می‌شناسد:
کد / دستورssh -Q key-sig
شناخته‌شدن یک گزینه الزاماً به معنی فعال‌بودن آن برای این مقصد نیست. تنظیم مؤثر همان اتصال را جداگانه بخوانید:
کد / دستورssh -G admin@example.com | grep -i '^hostkeyalgorithms '
در PowerShell ویندوز می‌توانید به‌جای
grep از Select-String 'hostkeyalgorithms' استفاده کنید. خروجی را با پیشنهاد سرور در پیام خطا مقایسه کنید. اگر ssh -Q یا ssh -G در نسخه قدیمی شما پشتیبانی نمی‌شود، راهنمای همان نسخه را ببینید و ابتدا ارتقای کلاینت را بررسی کنید. سیاست امنیتی سیستم نیز ممکن است انتخاب‌ها را محدود کند.۳. راه پایدار: سرور روش جدیدتر ارائه دهد
اگر مدیریت سرور با شماست، از کنسول ارائه‌دهنده یا نشست مدیریتی سالم وارد آن شوید. هنگام تغییر SSH یک نشست باز و راه دسترسی خارج از SSH نگه دارید تا در صورت خطا بتوانید تنظیم را برگردانید. ابتدا نسخه سرور، تنظیم و فایل‌های کلید عمومی میزبان را ببینید:
کد / دستورsshd -V
sudo sshd -T | grep -E '^(hostkey|hostkeyalgorithms) '
sudo ls -l /etc/ssh/ssh_host_*_key.pub
در برخی نسخه‌ها
sshd -V روی خروجی خطا نسخه را چاپ می‌کند و ممکن است وضعیت خروج متفاوت باشد؛ نسخه بسته و روش نصب توزیع را نیز بررسی کنید. دستور sshd -T تنظیم خوانده‌شده را نشان می‌دهد؛ تنظیمات شرطی Match، سیاست توزیع و قابل‌خواندن‌بودن فایل‌ها نیز اهمیت دارند. فایل‌هایی با پسوند .pub عمومی‌اند؛ محتوای فایل خصوصی میزبان را منتشر یا جابه‌جا نکنید.اگر نرم‌افزار سرور قدیمی است، ابتدا روش ارتقای پشتیبانی‌شده همان سیستم یا دستگاه را بررسی کنید. روی Ubuntu، مثلاً این دو دستور فهرست را تازه می‌کنند و بسته نصب‌شده OpenSSH server را در صورت وجود نسخه جدید ارتقا می‌دهند:
کد / دستورsudo apt update
sudo apt install --only-upgrade openssh-server
این نمونه فقط برای سرور مبتنی بر APT است؛ در AlmaLinux از روش بسته و مستند همان نسخه استفاده کنید. ارتقا ممکن است وابستگی‌ها یا سرویس را تغییر دهد؛ پیش از اجرا خروجی مدیر بسته، زمان نگهداری و امکان بازگشت را بررسی کنید. در وسیله‌ای مانند روتر، از firmware و راهنمای خود سازنده استفاده کنید، نه دستور APT.
اگر سرور جدیدتر است اما فقط یک روش قدیمی پیشنهاد می‌دهد، تنظیم
HostKey و HostKeyAlgorithms و سیاست رمزنگاری آن را با مستندات نصب مقایسه کنید. کلید Ed25519 یا ECDSA موجود و قابل استفاده، یا استفاده از امضای RSA-SHA2، بسته به نسخه و سیاست سیستم می‌تواند مشکل را برطرف کند. در محیط دارای محدودیت‌های رمزنگاری، همه الگوریتم‌ها مجاز نیستند؛ گزینه مناسب را طبق سیاست همان محیط انتخاب کنید.اگر واقعاً کلید میزبان جدید لازم است، ابتدا مطمئن شوید نه فایل خصوصی مقصد و نه فایل عمومی همنام آن از قبل وجود دارند و قالب آن توسط نسخه سرور و سیاست شما پشتیبانی می‌شود. برای نمونه، اگر هر دو مسیر
کد / دستور/etc/ssh/ssh_host_ed25519_key و /etc/ssh/ssh_host_ed25519_key.pub قطعاً وجود ندارند، می‌توانید Ed25519 را در مسیر پیش‌فرض بسازید:sudo ssh-keygen -t ed25519 -f /etc/ssh/ssh_host_ed25519_key -N ''
اگر دستور درباره بازنویسی فایل پرسید، بدون بررسی متوقف شوید؛ کلید موجود را کورکورانه جایگزین نکنید. در صورت نیاز مسیر کلید جدید را طبق فایل تنظیم OpenSSH همان سیستم اضافه کنید، بدون حذف کلیدهای سالمی که کلاینت‌های دیگر استفاده می‌کنند. سپس درستی تنظیم را پیش از اعمال بسنجید:
کد / دستورsudo sshd -t
نبود خروجی معمولاً یعنی بررسی نحوی خطایی پیدا نکرده، نه اینکه تمام مسیرهای اتصال تضمین شده باشند. نام سرویس در توزیع‌ها متفاوت است؛ اگر سرویس شما واقعاً
کد / دستورssh است، پس از برنامه‌ریزی می‌توانید تنظیم را بازخوانی کنید:sudo systemctl reload ssh
در بعضی سیستم‌ها نام آن
sshd است یا روش دیگری برای اعمال تنظیم وجود دارد. به نشست باز تکیه نکنید: از یک پنجره مستقل و بدون گزینه قدیمی اتصال جدید را آزمایش کنید. اگر شکست خورد، خروجی sshd -t و گزارش سرویس را بخوانید و در صورت نیاز از کنسول تنظیم قبلی را برگردانید.۴. اثر انگشت کلید جدید را مستقل تأیید کنید
روی کنسول مطمئن خود سرور، برای کلید عمومی نمونه اجرا کنید:
کد / دستورsudo ssh-keygen -lf /etc/ssh/ssh_host_ed25519_key.pub
اثر انگشت نمایش‌داده‌شده را از طریق کانال مطمئن با مقداری که کلاینت هنگام اولین اتصال نشان می‌دهد مقایسه کنید. دریافت کلید با
ssh-keyscan به‌تنهایی هویت سرور را ثابت نمی‌کند؛ پاسخ شبکه ممکن است متعلق به مقصد اشتباه باشد. اگر هشدار تغییر کلید قبلی دیدید، قبل از پذیرفتن یا حذف آن علت تغییر را با مدیر سرور و اثر انگشت معتبر تطبیق دهید. فایل کامل known_hosts را پاک نکنید.۵. اگر سرور قدیمی فعلاً قابل ارتقا نیست
برای دسترسی ضروری و کوتاه‌مدت به سروری که پس از تأیید هویت واقعاً فقط
کد / دستورssh-rsa پیشنهاد می‌کند، OpenSSH امکان افزودن همان روش را به یک اتصال می‌دهد:ssh -oHostKeyAlgorithms=+ssh-rsa admin@example.com
علامت
+ آن را به فهرست کلاینت اضافه می‌کند، نه اینکه همه گزینه‌های دیگر را جایگزین کند. این روش از الگوریتم قدیمی‌تر استفاده می‌کند؛ فقط برای مقصد و مدت ضروری به کار ببرید، هویت میزبان را مستقل تأیید کنید و برنامه ارتقای سرور را عقب نیندازید. اگر سیاست سیستم یا نسخه کلاینت استفاده از آن را منع کند، این دستور هم ممکن است کار نکند.اگر بعد از رفع خطای میزبان، مرحله ورود با کلید کاربر شکست خورد، آن خطا را جداگانه بررسی کنید. گزینه
PubkeyAcceptedAlgorithms مربوط به مرحله دیگری است و افزودن آن به‌صورت پیش‌فرض برای خطای host key لازم نیست. به همین ترتیب StrictHostKeyChecking=no یا حذف کل فایل کلیدهای شناخته‌شده مشکل مذاکره الگوریتم را درمان نمی‌کند.۶. نتیجه را بدون استثنای قدیمی بررسی کنید
پس از اصلاح سرور، از یک نشست تازه بدون
کد / دستورHostKeyAlgorithms=+ssh-rsa وصل شوید:ssh -vv admin@example.com
در گزارش، الگوریتم میزبان توافق‌شده را ببینید و مطمئن شوید هشدار هویت حل شده و ورود و کار معمول شما موفق است. اگر هنوز فقط روش قدیمی پیشنهاد می‌شود، بررسی کنید به IP، پورت و سرویس درست وصل می‌شوید و تنظیم جدید واقعاً اعمال شده است. برای تأخیر پس از برقراری اتصال نیز راهنمای کندی ورود SSH مسیر تشخیص جداگانه‌ای ارائه می‌کند.
اشتراک‌گذاری:
لینکدینتلگرامایکس
مقاله قبلی
مقاله بعدی
دیدگاه‌ها (۰)
دیدگاه‌های تاییدشده و پاسخ‌های تیم نت‌آرام