عیب یابی و رفع خطای Permission Denied publickey در Linux SSH

تسلط بر امنیت SSH عیب یابی و رفع خطای Permission Denied publickey

پروتکل SSH به عنوان ستون فقرات مدیریت سرورهای مدرن عمل می کند. این پروتکل به مهندسان اجازه می دهد تا زیرساخت ها را در سراسر جهان با تونل های رمزگذاری شده مدیریت کنند که محرمانگی و یکپارچگی را تضمین می کند. با این حال، حتی با تجربه ترین متخصصان DevOps نیز گهگاه با خطای ترسناک Permission Denied publickey مواجه می شوند. این پیام به عنوان یک نگهبان عمل می کند، درهای دسترسی به سرور ریموت شما را به روی شما می بندد و اغلب باعث ناامیدی قابل توجهی در طول پنجره های استقرار بحران یا کارهای تعمیر و نگهداری اضطراری می شود. درک چرایی وقوع این امر نیازمند بررسی عمیق فرآیند هندشیک، مجوزهای فایل سیستم حاکم بر دایرکتوری home و تفاوت های ظریف پیکربندی در سمت کلاینت و سرور است.

برای رفع این خطا، ابتدا باید درک کنید که چگونه SSH اعتماد را برقرار می کند. هنگامی که یک اتصال را آغاز می کنید، کلاینت شما یک public key را به سرور ریموت ارائه می دهد. سرور این کلید را با لیست هویت های مجاز خود که معمولاً در فایلی به نام authorized_keys در دایرکتوری home کاربر قرار دارد، بررسی می کند. اگر سرور نتواند تأیید کند که کلید ارائه شده با کلید ثبت شده مطابقت دارد، یا اگر تنظیمات پیکربندی برای فرآیند احراز هویت را غیرقابل قبول بداند، اتصال را قطع می کند. خطای Permission Denied publickey به طور خاص نشان می دهد که سرور تمام روش های احراز هویت ارائه شده را رد کرده است، یا اینکه به دلیل سیاست های امنیتی محدودکننده اصلاً به مرحله احراز هویت نمی رسد.

شایع ترین مقصر پشت این خطا، مجوزهای نادرست فایل سیستم روی سرور ریموت است. SSH به خاطر امنیت سختگیرانه خود معروف است. اگر دایرکتوری home شما، دایرکتوری ssh. یا خود فایل authorized_keys دارای مجوزهایی باشد که بیش از حد باز هستند، دیمون SSH از خواندن آنها خودداری می کند. این یک مکانیسم دفاعی عمدی است که برای جلوگیری از دستکاری کاربران غیرمجاز با فایل های هویت شما طراحی شده است.

در یک سیستم لینوکس استاندارد، دایرکتوری home شما باید فقط توسط خود شما قابل نوشتن باشد. پوشه ssh. باید به حالت 700 محدود شود، که دسترسی های خواندن، نوشتن و اجرای انحصاری را به مالک اعطا می کند. علاوه بر این، فایل authorized_keys باید روی حالت 600 تنظیم شود. اگر این فایل ها قابل نوشتن توسط گروه یا قابل خواندن توسط عموم باشند، دیمون سرور فرض می کند که پیکربندی ناامن است و عملاً کلیدهای شما را نادیده می گیرد. هنگامی که خطای publickey را مشاهده می کنید، اولین قدم همیشه باید بررسی این مجوزها باشد. شما می توانید با ورود به سیستم از طریق یک اتصال کنسول یا یک رابط ریکاوری ارائه شده توسط ارائه‌دهنده هاستینگ خود، مانند یک کنسول VNC یا یک سیستم مدیریت out-of-band مانند iLO یا IPMI، آنها را بازرسی کنید.

قبل از شروع تغییر تنظیمات، باید دقیقاً ببینید در طول تلاش برای اتصال چه اتفاقی می‌افتد. ابزار SSH یک ابزار تشخیصی فوق‌العاده قدرتمند به نام حالت verbose را فراهم می‌کند. با افزودن پرچم v- به دستور خود، می‌توانید لایه‌های فرآیند احراز هویت را کنار بزنید. استفاده از دستور ssh -v user@host هر مرحله از هندشیک، از تبادل کلید تا نقطه دقیقی که سرور اتصال را می‌بندد، خروجی می‌دهد.

هنگامی که این دستور را اجرا می کنید، به دقت لیست هویت های ارائه شده را زیر نظر داشته باشید. آیا کلاینت واقعاً private key شما را از روی سیستم لوکال شما بارگذاری می کند؟ اگر خروجی نشان دهد که در حال امتحان کردن هر کلید در اگنت شما است اما هیچ تطابقی پیدا نمی کند، ممکن است مشکل به جای سرور، روی سیستم لوکال شما باشد. برعکس، اگر سرور صراحتاً اعلام کند که به دلیل تنظیمات محدودکننده، از احراز هویت با public key صرف نظر می کند، می دانید که مشکل در سمت سرور است. حالت verbose یک حدس کور را به یک تحقیق پزشکی قانونی ساختاریافته تبدیل می کند.

گاهی اوقات مشکل خود فایل ها نیستند، بلکه قوانینی است که نحوه مدیریت آنها توسط سرور را دیکته می کنند. فایل پیکربندی دیمون SSH که در مسیر /etc/ssh/sshd_config قرار دارد، شامل دایرکتیوهایی است که رفتار احراز هویت را دیکته می کنند. یک نقطه شکست رایج زمانی رخ می دهد که دایرکتیو PubkeyAuthentication غیرفعال باشد. اگر این روی no تنظیم شود، سرور بدون توجه به اینکه مجوزهای شما چقدر عالی هستند، تمام تلاش‌های public key را نادیده می‌گیرد.

یک مانع بالقوه دیگر مربوط به دایرکتیو AuthorizedKeysFile است. اگر کلیدهای خود را به یک مکان غیر استاندارد منتقل کرده اید یا اگر مسیر به اشتباه پیکربندی شده باشد، سرور آنها را در مکان اشتباهی جستجو خواهد کرد. همیشه مطمئن شوید که مسیر به مکان صحیح نسبت به دایرکتوری home کاربر اشاره دارد. پس از ایجاد هرگونه تغییر در این فایل، باید با استفاده از دستور systemctl restart sshd سرویس را مجدداً راه اندازی کنید. با این حال، مراقب باشید که جلسه موجود خود را قبل از تأیید کارکرد تنظیمات جدید ببندید، زیرا در صورت وجود خطای نحو در پیکربندی، ممکن است خود را کاملاً قفل کنید.

سیستم لوکال شما به عنوان خط اول دفاعی در زنجیره احراز هویت عمل می کند. اگر چندین کلید برای سرورهای مختلف دارید، برای اگنت SSH آسان است که ردیابی کند که ابتدا کدام کلید را ارائه دهد. هنگامی که متصل می شوید، کلاینت در میان کلیدها چرخش می کند تا زمانی که سرور یکی را بپذیرد یا لیست تمام شود. اگر اگنت لوکال شما private key صحیح را نگه ندارد، یا اگر کلیدهای زیادی را بارگذاری کرده باشید، ممکن است سرور قبل از رسیدن به کلید مناسب، به حدکثر محدودیت تلاش های احراز هویت خود برسد.

شما می توانید کلیدهای لوکال خود را با استفاده از دستور ssh-add مدیریت کنید. اگر مشکوک هستید که محیط لوکال شما منبع مشکل است، اگنت فعلی خود را با دستور ssh-add -D پاک کنید و سپس به صورت دستی کلید خاص خود را با دستور ssh-add path/to/your/private/key اضافه کنید. این کار اگنت را مجبور می کند که کلید شما را در اولویت قرار دهد. این امر به ویژه هنگام کار با تنظیمات زیرساخت بزرگ که ممکن است ده ها کلید برای محیط های ابری مختلف داشته باشید، بسیار مرتبط است. تمیز نگه داشتن کلیدهای لوکال یک عادت حیاتی برای هر مهندس DevOps است.

در حالی که خطای Permission Denied معمولاً به مسائل احراز هویت اشاره دارد، گاهی اوقات می تواند با شکست تأیید اعتبار هاست کی اشتباه گرفته شود. اگر سرور خود را دوباره نصب کرده باشید یا آدرس IP آن را تغییر داده باشید، فایل known_hosts لوکال شما حاوی یک رکورد قدیمی خواهد بود. سرور هویت جدیدی را ارائه می دهد که با امضای قدیمی مطابقت ندارد، و کلاینت شما به حق این را به عنوان یک نقض امنیتی بالقوه می بیند.

در حالی که این امر معمولاً منجر به هشدار در مورد حملات احتمالی man-in-the-middle می شود، اگر کلاینت خود را به گونه ای پیکربندی کرده باشید که هاست های ناشناخته را به شدت رد کند، گاهی اوقات می تواند به صورت شکست ورود به سیستم خود را نشان دهد. برای رفع این مشکل، می توانید خط مشکل ساز را از فایل ~/.ssh/known_hosts لوکال خود حذف کنید. از دستور ssh-keygen -f “/home/youruser/.ssh/known_hosts” -R “remote_server_ip” برای حذف ایمن امضای قدیمی استفاده کنید. هنگامی که رکورد از بین رفت، تلاش بعدی از شما می خواهد که اثر انگشت جدید را بپذیرید و اتصال مورد اعتماد را بازیابی کنید.

در محیط های سازمانی پیچیده، سیاست امنیتی معروف به SELinux می تواند دسترسی به دایرکتوری ssh. را مسدود کند حتی اگر مجوزهای فایل کاملاً درست به نظر برسند. SELinux کنترل دسترسی اجباری را اعمال می کند و برای تعریف کارهایی که فرآیندها می توانند با فایل های خاص انجام دهند، به زمینه های امنیتی متکی است. اگر دایرکتوری ssh. شما دارای زمینه نادرست باشد، دسترسی دیمون SSH برای خواندن فایل ها رد می شود و خطای publickey را ایجاد می کند.

شما می توانید زمینه امنیتی فایل های خود را با استفاده از دستور ls -Z بررسی کنید. اگر متوجه شدید که زمینه ها به طور نامناسبی تنظیم شده اند، می توانید با استفاده از دستور restorecon آنها را بازیابی کنید. به طور خاص، اجرای دستور restorecon -R -v ~/.ssh زمینه های امنیتی را برای دایرکتوری پیکربندی SSH شما به صورت بازگشتی به مقادیر پیش فرض سیستم بازنشانی می کند. این یک مرحله عیب یابی پیشرفته است که اغلب نادیده گرفته می شود اما در توزیع های لینوکس به شدت قفل شده مانند RHEL، CentOS یا AlmaLinux بسیار حیاتی است.

برخی از سرورها به گونه ای پیکربندی شده اند که به احراز هویت چند عاملی نیاز دارند، یا ممکن است ترتیب خاصی از احراز هویت را مطالبه کنند. اگر سرور شما به یک پسورد و یک کلید نیاز دارد، یا اگر به پاسخ چالش نیاز دارد، اگر پیکربندی صراحتاً برای اجازه دادن به public key به عنوان یک روش پشتیبان تنظیم نشده باشد، احراز هویت مبتنی بر کلید استاندارد ممکن است با شکست مواجه شود. شما می توانید با استفاده از پرچم -o گزینه های مختلف را از خط فرمان آزمایش کنید.

برای مثال، می‌توانید کلاینت را مجبور کنید که فقط از فایل هویتی که مشخص می‌کنید با اجرای دستور ssh -i /path/to/key -o IdentitiesOnly=yes user@host استفاده کند. این کار به طور کامل از اگنت SSH عبور می‌کند و به کلاینت می‌گوید که فقط از هویت ارائه‌شده استفاده کند. اگر این کار با موفقیت انجام شود، تأیید می‌کند که کلیدها و مجوزهای شما صحیح هستند، اما پیکربندی اگنت SSH لوکال شما باعث ایجاد تداخل شده است. این یک روش بسیار قدرتمند برای ایزوله کردن متغیرها هنگام عیب‌یابی است.

در DevOps مدرن، ما به ندرت سرورها را به صورت دستی پیکربندی می کنیم. ما از ابزارهایی مانند Ansible، Terraform یا Chef برای مدیریت هزاران گره استفاده می کنیم. یک تایپ اشتباه در یک اسکریپت اتوماسیون می تواند یک پیکربندی نادرست SSH را در کل ناوگان شما منتشر کند. اگر نسخه جدیدی از زیرساخت خود را مستقر کرده اید و ناگهان متوجه شدید که قادر به ورود به سیستم نیستید، مقصر احتمالاً کد اتوماسیون است.

اسکریپت های پروویژنینگ خود را برای خطوطی که دایرکتوری های home کاربر یا فایل های پیکربندی SSH را تغییر می دهند، بررسی کنید. معمولاً هنگام تلاش برای اتوماسیون دسترسی برای حساب های سرویس، به طور تصادفی مجوزهایی اعمال می شود که بیش از حد باز هستند. اگر از Ansible استفاده می کنید، group_vars و فایل های role خود را برای هر وظیفه ای که فایل های authorized_keys را دستکاری می کند، بررسی کنید. ابزارهای خودکار قدرتمند هستند، اما اگر منطق نقص داشته باشد، می توانند شما را با کارایی باورنکردنی قفل کنند.

موثرترین راه برای بازیابی از خطای Permission Denied این است که مسیری داشته باشید که اصلاً به SSH متکی نباشد. هرگز منحصراً برای زیرساخت تولید بحران به دسترسی ریموت SSH اعتماد نکنید. همیشه مطمئن شوید که به یک کنسول یا ترمینال ریکاوری ارائه شده توسط ارائه‌دهنده ابری یا ارائه‌دهنده سخت‌افزار خود دسترسی دارید.

این ابزارها به شما اجازه می دهند تا به طور کامل از دیمون SSH عبور کنید. هنگامی که به کنسول فیزیکی یا مجازی وارد شدید، به عنوان یک کاربر لوکال با سیستم تعامل دارید. این به شما اجازه می دهد تا لاگ های سیستم را در مسیر /var/log/auth.log یا /var/log/secure بررسی کنید، که دلیل خاصی را که دیمون SSH اتصال شما را رد کرده است، ارائه می دهد. لاگ ها اغلب حاوی پیام های صریحی هستند که دقیقاً بیان می کنند کدام فایل مجوزهای نادرست داشته است یا چرا یک کلید خاص رد شده است. بدون دسترسی به لاگ، عملاً کورکورانه پرواز می کنید.

هنگامی که چندین مهندس دسترسی به یک سرور را به اشتراک می‌گذارند، فایل authorized_keys می‌تواند به آشفتگی از ورودی‌های متناقض تبدیل شود. اگر یکی از همکاران سازمان را ترک کند یا اگر کلید آنها منقضی شود، مدیریت دسترسی آنها به یک بار تعمیر و نگهداری تبدیل می شود. استفاده از یک سیستم مدیریت کلید SSH متمرکز یا حتی یک اسکریپت ساده برای همگام سازی کلیدها از یک مخزن مرکزی بسیار توصیه می شود.

با این حال، توجه داشته باشید که این سیستم ها نیز ممکن است خراب شوند. اگر یک کار همگام سازی با شکست مواجه شود، ممکن است کلیدهای شما را پاک کند یا فایل authorized_keys را خراب کند. همیشه یک نسخه پشتیبان از کلید مدیریتی خود در یک مکان امن و آفلاین نگهداری کنید. داشتن یک در پشتی، مانند ورود ریشه که فقط از یک هاست پرش خاص مجاز است یا یک هویت ثانویه با اعتبارنامه های سخت کد شده در مخزن لوکال، می تواند کسب و کار شما را از خرابی قابل توجه نجات دهد.

هرگز تنظیمات SSH را روی یک سرور زنده بدون بررسی نحو (syntax) تغییر ندهید. دستور sshd یک پرچم مفید -t دارد که فایل پیکربندی شما را برای خطاهای نحو قبل از اعمال آنها تست می کند. اجرای دستور sshd -t هرگونه مسئله ای را در فایل /etc/ssh/sshd_config شما گزارش می کند و اطمینان حاصل می کند که سرویس را در وضعیتی که از شروع به کار خودداری می کند، رها نمی کنید.

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

در حالی که وسوسه انگیز است که مجوزها را برای رفع خطا شل کنید، همیشه به خاطر داشته باشید که امنیت سرور خود را کاهش می دهید. هرگز دایرکتوری ssh. خود را chmod 777 نکنید. مقدار استاندارد 700 برای دایرکتوری و 600 برای فایل به دلیلی وجود دارد. اگر سرور شما در معرض اینترنت عمومی قرار دارد، یک دایرکتوری SSH با پیکربندی نادرست دعوتی آشکار برای بازیگران مخرب است تا برای ورود غیرمجاز تلاش کنند.

هنگامی که دسترسی public key خود را تأیید کردید، غیرفعال کردن کامل احراز هویت با پسورد را در نظر بگیرید. این کار سطح حمله در برابر تلاش های brute-force را به شدت کاهش می دهد. همچنین، استفاده از روش های احراز هویت جایگزین مانند کلیدهای امنیتی FIDO/U2F یا گواهینامه ها را در نظر بگیرید. این روش ها سطح بالاتری از امنیت را فراهم می کنند و خطر سرقت private key از سیستم لوکال شما را از بین می برند.

گاهی اوقات خود سرویس SSH وارد وضعیتی می شود که دیگر به درخواست های احراز هویت به درستی پاسخ نمی دهد. یک سرویس systemd ممکن است در حال اجرا باشد، اما فرآیند زیرین ممکن است معلق شده باشد. راه اندازی مجدد سرویس یک مرحله عیب یابی رایج است، اما اگر مشکل همچنان ادامه داشت، وضعیت سرویس را با استفاده از دستور systemctl status sshd بررسی کنید.

اگر پیام های خطای مربوط به قفل کردن فایل یا حافظه اشتراکی را مشاهده کردید، ممکن است با یک مشکل عمیق تر سیستم عامل روبرو باشید. گهگاه، به روز رسانی سیستم عامل یا خود بسته SSH می تواند باگ های زیرین را حل کند. همیشه نرم افزار سرور خود را به روز نگه دارید، زیرا آسیب پذیری های پیاده سازی SSH مکرراً پچ می شوند. یک دیمون SSH منسوخ شده فقط یک خطر نیست، بلکه یک مسئولیت است.

خطای Permission Denied publickey یک آیین گذار برای هر مدیر سیستم است. این یک مانع ناامیدکننده است، اما همچنین یک درس بنیادی در اهمیت امنیت، مجوزها و انضباط پیکربندی است. با تسلط بر ابزارهای تشخیصی مانند حالت verbose، درک تفاوت های ظریف مجوزهای فایل سیستم، و حفظ مسیرهای بازیابی out-of-band قوی، می توانید این خطا را از یک شکست فاجعه بار به یک رویداد معمولی قابل مدیریت تبدیل کنید.

همیشه با مشکل به طور روشمند برخورد کنید. قبل از پرداختن به مسائل پیچیده تری مانند زمینه های امنیتی یا پیکربندی های سرویس، با ساده ترین توضیحات، مانند مجوزهای فایل و وضعیت اگنت لوکال شروع کنید. اصلاحات خود را مستند کنید و اسکریپت های اتوماسیون خود را اصلاح کنید تا مطمئن شوید که دو بار با همان مشکل مواجه نمی شوید. قابلیت اطمینان بر روی ویرانه های خرابی های گذشته ساخته می شود، و با یک رویکرد سیستماتیک، می توانید اطمینان حاصل کنید که زیرساخت شما در مواجهه با سرسخت ترین خطاهای احراز هویت نیز امن، قابل دسترس و انعطاف پذیر باقی می ماند.