وقتی در محیط لینوکس با دستور SSH قصد دارید به یک سرور از راه دور متصل شوید، گاهی با پیامی مثل زیر روبه‌رو می‌شوید:
Host key verification failed.
این خطا به‌معنای آن است که کلید عمومی (public key) سروری که به آن متصل می‌شوید، با کلیدی که قبلاً در سیستم‌تان ذخیره شده، مغایرت دارد یا هنوز تأیید نشده است. این موضوع می‌تواند هم به دلایل امنیتی باشد (مانند تغییر واقعی کلید در سمت سرور)، یا ناشی از خطای تنظیمات یا انتقال سرور. در هر صورت، تا زمانی که این مشکل را حل نکنید، اتصال SSH انجام نمی‌شود.
مرور مقاله در یک نگاه:
وقتی از سرورهای لینوکسی برای اجرای ربات‌های معاملاتی خودکار یا انجام تریدهای الگوریتمی استفاده می‌کنی، احتمالاً با خطای “Host key verification failed” روبرو می‌شی. این خطا معمولاً زمانی اتفاق می‌افته که تلاش می‌کنی به یک سرور SSH متصل بشی اما سیستم قادر به شناسایی یا تأیید کلید عمومی اون سرور نیست. دلیل این خطا می‌تونه به‌روزرسانی یا تغییر کلیدهای SSH سرور باشه، یا حتی ممکنه فایل
known_hostsکه محل ذخیره‌سازی کلیدهای شناخته‌شده است، دچار مشکل بشه.در این مواقع سیستم هشدار می‌ده که ممکنه با یک سرور تقلبی روبرو باشی، و این هشدار رو می‌شه به‌عنوان یک مکانیزم امنیتی برای جلوگیری از حملات man-in-the-middle در نظر گرفت. برای مثال اگر یک تریدر بخواد به سرور یک بروکر معتبر مثل IC Markets یا FXTM متصل بشه، این خطا می‌تونه مانع از اتصال و اجرای استراتژی‌های خودکار بشه. رفع این خطا نیاز به بررسی و تنظیماتی دقیق داره که در اینجا به توضیح اون‌ها می‌پردازیم.
برای رفع این خطا اولین کاری که باید انجام بدی، بررسی محتوای فایل
known_hostsهست. این فایل معمولاً در دایرکتوری~/.ssh/قرار داره و شامل کلیدهای عمومی سرورهایی هست که قبلاً به اون‌ها متصل شدی. وقتی این فایل مشکلی پیدا می‌کنه یا تغییرات غیرمنتظره‌ای در سرور ایجاد می‌شه، باید اون رو پاک‌سازی یا به‌روزرسانی کنی. برای حل این مشکل ابتدا باید کلید مربوط به سرور موردنظر رو از این فایل حذف کنی. برای این کار می‌تونی از دستورssh-keygen -R <hostname>استفاده کنی که به‌طور خودکار کلیدهای قدیمی رو حذف می‌کنه. بعد از این مرحله وقتی دوباره به سرور متصل می‌شی، از تو خواسته می‌شه که کلید جدید رو تأیید کنی.نکته‌ای که باید در نظر بگیری اینه که حتماً باید از اعتبار سرور مطمئن بشی، زیرا در صورت وارد کردن کلید نادرست ممکنه امنیت ارتباطت به خطر بیفته. برای مثال، در صورت تغییر کلید یک VPS که برای معاملات فارکس استفاده می‌کنی، باید مطمئن بشی که تغییرات از سوی پشتیبانی معتبر سرور اعمال شده و نه یک حمله امنیتی. در مواقعی که این خطا تکرار می‌شه، بهتره که گزینه‌هایی مثل
StrictHostKeyChecking yesرو در فایلssh_configفعال کنی تا از اتصال به سرورهای ناشناخته جلوگیری بشه و امنیت بیشتر تضمین بشه. با این روش می‌تونی از بروز مشکلات مشابه در آینده جلوگیری کنی و مطمئن باشی که همه‌چیز به‌طور امن در جریان است.
فهرست مطالب
دلیل اصلی خطا چیست و چرا لینوکس جلوی اتصال را می‌گیرد؟
زمانی که شما برای اولین بار به یک سرور SSH می‌زنید، لینوکس کلید عمومی آن سرور را در فایل ~/.ssh/known_hosts ذخیره می‌کند. این یک اقدام امنیتی مهم برای جلوگیری از حملات “man-in-the-middle” است. اگر در اتصال‌های بعدی، کلید جدیدی ارائه شود که با کلید قبلی همخوانی ندارد، لینوکس این خطا را نمایش می‌دهد تا مطمئن شود کسی در میان مسیر داده‌ها را دستکاری نکرده است.
درواقع این مکانیزم، مانند اثر انگشت برای تأیید هویت سرور عمل می‌کند. تغییر کلید معمولاً دلایلی مثل نصب مجدد سیستم‌عامل، تغییر آدرس IP، یا انتقال به سرور جدید دارد. اما ممکن است به دلایل غیرعمدی مثل کپی اشتباه فایل‌های SSH نیز رخ دهد.
چگونه خطا را گام‌به‌گام رفع کنیم؟
شناسایی مسیر فایل known_hosts
ابتدا مسیر فایل known_hosts که لیست سرورهای تأییدشده را نگه می‌دارد بررسی کنید. معمولاً این فایل در مسیر زیر قرار دارد:
~/.ssh/known_hosts
در این فایل، برای هر سروری که به آن متصل شده‌اید، یک خط شامل IP یا دامنه و کلید عمومی ذخیره شده است.
حذف کلید نادرست یا قدیمی
اگر می‌دانید که سرور موردنظر تغییر کرده و خطری وجود ندارد، می‌توانید کلید ذخیره‌شده قبلی را حذف کنید. برای این کار دو روش وجود دارد:
حذف دستی:
فایل را با ویرایشگر باز کنید و خطی که مربوط به آدرس IP یا دامنه موردنظر است حذف کنید:
nano ~/.ssh/known_hosts
با استفاده از جستجو (CTRL + W) آدرس IP سرور را پیدا و آن خط را حذف کنید.
استفاده از دستور SSH-Keygen برای حذف کلید:
ssh-keygen -R [hostname or IP]
مثلاً:
ssh-keygen -R 192.168.1.100
این دستور به‌صورت خودکار کلید مربوطه را حذف می‌کند.
اتصال مجدد و تأیید دستی کلید جدید
پس از حذف کلید قبلی، دوباره تلاش کنید به سرور متصل شوید:
ssh user@hostname
اگر اتصال برقرار باشد، پیامی مانند زیر ظاهر می‌شود:
The authenticity of host ‘192.168.1.100’ can’t be established.
ECDSA key fingerprint is SHA256:…
Are you sure you want to continue connecting (yes/no)?
در صورت اطمینان از صحت سرور، گزینه yes را وارد کنید تا کلید جدید ذخیره و اتصال برقرار شود.
چطور تشخیص دهیم خطا امنیتی است یا طبیعی؟
همیشه نباید به‌سادگی کلید جدید را بپذیرید. اگر تغییر سرور یا تنظیمات از سمت شما نبوده، قبل از قبول کلید جدید، از مسئول سرور یا تیم IT تأییدیه بگیرید. مخصوصاً در محیط‌های تولیدی (Production)، تأیید صحت کلید جدید حیاتی است. چون حمله‌های مرد میانی (MITM) دقیقاً از همین رخنه سوءاستفاده می‌کنند.
سرور قدرتمند = اتصال بی‌دردسر. همین حالا سرور HP مناسب کارت رو از سرورتیک تهیه کن و دغدغه SSH نداشته باش!
جدول مقایسه‌ای از خطاهای رایج در اتصال SSH و روش‌های حل آن
|
خطا |
دلیل اصلی |
راه‌حل پیشنهادی |
|
Host key verification failed |
مغایرت کلید فعلی با کلید ذخیره‌شده قبلی |
حذف خط مربوطه از known_hosts |
|
Permission denied (publickey) |
عدم تطابق کلید خصوصی با کلید مجاز در سرور | بررسی و آپلود صحیح کلید در authorized_keys |
|
Connection refused |
سرور SSH فعال نیست یا پورت بسته است |
بررسی پورت و سرویس sshd |
| Connection timed out | ارتباط شبکه‌ای قطع است | بررسی فایروال، IP و پورت |
بررسی دقیق ساختار فایل known_hosts و نحوه رمزنگاری کلیدها
وقتی با سرورهای لینوکسی یا محیط‌هایی مثل ترمینال SSH کار می‌کنیم، فایل known_hosts یکی از اجزای کلیدی در بحث امنیت ارتباطات محسوب می‌شه. این فایل به‌طور خلاصه فهرستی از کلیدهای عمومی سرورهایی هست که قبلاً به اون‌ها متصل شدیم، تا در دفعات بعدی مطمئن باشیم داریم با همون سرور ارتباط برقرار می‌کنیم، نه یک سرور جعلی یا مخرب. تصور کن که داری به سرور یک بروکر معتبر مثل FXTM یا IC Markets متصل می‌شی؛
اگه فایل known_hosts کلید سرور رو ذخیره کرده باشه، سیستم شما در اتصال بعدی بررسی می‌کنه که کلید عمومی دریافت‌شده با قبلی یکی هست یا نه. اگه یکی نباشه، هشدار می‌ده که احتمال داره با یه سرور غیرقابل اعتماد روبرو باشید. این یعنی دقیقا مثل زمانی که توی بازار فارکس با یه پلتفرم ناشناس روبرو می‌شی و سریع حس می‌کنی باید بیشتر بررسی‌اش کنی.
رمزنگاری کلیدها در این فایل به روش Base64 انجام می‌شه، اما نکته جالب اینجاست که خود کلید رمزنگاری‌شده نیست، بلکه به‌شکل متنی قابل مشاهده است. برای مثال، وقتی به یک سرور SSH وصل می‌شی، کلید عمومی اون سرور به همراه آدرس و نوع رمزنگاری (مثل RSA یا ECDSA) در این فایل ذخیره می‌شه. حالا اگه این فایل پاک بشه یا ویرایش بشه، انگار تو برای اولین بار داری وارد اون سرور می‌شی و مجدداً باید تأییدش کنی.
توی پروژه‌هایی مثل ترید الگوریتمی که ارتباط با سرورهای مجازی یا VPSها مهمه، بررسی منظم این فایل و اطمینان از معتبر بودن کلیدها باعث می‌شه امنیت کار بالاتر بره و ریسک لو رفتن اطلاعات یا ورود به سرورهای تقلبی کاهش پیدا کنه. اگه تازه‌کار هستی یا داری برای اولین بار یه ربات تریدر رو روی یه سرور ریموت ران می‌کنی، حتما این فایل رو جدی بگیر چون اولین خط دفاعی در برابر حملات man-in-the-middle محسوب می‌شه.
نحوه استفاده از ssh-keyscan برای استخراج کلید سرور بدون اتصال
این دستور یه ابزار امنیتی عالیه که بدون نیاز به اتصال SSH، کلید فعلی سرور رو بهت نشون می‌ده. مثلاً:
ssh-keyscan example.com
این تیتر باعث می‌شه کاربر فرق بین تشخیص کلید واقعی و کلید مخرب رو بهتر متوجه بشه.
بررسی تأثیر این خطا در اسکریپت‌های خودکار و CI/CD
وقتی در مسیر راه‌اندازی سیستم‌های خودکار یا پیاده‌سازی فرآیندهای CI/CD هستیم، مخصوصا تو حوزه‌هایی مثل معامله‌گری الگوریتمی یا اجرای خودکار استراتژی‌های فارکس، یه خطای کوچک در ارتباط SSH می‌تونه باعث توقف کامل اجرای اسکریپت‌ها بشه. یکی از رایج‌ترین مشکلات، خطای مربوط به فایل known_hosts هست که معمولاً زمانی رخ می‌ده که کلید عمومی سرور تغییر کرده یا فایل به هر دلیلی دچار اختلال شده باشه.
حالا تصور کن اسکریپتی که وظیفه داره اطلاعات بازار از سرور اصلی دیتای ترید یا VPSی که روی اون ربات اجرا می‌شه رو دریافت کنه، به دلیل همین خطای ظاهراً ساده متوقف بشه. اگر در زمان‌های حساس مثل اعلام خبرهای اقتصادی از منابعی مثل ForexFactory این اتفاق بیفته، ممکنه بخشی از سود از دست بره یا حتی پوزیشن‌های اشتباه باز بشه.
در پروژه‌های مبتنی بر CI/CD، مخصوصاً اگه از ابزارهایی مثل GitLab CI، Jenkins یا حتی GitHub Actions استفاده می‌کنی، نبود کنترل مناسب روی کلیدهای SSH و عدم مدیریت فایل known_hosts باعث می‌شه که اجرای خودکار Deployment با خطا روبرو بشه.
مثلا فرض کن داری یه بات معامله‌گر رو که با زبان پایتون نوشته شده به‌صورت خودکار روی یه سرور جدید دیپلوی می‌کنی، اما چون فایل known_hosts اطلاعات اون سرور رو نداره یا قبلاً تغییر کرده، سیستم جلوی اتصال رو می‌گیره. در این حالت نه‌تنها باید اسکریپت‌ها رو به‌روز کنی، بلکه باید مدیریت کلیدها رو هم به شکل امن و حرفه‌ای انجام بدی.
برای همین پیشنهاد می‌شه همیشه در کنار تست‌های امنیتی، مکانیزمی برای مدیریت این فایل در فرآیندهای CI/CD داشته باشی تا اختلالی در اجرای ربات‌های معاملاتی یا استقرار خودکار پروژه‌ها به وجود نیاد.
تنظیمات امن برای SSH در فایل ssh_config برای جلوگیری از خطاهای مشابه
وقتی صحبت از امنیت در ارتباط‌های سرور به میان میاد، مخصوصاً در شرایطی که از ربات‌های تریدر استفاده می‌کنی یا استراتژی‌های معاملاتی خودکار روی VPS اجرا می‌شن، فایل ssh_config می‌تونه نقشی کلیدی تو جلوگیری از خطاهای ناگهانی و حملات احتمالی داشته باشه.
خیلی از معامله‌گرها فقط به اتصال فکر می‌کنن، اما پایداری و امنیت این اتصال تو بلندمدت اهمیت خیلی بیشتری داره. یکی از تنظیماتی که توصیه می‌شه فعال بشه، تعیین دقیق الگوریتم‌های رمزنگاری و محدود کردن نسخه‌های SSH هست. مثلاً با مشخص کردن گزینه‌هایی مثل StrictHostKeyChecking yes باعث می‌شی که سیستم فقط زمانی به سرور وصل بشه که مطمئن باشه کلید قبلی هیچ تغییری نکرده. حالا فرض کن سرور یه بروکر معتبر رو توی فایل known_hosts ذخیره کرده باشی و روزی کلید اون تغییر کنه؛ اگه این گزینه فعال نباشه، ممکنه ارتباط با سرور جعلی هم برقرار بشه بدون اینکه بفهمی.
برای کاربرهایی که روی پروژه‌های CI/CD یا اجرای مداوم ربات‌های معاملاتی سرمایه‌گذاری کردن، تنظیمات دقیق توی ssh_config یه جور بیمه امنیتی محسوب می‌شه. علاوه بر اینکه جلوی خیلی از خطاهای وقت‌گیر مثل mismatch کلید یا خطای “host verification failed” رو می‌گیره، می‌تونه به فرآیند خودکارسازی هم سرعت و پایداری بده. مثلاً با اضافه کردن پارامترهایی مثل UserKnownHostsFile می‌تونی مسیر خاصی برای ذخیره کلیدهای هر پروژه تعیین کنی، تا پروژه‌های مختلف تداخلی با هم نداشته باشن.
این موضوع به‌خصوص برای تریدرهایی که چند سرور یا حساب رو مدیریت می‌کنن اهمیت زیادی داره. برندهایی مثل DigitalOcean یا Contabo که اغلب برای میزبانی سرورهای معاملاتی استفاده می‌شن، خودشون هم پیشنهادهای امنیتی برای پیکربندی SSH ارائه می‌دن، اما شخصی‌سازی این فایل براساس نیاز معامله‌گر باعث می‌شه هم امنیت حفظ بشه، هم خطاهای پیش‌بینی‌نشده کمتر اتفاق بیفته.
راهکارهای سازمانی برای مدیریت کلیدهای سرورها در شبکه‌های بزرگ
در این تیتر می‌شه به ابزارهایی مثل Ansible, SaltStack, یا سیستم‌های مدیریتی مثل HashiCorp Vault برای توزیع و اعتبارسنجی کلیدها اشاره کرد. خیلی از شرکت‌ها برای جلوگیری از این خطاها سرورهای SSH داخلی خودشون رو به‌روز و متمرکز مدیریت می‌کنن.
سخن پایانی
خطای “Host key verification failed” یک مشکل رایج ولی کاملاً قابل‌کنترل در دنیای لینوکس و مدیریت سروره. برخلاف تصور اولیه، این پیام صرفاً یک ارور نیست، بلکه دیواره‌ی دفاعی مهمی در مقابل حملات سایبری و نفوذ از طریق تغییر مسیر اتصال SSH به‌شمار می‌ره. اگر بدون آگاهی، صرفاً کلید قبلی رو حذف کنیم و کلید جدید رو قبول کنیم، ممکنه امنیت سیستم‌هامون رو به‌خطر بندازیم.
مقاله‌ای که به این موضوع می‌پردازه باید هم جنبه امنیتی و هم جنبه کاربردی و فنی رو با هم در نظر بگیره. آموزش گام‌به‌گام، معرفی ابزارهای جانبی، مدیریت SSH در محیط‌های DevOps و تأکید بر تحلیل قبل از هر تصمیم، این محتوا رو برای همه‌ی سطوح از کاربر مفید می‌کنه.
سوالات متداول درباره خطای “Host key verification failed”
آیا می‌توان به‌صورت خودکار کلیدها را قبول کرد؟
بله، اما این روش فقط در محیط تست توصیه می‌شود. استفاده از پارامتر -o StrictHostKeyChecking=no در SSH می‌تواند کلید را به‌صورت خودکار ذخیره کند، اما امنیت را کاهش می‌دهد.
آیا حذف کلید قبلی باعث بروز مشکل در امنیت می‌شود؟
درصورتی‌که مطمئن باشید سرور همان سرور قبلی است یا از منبع رسمی تأیید گرفته‌اید، حذف کلید مشکلی ندارد. در غیر این‌صورت خطرناک است.
آیا می‌توان known_hosts را به‌کلی حذف کرد؟
از نظر فنی بله، اما به‌شدت توصیه نمی‌شود. این فایل سپر امنیتی شما در برابر حملات شبکه‌ای است.
چگونه می‌توان کلید فعلی سرور را با کلید واقعی مقایسه کرد؟
با اتصال به سرور از کنسول مستقیم یا استفاده از دستور ssh-keyscan می‌توانید کلید سرور را استخراج و با نسخه ذخیره‌شده مقایسه کنید.