خطای Permission denied (publickey) در SSH؛ علت‌ها و رفع قدم‌به‌قدم

این خطا دقیقاً چه می‌گوید؟

پیام کامل معمولاً این شکل است:

root@203.0.113.10: Permission denied (publickey).

اولین نکتهٔ مهم این است که این خطا مشکل شبکه نیست. اتصال به سرور برقرار شده، سرویس SSH پاسخ داده و مرحلهٔ احراز هویت شروع شده است؛ اما سرور هیچ‌کدام از کلیدهایی را که کلاینت شما ارائه کرده نپذیرفته است. عبارت داخل پرانتز روش‌های مجازی ورود را نشان می‌دهد؛ وقتی فقط publickey نوشته شده، یعنی ورود با رمز روی سرور غیرفعال است و تنها راه ورود، کلید درست است.

پس اگر خطای شما Connection timed out یا Connection refused است، مشکل جای دیگری است و باید مقالهٔ رفع خطای Connection timed out در SSH را ببینید. اما اگر دقیقاً همین پیام را می‌بینید، علت تقریباً همیشه یکی از موارد زیر است.

گام ۱: با حالت verbose ببینید چه اتفاقی می‌افتد

پیش از هر تغییری، دستور اتصال را با گزینهٔ -v اجرا کنید. خروجی نشان می‌دهد کلاینت کدام فایل‌های کلید را امتحان کرده و سرور به هرکدام چه پاسخی داده است:

ssh -v root@203.0.113.10

دنبال خطوطی مثل Offering public key و Trying private key بگردید. اگر کلیدی که انتظار داشتید اصلاً در فهرست نیست، کلاینت آن را نمی‌شناسد (گام ۲). اگر کلید ارسال شده اما پس از آن Authentications that can continue: publickey آمده، سرور کلید را رد کرده است (گام ۳ و ۴).

گام ۲: مطمئن شوید کلید درست ارسال می‌شود

کلاینت SSH به‌طور پیش‌فرض فقط کلیدهایی با نام‌های استاندارد را امتحان می‌کند؛ مثل ~/.ssh/id_ed25519 و ~/.ssh/id_rsa. اگر کلید را با نام دیگری ذخیره کرده‌اید، باید مسیرش را صریحاً بدهید:

ssh -i ~/.ssh/my_server_key root@203.0.113.10

برای اینکه هر بار تایپش نکنید، آن را در فایل ~/.ssh/config تعریف کنید:

Host myserver
    HostName 203.0.113.10
    User root
    IdentityFile ~/.ssh/my_server_key
    IdentitiesOnly yes

حالا کافی است بنویسید ssh myserver. گزینهٔ IdentitiesOnly yes مهم است: اگر کلیدهای زیادی در ssh-agent دارید، کلاینت ممکن است چند کلید اشتباه را پیش از کلید درست امتحان کند و سرور پس از چند تلاش ناموفق (پیش‌فرض شش بار) اتصال را ببندد.

کاربران ویندوز و PuTTY: PuTTY فقط کلید با فرمت .ppk را می‌پذیرد و OpenSSH ویندوز فقط فرمت OpenSSH را. اگر کلید را در یکی ساخته‌اید و در دیگری استفاده می‌کنید، با PuTTYgen تبدیلش کنید (Load و سپس Save private key یا Conversions ← Export OpenSSH key).

گام ۳: نام کاربری را بررسی کنید

کلید برای یک کاربر مشخص روی سرور ثبت می‌شود. اگر کلید را در /root/.ssh/authorized_keys گذاشته‌اید اما با کاربر ubuntu وارد می‌شوید، یا برعکس، با همین خطا روبه‌رو می‌شوید. برخی ایمیج‌های ابری ورود مستقیم root را می‌بندند و کاربر پیش‌فرضی مثل ubuntu، debian، almalinux یا rocky دارند. اطلاعات اتصالی را که ارائه‌دهنده هنگام تحویل سرور داده، دقیق بررسی کنید.

گام ۴: کلید عمومی و مجوزها روی سرور

برای این گام باید به سرور دسترسی داشته باشید؛ اگر SSH راهی ندارد، از کنسول وب (VNC) ارائه‌دهنده وارد شوید. روی سرور دو چیز را بررسی کنید:

الف) کلید عمومی در جای درست باشد. محتوای فایل .pub روی کامپیوتر شما (یک خط که با ssh-ed25519 یا ssh-rsa شروع می‌شود) باید به‌صورت یک خط کامل در فایل authorized_keys کاربر مقصد باشد. کپی‌کردن از ترمینال یا پیام‌رسان گاهی خط را می‌شکند یا کاراکتر اضافه وارد می‌کند.

ب) مجوزها درست باشد. سرویس SSH با حالت سخت‌گیرانه (StrictModes) اگر پوشه یا فایل برای دیگران قابل‌نوشتن باشد، کلید را نادیده می‌گیرد:

chmod 700 ~/.ssh
chmod 600 ~/.ssh/authorized_keys
chown -R $USER:$USER ~/.ssh
# پوشهٔ خانه هم نباید برای گروه یا دیگران قابل‌نوشتن باشد
chmod go-w ~

اگر برای کاربر دیگری تنظیم می‌کنید، $USER را با نام آن کاربر جایگزین کنید. ساده‌ترین روش قرار دادن درست کلید، دستور ssh-copy-id از سمت کامپیوتر شماست، به شرط اینکه موقتاً ورود با رمز ممکن باشد؛ مراحل کامل را در آموزش کلید SSH و تغییر پورت ببینید.

$ ls -ld ~/.ssh ~/.ssh/authorized_keysdrwxrwxr-x ... /root/.ssh-rw-rw-r-- ... /root/.ssh/authorized_keys$ chmod 700 ~/.ssh && chmod 600 ~/.ssh/authorized_keys$ journalctl -u ssh -n 1 --no-pager... Accepted publickey for root from 198.51.100.20 ...$ 

گام ۵: لاگ سرور را بخوانید

لاگ سرویس SSH دقیق‌ترین علت رد شدن را می‌گوید. روی سرور (از کنسول) اجرا کنید و هم‌زمان از کامپیوتر خود دوباره تلاش کنید:

sudo journalctl -u ssh -f
# در AlmaLinux و Rocky نام سرویس sshd است
sudo tail -f /var/log/auth.log

پیام‌هایی مثل Authentication refused: bad ownership or modes مستقیماً مشکل مجوز را نشان می‌دهند. پیام User root from ... not allowed یعنی ورود root در تنظیمات بسته است.

گام ۶: تنظیمات sshd را بررسی کنید

فایل /etc/ssh/sshd_config و فایل‌های داخل /etc/ssh/sshd_config.d/ را ببینید. گزینه‌های مرتبط:

• PubkeyAuthentication yes باید فعال باشد.
• PermitRootLogin اگر no باشد، ورود root حتی با کلید ممکن نیست؛ مقدار prohibit-password یعنی root فقط با کلید.
• AuthorizedKeysFile معمولاً .ssh/authorized_keys است؛ اگر تغییر کرده، کلید را در همان مسیر بگذارید.
• AllowUsers اگر تعریف شده، فقط کاربران فهرست‌شده می‌توانند وارد شوند.

پس از هر تغییر، ابتدا پیکربندی را تست و سپس سرویس را بارگذاری دوباره کنید و نشست فعلی را نبندید تا مطمئن شوید در نشست جدید وارد می‌شوید:

sudo sshd -t && sudo systemctl reload ssh

حالت‌های خاص که کمتر به آن‌ها توجه می‌شود

نصب دوباره سیستم‌عامل: اگر سرور را دوباره نصب کرده‌اید، authorized_keys قبلی از بین رفته است و باید کلید را دوباره قرار دهید. در این حالت معمولاً هشدار تغییر کلید میزبان (Host key) هم می‌بینید که با حذف خط قدیمی از known_hosts برطرف می‌شود: ssh-keygen -R 203.0.113.10.

کلید با عبارت عبور: اگر کلید خصوصی‌تان عبارت عبور (Passphrase) دارد و آن را اشتباه وارد کنید، کلاینت کلید را نمی‌تواند باز کند و ارسالش نمی‌کند؛ نتیجه همان خطای publickey است. با ssh-keygen -y -f ~/.ssh/id_ed25519 می‌توانید بررسی کنید که عبارت عبور را درست به یاد دارید یا نه.

سیستم‌فایل رمزنگاری‌شده یا پوشهٔ خانهٔ غیرعادی: اگر پوشهٔ خانهٔ کاربر تا پیش از ورود در دسترس نیست (مثلاً رمزنگاری‌شده است یا روی دیسک جداگانه‌ای قرار دارد که هنوز mount نشده)، سرویس SSH نمی‌تواند authorized_keys را بخواند. این وضعیت روی سرورهای معمولی نادر است، اما در سرورهای سفارشی پیش می‌آید.

SELinux در AlmaLinux و Rocky: اگر فایل authorized_keys را با روشی غیرمعمول ساخته یا از جای دیگری کپی کرده باشید، ممکن است برچسب امنیتی درستی نداشته باشد. دستور restorecon -Rv ~/.ssh برچسب‌ها را اصلاح می‌کند.

کلیدهای RSA قدیمی

نسخه‌های جدید OpenSSH الگوریتم امضای قدیمی ssh-rsa با SHA-1 را به‌طور پیش‌فرض نمی‌پذیرند. اگر از کلاینت بسیار قدیمی یا کلید RSA خیلی کهنه استفاده می‌کنید، ممکن است همین خطا را ببینید. ساده‌ترین و امن‌ترین راه، ساختن کلید جدید از نوع ed25519 است:

ssh-keygen -t ed25519 -C "my-laptop"

پیشگیری از قفل شدن در آینده

• پیش از غیرفعال کردن ورود با رمز، در یک پنجرهٔ جداگانه مطمئن شوید ورود با کلید کار می‌کند.
• از کلید خصوصی خود یک نسخهٔ امن پشتیبان نگه دارید؛ گم شدن آن یعنی نیاز به کنسول وب برای افزودن کلید جدید.
• برای هر دستگاه یک کلید جدا بسازید تا اگر دستگاهی گم شد، فقط همان کلید را از authorized_keys حذف کنید.
• راه ورود اضطراری، یعنی کنسول وب ارائه‌دهنده، را از قبل امتحان کنید.

در سرورهای کلودیفای، از بخش مدیریت سرور می‌توانید رمز را نمایش دهید یا بازنشانی کنید و در صورت نیاز از کنسول وارد شوید؛ مراحل ورود اول در راهنمای اولین ورود به سرور آمده است. برای مرور کامل روش اتصال از ویندوز، مک و لینوکس هم آموزش اتصال به سرور با SSH را ببینید.

سؤالات متداول