وبلاگ نت‌آرامآموزش، تجربه و راهکارهای زیرساخت

رفع Permission denied (publickey) در اتصال SSH

بررسی نام کاربری، کلید خصوصی و مجوزهای authorized_keys برای حل خطای ورود SSH بدون غیرفعال کردن امنیت.

انتشار:
توسط تیم فنی نت‌آرام
۴ دقیقه زمان مطالعه
۰ دیدگاه
محتوای تخصصی، ساده و کاربردی
هماهنگ با هویت حرفه‌ای نت‌آرام
بازگشت به لیست مقالات
تصویر شاخص مقاله رفع Permission denied (publickey) در اتصال SSH در وبلاگ نت‌آرام
محتوای آموزشی وبلاگ نت‌آرام
پیام Permission denied (publickey) معمولاً یعنی ارتباط اولیه با سرویس SSH برقرار شده، ولی سرور هیچ‌کدام از کلیدهای پیشنهادی را برای ورود آن کاربر نپذیرفته است. این پیام با timeout فرق دارد. قبل از تغییر فایروال یا ساخت کلید تازه، نام کاربر و کلیدی را که واقعاً انتخاب می‌کنید بررسی کنید.

نام کاربری و کلید درست را انتخاب کنید

نام کاربری اولیه در سرویس‌ها متفاوت است. اطلاعات پنل ارائه‌دهنده را ببینید و از نامی که همان سرور مشخص کرده استفاده کنید. در دستور زیر، مسیر کلید، پورت، نام کاربر و آدرس صرفاً نمونه‌اند:
کد / دستورssh -i ~/.ssh/my_server_key -p 22 user@example.com
فایل بدون پسوند .pub معمولاً کلید خصوصی است و باید روی رایانه خودتان بماند. فایل .pub کلید عمومی است که می‌توان برای ثبت روی سرور استفاده کرد. کلید خصوصی و عبارت محافظ آن را برای پشتیبانی ارسال نکنید.
اگر چند کلید دارید و نمی‌دانید کدام فرستاده می‌شود، خروجی توضیحی اتصال را بخوانید:
کد / دستورssh -v -i ~/.ssh/my_server_key -o IdentitiesOnly=yes -p 22 user@example.com
در این دستور هم پورت 22 را با پورت واقعی سرور جایگزین کنید. گزینه IdentitiesOnly کمک می‌کند کلید مشخص‌شده به جای فهرست بزرگی از کلیدهای دیگر پیشنهاد شود؛ اگر در پیکربندی همان میزبان کلیدهای دیگری مشخص کرده‌اید، ممکن است آن‌ها نیز پیشنهاد شوند. جزئیات خروجی را قبل از اشتراک مرور کنید. پس از اصلاح، اتصال را فقط چند بار آزمایش کنید تا سیاست‌های امنیتی سرور به دلیل تلاش‌های ناموفق حساب شما را محدود نکنند.

کلید عمومی باید در حساب درست باشد

اگر کنسول امن سرور دارید، با روشی که ارائه‌دهنده پشتیبانی می‌کند وارد شوید. فایل ~/.ssh/authorized_keys همان کاربری را بررسی کنید که می‌خواهید با آن وصل شوید. هر کلید عمومی معمولاً یک خط کامل است؛ شکستن خط، جای‌گذاری ناقص یا ثبت کلید در حسابی دیگر می‌تواند باعث رد شدن آن شود.
برای دیدن اثر انگشت کلید عمومی رایانه خود از این دستور استفاده کنید:
کد / دستورssh-keygen -lf ~/.ssh/my_server_key.pub
اگر به فایل عمومی مربوط به همان کلید خصوصی دسترسی ندارید، ابتدا منشأ کلید را مشخص کنید. مقایسه اثر انگشت کلید عمومی ثبت‌شده و کلید شما به تشخیص جابه‌جایی کمک می‌کند. محتوای authorized_keys دیگران را تغییر ندهید و قبل از هر ویرایش نسخه پشتیبان آن را حفظ کنید.

کلید عمومی را روی حساب درست قرار دهید

اگر کنسول امن دارید، با همان حساب مقصد وارد شوید و مسیر ~/.ssh/authorized_keys را باز کنید. کلید عمومی فرد را به‌صورت یک خط کامل در انتهای فایل قرار دهید؛ کلیدهای قبلی را حذف نکنید و کلید خصوصی را به سرور نفرستید. مالکیت فایل باید متعلق به همان حساب باشد. سپس از رایانه کاربر با مسیر کلید خصوصی و پورت واقعی دوباره وصل شوید. اگر خطا ادامه داشت، همان دقیقه گزارش سرویس را بخوانید؛ پیام مالکیت یا دسترسی را برای اصلاح محدود همان فایل استفاده کنید، نه تغییر بازگشتی کل پوشه خانه.

مجوزها و گزارش SSH

روی لینوکس، دسترسی بیش از حد باز به پوشه کاربر یا فایل‌های SSH ممکن است باعث نادیده گرفتن کلید شود. از کنسول سرور مالکیت پوشه خانگی، .ssh و authorized_keys را با مستندات همان سیستم مقایسه کنید. معمولاً .ssh با مجوز 700 و فایل authorized_keys با 600 تنظیم می‌شود، اما ابتدا مالک و نام کاربر درست را مشخص کنید و دستور بازگشتی روی پوشه‌های دیگر اجرا نکنید.
گزارش سرویس SSH در همان ساعت معمولاً علت دقیق‌تری دارد. نام سرویس ممکن است ssh یا sshd باشد:
کد / دستورsudo journalctl -u ssh -n 50 --no-pager
اگر سرویس شما sshd نام دارد، همان نام را جایگزین کنید. گزارش می‌تواند اطلاعات حساس داشته باشد؛ فقط بخش لازم را در مسیر امن برای پشتیبانی بفرستید. روشن کردن ورود با رمز یا دسترسی root بدون بررسی سیاست امنیتی راه‌حل لازم برای این خطا نیست.
برچسب‌ها:
اشتراک‌گذاری:
لینکدینتلگرامایکس
مقاله قبلی
مقاله قبلی وجود ندارد.

دیدگاه‌ها (۰)

دیدگاه‌های تاییدشده و پاسخ‌های تیم نت‌آرام