رفع خطای Permission denied (publickey) در SSH

معنای واقعی خطای Permission denied (publickey)

خطای Permission denied (publickey) بدین معناست که کلاینت شما یک یا چند کلید عمومی ارسال کرده و سرور هیچ‌کدام را نپذیرفته است. شبکه مشکلی ندارد و سرویس sshd در حال اجراست: این عدم پذیرش در آخرین مرحله از احراز هویت رخ می‌دهد. رفع این مشکل هرگز با حدس و گمان انجام نمی‌شود، زیرا ssh -v به شما می‌گوید که کدام‌یک از پنج علت احتمالی عامل بروز این وضعیت است.

عبارات داخل پرانتز، روش‌هایی هستند که سرور مایل به پذیرش آن‌هاست. عبارت Permission denied (publickey) به تنهایی به این معناست که ورود با رمز عبور در آن سرور غیرفعال شده است، بنابراین هیچ رمز عبوری برای جایگزینی وجود ندارد. عبارت Permission denied (publickey,password) به این معناست که ورود با رمز عبور مجاز بوده و شما در آن مرحله نیز ناموفق بوده‌اید.

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

ابتدا ssh -v را اجرا کنید و سه خط را بخوانید

دستوری که با شکست مواجه شده است را با افزودن -v دوباره اجرا کنید:

ssh -v deploy@203.0.113.10

یک خروجی واقعی اما خلاصه شده به این شکل است:

OpenSSH_9.6p1 Ubuntu-3ubuntu13, OpenSSL 3.0.13 30 Jan 2024
debug1: Connecting to 203.0.113.10 [203.0.113.10] port 22.
debug1: Connection established.
debug1: Authenticating to 203.0.113.10:22 as 'deploy'
debug1: Authentications that can continue: publickey
debug1: Next authentication method: publickey
debug1: Will attempt key: /home/you/.ssh/id_ed25519 ED25519 SHA256:0eL/8sBw... agent
debug1: Offering public key: /home/you/.ssh/id_ed25519 ED25519 SHA256:0eL/8sBw... agent
debug1: Authentications that can continue: publickey
debug1: No more authentication methods to try.
deploy@203.0.113.10: Permission denied (publickey).

سه خط زیر تمام اطلاعات مورد نیاز شما را در بر دارند.

Authenticating to 203.0.113.10:22 as 'deploy' نام کاربری است که در واقع استفاده خواهد شد. نه آن نامی که مد نظر شما بوده است: بلکه نامی که ssh از روی خط فرمان، از ~/.ssh/config، یا از نام کاربری محلی شما استخراج کرده است.

Authentications that can continue: publickey لیست روش‌های پذیرفته‌شده توسط سرور است که پیش از تلاش برای استفاده از هر کلیدی ارسال می‌شود. اگر publickey در آن لیست اولیه وجود نداشته باشد، یعنی ورود با کلید عمومی (public key) در سرور غیرفعال است و هیچ کلیدی کار نخواهد کرد.

Offering public key: ... به ازای هر کلیدی که کلاینت شما واقعاً ارسال کرده است، یک خط نمایش می‌دهد که نام فایل منبع و اثر انگشت SHA256 آن را مشخص می‌کند. کلیدی که خط Offering برای آن وجود ندارد، هرگز به سرور ارسال نشده است.

اکنون مشکل را به دو بخش تقسیم کنید:

• خط Offering public key برای کلیدی که انتظار دارید وجود ندارد. خطا در سیستم شماست، زیرا سرور اصلاً کلید شما را دریافت نکرده است.
• کلید ارائه می‌شود و دوباره Authentications that can continue: publickey بازمی‌گردد. سرور آن کلید را دریافت کرده و رد کرده است، بنابراین خطا در سمت سرور است.

علل ذکر شده در ادامه، به ترتیب فراوانی وقوع مرتب شده‌اند.

دلیل 1: اتصال با نام کاربری اشتباه

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

پیش از هر چیز، خط Authenticating to ... as را بررسی کنید. اگر این خط به جای حساب کاربری سرور، نام کاربری لپ‌تاپ شما را نشان می‌دهد، یعنی نام کاربری را در دستور وارد نکرده‌اید.

ssh -v deploy@203.0.113.10
ssh -v root@203.0.113.10

حساب کاربری پیش‌فرض به ایمیجی بستگی دارد که ارائه‌دهندهٔ سرویس شما ارائه می‌دهد. تا اوت 2026، ایمیج‌های ابری Ubuntu معمولاً با حساب ubuntu عرضه می‌شوند، ایمیج‌های Debian با debian یا admin، ایمیج‌های Rocky Linux و AlmaLinux با rocky و almalinux، و بسیاری از ارائه‌دهندگان VPS کلید شما را مستقیماً در root نصب می‌کنند. پنل مدیریت ارائه‌دهندهٔ شما ثبت می‌کند که کدام حساب کاربری ایجاد شده است. هیچ دستوری از خارج سرور نمی‌تواند این موضوع را پرس‌وجو کند.

یک بلوک Host در فایل ~/.ssh/config نیز نام کاربری را تعیین می‌کند و اولویت آن بالاتر از نام کاربری محلی شماست:

Host vps-prod
  HostName 203.0.113.10
  User deploy

اگر حساب کاربری را خودتان ایجاد کرده‌اید و سپس نتوانستید با آن وارد شوید، احتمالاً کلید برای کاربر پیش‌فرض ایمیج نصب شده و به حساب جدید کپی نشده است. این مرحله بخشی از ده دقیقهٔ نخست روی یک VPS جدید است و به‌راحتی ممکن است فراموش شود.

دلیل 2: کلیدی که تصور می‌کنید در حال ارسال آن هستید، همان کلیدی نیست که ارسال می‌شود

به‌طور پیش‌فرض، ssh فقط کلیدهای موجود در ssh-agent و مجموعه‌ای ثابت از نام فایل‌ها در ~/.ssh را ارائه می‌دهد: id_ed25519، id_ecdsa، id_rsa و نسخه‌های سخت‌افزاری و DSA از این نام‌ها. کلیدی که با نام ~/.ssh/vps-prod ذخیره شده باشد، تا زمانی که آن را مشخص نکنید برای ssh نامرئی است؛ به همین دلیل است که خروجی verbose هیچ خط Offering public key برای آن نشان نمی‌دهد.

نام فایل را مشخص کنید و مانع از آن شوید که کلیدهای agent جای آن را بگیرند:

ssh -i ~/.ssh/vps-prod -o IdentitiesOnly=yes deploy@203.0.113.10

استفاده از -i به‌تنهایی کافی نیست، زیرا زمانی که agent کلیدهایی در اختیار دارد، ssh همچنان ابتدا کلیدهای agent و در نهایت فایل نام‌گذاری‌شده را ارائه می‌دهد. این موضوع اهمیت دارد، چرا که سرور هر کلید ردشده را در شمارش MaxAuthTries لحاظ می‌کند که مقدار پیش‌فرض آن 6 است. اگر یک agent هفت کلید داشته باشد، پیش از آنکه نوبت به کلید صحیح شما برسد، محدودیت تمام می‌شود و پیام خطا به این صورت تغییر می‌کند:

Received disconnect from 203.0.113.10 port 22:2: Too many authentication failures

IdentitiesOnly=yes تلاش برای احراز هویت را فقط به فایلی که ارسال کرده‌اید محدود می‌کند. با استفاده از ssh-add -l لیست کلیدهای موجود در agent را مشاهده کنید و اگر سال‌ها کلید قدیمی در آن جمع شده است، با ssh-add -D آن را پاک‌سازی کنید. سپس تنظیمات را یادداشت کنید تا ورود بعدی وابسته به به‌خاطر سپردن فلگ‌ها نباشد:

Host vps-prod
  HostName 203.0.113.10
  User deploy
  IdentityFile ~/.ssh/vps-prod
  IdentitiesOnly yes

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

@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@
@         WARNING: UNPROTECTED PRIVATE KEY FILE!          @
@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@
Permissions 0644 for '/home/you/.ssh/vps-prod' are too open.

chmod 600 ~/.ssh/vps-prod این مشکل را برطرف می‌کند. انتقال کلید از طریق حافظه USB یا اشتراک‌گذاری در ویندوز، معمول‌ترین راهی است که باعث از دست رفتن مجوزهای فایل (mode) می‌شود. محل نگهداری کلیدها و نحوه نام‌گذاری آن‌ها در اصول مدیریت کلید SSH پوشش داده شده است.

دلیل 3: کلید عمومی هرگز به authorized_keys نرسیده است

اگر ssh -v نشان می‌دهد که کلید ارسال شده اما سرور همچنان دسترسی نمی‌دهد، پرسش بعدی این است که آیا آن کلید در فایل authorized_keys حساب کاربری قرار دارد یا خیر. از آنجا که نمی‌توانید از طریق SSH برای بررسی وارد شوید، کنسول ارائه‌دهنده خدمات خود را باز کنید.

sudo ls -l /home/deploy/.ssh/
sudo ssh-keygen -lf /home/deploy/.ssh/authorized_keys

دستور ssh-keygen -lf روی یک فایل authorized_keys، برای هر ورودی یک اثر انگشت (fingerprint) چاپ می‌کند:

256 SHA256:0eL/8sBw... you@laptop (ED25519)
3072 SHA256:9Tq2yZk... old-laptop (RSA)

آن‌ها را با اثر انگشت موجود در خط Offering public key خود مقایسه کنید. اگر در لیست نیست، کلید روی آن حساب نصب نشده است، فارغ از اینکه چه چیزی در خاطر دارید.

چهار روش رایج که در آن اشتباه رخ می‌دهد:

• شما کلید خصوصی را به جای فایل .pub کپی کرده‌اید. خط کلید عمومی با ssh-ed25519 یا ssh-rsa شروع می‌شود. کلید خصوصی با -----BEGIN OPENSSH PRIVATE KEY----- شروع می‌شود.
• متن کپی‌شده در چندین خط شکسته شده است. هر ورودی باید دقیقاً در یک خط قرار بگیرد؛ بنابراین کلیدی که شکسته شده باشد، به عنوان چندین ورودی ناقص خوانده می‌شود و با چیزی مطابقت پیدا نمی‌کند.
• کلید در /root/.ssh/authorized_keys قرار گرفته است در حالی که شما با کاربر deploy وارد می‌شوید، یا برعکس. این فایل مختص هر حساب است و فایل مشترکی وجود ندارد.
• کادر "add my key" در پنل ارائه‌دهنده، کلید را فقط برای کاربر پیش‌فرض ایمیج نوشته است، بنابراین حسابی که بعداً ایجاد کرده‌اید دارای دایرکتوری .ssh خالی است.

روش ایمن برای افزودن کلید از طریق کنسول، با دسترسی root:

sudo install -d -m 700 -o deploy -g deploy /home/deploy/.ssh
sudo tee -a /home/deploy/.ssh/authorized_keys >/dev/null <<'EOF'
ssh-ed25519 AAAAC3NzaC1lZDI1NTE5AAAAIExampleKeyDataHere you@laptop
EOF
sudo chown deploy:deploy /home/deploy/.ssh/authorized_keys
sudo chmod 600 /home/deploy/.ssh/authorized_keys

پس از آن دوباره sudo ssh-keygen -lf /home/deploy/.ssh/authorized_keys را اجرا کنید. اثر انگشت جدید اکنون باید در لیست باشد. از دستگاهی که هنوز امکان ورود با رمز عبور را دارد، دستور ssh-copy-id -i ~/.ssh/vps-prod.pub deploy@203.0.113.10 همان کار را انجام می‌دهد و مجوزهای دسترسی (modes) را نیز به‌درستی برای شما تنظیم می‌کند.

دلیل 4: چرا sshd فایل authorized_keys را در صورت باز بودن بیش از حد مجوزها نادیده می‌گیرد

StrictModes yes تنظیم پیش‌فرض sshd است. تحت این تنظیم، اگر فایل authorized_keys، دایرکتوری .ssh یا دایرکتوری home حساب کاربری توسط هر شخصی غیر از مالک آن قابل نوشتن باشد، sshd از خواندن authorized_keys خودداری می‌کند. دلیل این امر واضح است: اگر گروه یا سایر کاربران (world) بتوانند در دایرکتوری home شما بنویسند، هر حسابی با این دسترسی می‌تواند authorized_keys را جایگزین کرده و کنترل ورود را به دست بگیرد. sshd با یک مسیر غیرقابل‌اعتماد طوری رفتار می‌کند که گویی هیچ کلیدی وجود ندارد.

کلاینت پیام ساده Permission denied را مشاهده می‌کند. لاگ سرور دلیل واقعی را ثبت می‌کند:

Authentication refused: bad ownership or modes for directory /home/deploy/.ssh

یا زمانی که خود فایل مشکل‌ساز باشد:

Authentication refused: bad ownership or modes for file /home/deploy/.ssh/authorized_keys

آنچه sshd می‌پذیرد:

• دایرکتوری home: نباید توسط گروه یا سایر کاربران قابل نوشتن باشد. 755، 750 و 700 همگی مورد قبول هستند. 775 و 777 رد می‌شوند.
• ~/.ssh: با مجوز 700.
• ~/.ssh/authorized_keys: با مجوز 600.
• مالکیت: هر سه مورد باید متعلق به حسابی باشد که با آن وارد می‌شوید، نه متعلق به root.

مالکیت به اندازه مجوزها اهمیت دارد. فایلی در /home/deploy/.ssh که متعلق به root باشد، در همان بررسی شکست می‌خورد؛ این اتفاق زمانی می‌افتد که فایل را با sudo nano ایجاد کرده و فراموش کنید مالکیت آن را بازگردانید. هر دو را همزمان اصلاح کنید:

sudo chown -R deploy:deploy /home/deploy/.ssh
sudo chmod 700 /home/deploy/.ssh
sudo chmod 600 /home/deploy/.ssh/authorized_keys
sudo chmod go-w /home/deploy
ls -ld /home/deploy /home/deploy/.ssh

دستور آخر نتیجه را نشان می‌دهد. شما به مجوز drwxr-xr-x یا محدودتر برای دایرکتوری home و drwx------ برای .ssh نیاز دارید. اگر این رشته‌ها هنوز برایتان واضح نیستند، پیش از تغییر مجوزها روی یک سرور زنده، نحوه خواندن رشته مجوز مانند drwxr-xr-x را مطالعه کنید.

در Rocky Linux و AlmaLinux، سیستم SELinux (امنیت پیشرفته لینوکس) را نیز به لیست موارد مشکوک اضافه کنید. یک دایرکتوری .ssh که از مسیر غیرمعمولی ایجاد شده باشد، ممکن است دارای برچسب فایل (file label) اشتباه باشد؛ بنابراین با وجود درست بودن مجوزها، sshd از دسترسی خواندن منع می‌شود. دستور sudo restorecon -Rv /home/deploy/.ssh برچسب‌ها را اصلاح می‌کند و sudo ausearch -m avc -ts recent نشان می‌دهد که آیا SELinux همان مؤلفه‌ای بوده که دسترسی را رد کرده است یا خیر.

دلیل 5: پیکربندی sshd دسترسی شما را رد می‌کند

خواندن /etc/ssh/sshd_config در سیستم‌های فعلی Ubuntu یا Debian کافی نیست. آن فایل با Include /etc/ssh/sshd_config.d/*.conf شروع می‌شود و OpenSSH اولین مقداری را که برای هر تنظیم پیدا کند، می‌پذیرد. بنابراین، یک فایل drop-in مانند 50-cloud-init.conf ابتدا خوانده می‌شود و بر هر تغییری که در سطرهای پایین‌تر فایل اصلی اعمال کنید، اولویت دارد. به همین دلیل است که گاهی ویرایش فایل درست به نظر می‌رسد اما هیچ تغییری ایجاد نمی‌شود.

از sshd بخواهید پیکربندی‌ای را که واقعاً در حال استفاده از آن است به شما نشان دهد:

sudo sshd -T | grep -Ei 'pubkeyauth|authorizedkeysfile|permitrootlogin|allowusers|allowgroups|denyusers'

یک پاسخ سالم به این شکل است:

permitrootlogin prohibit-password
pubkeyauthentication yes
authorizedkeysfile .ssh/authorized_keys .ssh/authorized_keys2

موارد زیر را در خروجی خود بررسی کنید:

• pubkeyauthentication no. هیچ کلیدی پذیرفته نخواهد شد. این مورد همچنین در ssh -v به صورت یک لیست Authentications that can continue: اولیه بدون هیچ publickey در آن ظاهر می‌شود.
• authorizedkeysfile که به مسیر دیگری اشاره دارد، برای مثال /etc/ssh/authorized_keys/%u. در این صورت، فایلی که در دایرکتوری home قرار دارد کاملاً نادیده گرفته می‌شود و قوانین مربوط به مجوزها (از دلیل 4) به جای آن، برای مسیر جدید اعمال می‌شوند.
• وجود allowusers یا allowgroups. هر حسابی که در این لیست‌ها نباشد، دقیقاً با همین خطا و بدون هیچ توضیحی رد می‌شود. denyusers و denygroups نیز همین کار را به صورت معکوس انجام می‌دهند.
• permitrootlogin no در حالی که تلاش می‌کنید با کاربر root وارد شوید. prohibit-password تنظیم میانی مفیدی است: کاربر root می‌تواند از کلید استفاده کند اما اجازه ورود با رمز عبور را ندارد.

بلوک‌های Match در یک sshd -T ساده ظاهر نمی‌شوند، زیرا نتیجه آن‌ها به این بستگی دارد که چه کسی در حال اتصال است. درباره یک اتصال خاص پرس‌وجو کنید:

sudo sshd -T -C user=deploy,host=vps.example.com,addr=198.51.100.7

یک تنظیم دیگر بر کلیدهای قدیمی‌تر تأثیر می‌گذارد. OpenSSH 8.8 دیگر امضاهای SHA-1 (ssh-rsa) را به صورت پیش‌فرض نمی‌پذیرد، بنابراین کلید RSA که سال‌ها کار می‌کرد، ممکن است بلافاصله پس از ارتقای سرور از کار بیفتد. کلاینت این موضوع را به وضوح اعلام می‌کند:

debug1: send_pubkey_test: no mutual signature algorithm

راه‌حل درست، ایجاد یک کلید جدید است: ssh-keygen -t ed25519 -C "deploy@vps-prod"، سپس فایل .pub را همان‌طور که در بالا نشان داده شد نصب کنید. تنظیم PubkeyAcceptedAlgorithms +ssh-rsa روی سرور، امضاهای قدیمی را دوباره فعال می‌کند و به شما اجازه ورود می‌دهد، اما آن را صرفاً راهی برای دسترسی به سرور در نظر بگیرید، نه پایان کار. سایر تنظیمات سمت سرور که ارزش بررسی دارند در ایمن‌سازی سرور SSH روی VPS آمده‌اند.

نحوه اثبات تطابق کلید خصوصی با کلید عمومی نصب‌شده

بخش بزرگی از حدس و گمان‌ها در این خطا ناشی از این است که نمی‌دانید آیا دو فایل با هم جفت هستند یا خیر. یک دستور پاسخ این پرسش را می‌دهد:

ssh-keygen -y -f ~/.ssh/vps-prod

این دستور کلید عمومی استخراج‌شده از کلید خصوصی را چاپ می‌کند. این دستور هرگز فایل .pub کنار آن را نمی‌خواند، بنابراین به شما نشان می‌دهد که کلید خصوصی واقعاً چیست، نه آنچه یک فایل .pub قدیمی ادعا می‌کند. اگر کلید دارای passphrase باشد، دستور آن را درخواست می‌کند که خود اثباتی بر این است که شما هنوز passphrase را می‌دانید.

ssh-keygen -lf ~/.ssh/vps-prod.pub
ssh-add -l

دستور اول اثر انگشت (fingerprint) یک فایل کلید عمومی را چاپ می‌کند. دستور دوم اثر انگشت‌هایی که در agent شما نگهداری می‌شوند را چاپ می‌کند. اکنون چهار نمای مختلف از یک رشته را با هم مقایسه کنید: اثر انگشت موجود در خط Offering public key از ssh -v، اثر انگشت فایل .pub خودتان، اثر انگشت‌های موجود در ssh-keygen -lf در فایل authorized_keys سرور، و اثر انگشت موجود در لاگ سرور. نقطه‌ای که در آن تطابق از بین می‌رود، محل بروز خطای شماست.

خواندن لاگ سرور هنگام شکست ورود

به دلایل امنیتی، هیچ اطلاعات مفیدی به کلاینت داده نمی‌شود. سرور دلیل واقعی را در لاگ می‌نویسد. یک دنبال‌کننده لاگ را در نشست کنسول اجرا کنید و سپس دستور ssh را از لپ‌تاپ خود اجرا کنید تا با خطا مواجه شود.

sudo journalctl -u ssh -f

سیستم‌عامل Ubuntu 24.04 به‌صورت پیش‌فرض rsyslog را نصب نمی‌کند، بنابراین ممکن است /var/log/auth.log در آن وجود نداشته باشد. در Rocky Linux و AlmaLinux، نام این واحد sshd است و رکوردهای مشابه در /var/log/secure ذخیره می‌شوند.

مقدار LogLevel VERBOSE را در پیکربندی sshd تنظیم کرده و سرویس را reload کنید. پس از آن، هر تلاش برای ورود، اثر انگشت (fingerprint) دریافتی توسط سرور را لاگ می‌کند:

Failed publickey for deploy from 198.51.100.7 port 49812 ssh2: ED25519 SHA256:0eL/8sBw...

آن خط به شما می‌گوید که خطا از کدام سمت است. اگر اثر انگشت را می‌شناسید، یعنی کلید شما به سرور رسیده اما رد شده است؛ پس به دلایل 3، 4 و 5 مراجعه کنید. اگر اثر انگشت را نمی‌شناسید، یعنی کلاینت شما کلیدی را ارسال کرده که مد نظر شما نبوده است؛ پس به دلیل 2 بازگردید.

اگر لاگ همچنان مبهم است، یک نمونه دوم از sshd را روی پورت دیگری در حالت debug اجرا کنید. این نمونه در پیش‌زمینه باقی می‌ماند، به یک اتصال پاسخ می‌دهد، دلایل خود را چاپ می‌کند و سپس خارج می‌شود:

sudo /usr/sbin/sshd -ddd -p 2222

از نشست کنسول روی همان سرور، از طریق آدرس loopback به آن متصل شوید:

ssh -p 2222 -i ~/.ssh/vps-prod -o IdentitiesOnly=yes deploy@127.0.0.1

استفاده از 127.0.0.1 باعث می‌شود فایروال در این تست دخالتی نداشته باشد. خروجی debug فایلی که باز شده، اثر انگشتی که مقایسه شده و دلیل دقیق رد شدن (شامل خطوطی مانند Authentication refused: bad ownership or modes for directory /home/deploy) را نمایش می‌دهد. پس از دریافت پاسخ، کلیدهای Ctrl+C را فشار دهید. نمونه اصلی sshd روی پورت 22 در تمام این مدت بدون تغییر باقی می‌ماند.

چگونه از مسدود شدن دسترسی خود جلوگیری کنید

هر مرحله‌ای که پیکربندی سرور را تغییر می‌دهد، نیازمند راهی برای بازگشت است که به SSH وابسته نباشد. این راهکار را زمانی که SSH هنوز کار می‌کند پیاده‌سازی کنید، نه پس از آنکه دسترسی قطع شد.

1. کنسول ارائه‌دهندهٔ خدمات خود را از طریق سریال یا VNC (مخفف virtual network computing) باز کنید و مطمئن شوید که می‌توانید از آن طریق وارد شوید.
2. اطمینان حاصل کنید که رمز عبور محلی معتبری برای یک حساب کاربری با دسترسی sudo دارید. اگر ندارید، ابتدا رمز عبور root را از طریق کنسول ارائه‌دهنده بازنشانی کنید.
3. نشست SSH فعلی خود را باز نگه دارید. یک نشست باز، systemctl restart ssh را تاب می‌آورد، بنابراین اگر پیکربندی جدید اشتباه باشد، همچنان راهی برای بازگشت باقی می‌ماند.
4. پیش از راه‌اندازی مجدد، نحو (syntax) را بررسی کنید: sudo sshd -t در صورت معتبر بودن فایل، خروجی نمی‌دهد و در صورت وجود خطا، نام فایل و شماره خط را چاپ می‌کند.
5. پیش از بستن ترمینال اول، یک ترمینال دوم باز کنید و یک نشست جدید ایجاد کنید. پیکربندی معیوب مانع از ورودهای جدید می‌شود اما نشست‌های موجود را دست‌نخورده باقی می‌گذارد؛ بنابراین نشستی که در آن هستید نمی‌تواند به شما بگوید که آیا تغییرات اعمال‌شده کار می‌کنند یا خیر.

سرویس را با sudo systemctl restart ssh در Debian و Ubuntu، یا sudo systemctl restart sshd در Rocky Linux و AlmaLinux راه‌اندازی مجدد کنید. در Ubuntu 24.04، سرویس sshd از یک socket unit اجرا می‌شود، بنابراین تغییر در Port یا ListenAddress پیش از اعمال شدن، نیازمند sudo systemctl restart ssh.socket نیز هست.

FAQ

چرا با وجود اینکه کلید من در سرور دیگری کار می‌کند، خطای Permission denied (publickey) دریافت می‌کنم؟

زیرا کلید شما مشکلی ندارد و مسئله مربوط به محیط اطراف آن است. دستور ssh -v را اجرا کنید و خط Offering public key را بیابید. اگر کلید شما در لیست نیست، ssh هرگز آن را ارسال نکرده است: فایل در مسیر ~/.ssh با نام پیش‌فرض وجود ندارد و در agent نیز بارگذاری نشده است، بنابراین -i /path/to/key -o IdentitiesOnly=yes را اضافه کنید. اگر کلید در لیست است و سرور همچنان دسترسی را رد می‌کند، آن کلید در فایل authorized_keys حساب کاربری وجود ندارد، مسیر آن برای گروه قابل‌نوشتن است، یا پیکربندی sshd دسترسی کاربر را مسدود کرده است. لاگ سرور این موارد را از هم تفکیک می‌کند.

چگونه بفهمم SSH دقیقاً در حال ارسال کدام کلید است؟

دستور ssh -v host به ازای هر کلید یک خط debug1: Offering public key: چاپ می‌کند که نام فایل منبع و اثر انگشت SHA256 آن را نشان می‌دهد. دستور ssh-add -l اثر انگشت‌های موجود در agent را لیست می‌کند. دستور ssh-keygen -lf ~/.ssh/id_ed25519.pub اثر انگشت یک فایل کلید خاص را چاپ می‌کند و ssh-keygen -y -f ~/.ssh/id_ed25519 کلید عمومی مشتق‌شده از یک کلید خصوصی را نمایش می‌دهد. برای موفقیت در ورود، اثر انگشت موجود در خط Offering باید در خروجی دستور ssh-keygen -lf که روی فایل authorized_keys سرور اجرا شده است نیز دیده شود.

چرا sshd فایل authorized_keys مرا نادیده می‌گیرد؟

زیرا گزینه StrictModes به‌صورت پیش‌فرض فعال است و اگر فایل، دایرکتوری .ssh یا دایرکتوری home توسط گروه یا سایر کاربران قابل‌نوشتن باشد، یا مالکیت آن متعلق به حساب کاربری دیگری باشد، sshd به آن اعتماد نمی‌کند. sshd به مسیری که دیگران امکان تغییر آن را داشته باشند اعتماد نمی‌کند و طوری رفتار می‌کند که گویی هیچ کلیدی وجود ندارد. مجوز دایرکتوری home را روی 755 یا محدودتر تنظیم کنید، .ssh را روی 700 و authorized_keys را روی 600 قرار دهید و مالکیت هر سه را به حساب کاربری خود اختصاص دهید. با استفاده از LogLevel VERBOSE، سرور دلیل رد دسترسی را در Authentication refused: bad ownership or modes for directory /home/deploy/.ssh ثبت می‌کند.

کلید من بلافاصله پس از ارتقای سرور از کار افتاد. چه چیزی تغییر کرده است؟

اگر کلید شما از نوع RSA است، این موضوع به احتمال زیاد به تغییرات SHA-1 مربوط می‌شود. نسخه OpenSSH 8.8 امضاهای SHA-1 را در ssh-rsa به‌صورت پیش‌فرض غیرفعال کرده است، بنابراین کلیدی که فقط با آن روش امضا می‌کند، رد می‌شود. خروجی verbose کلاینت، پیام debug1: send_pubkey_test: no mutual signature algorithm را نشان می‌دهد. یک کلید مدرن با ssh-keygen -t ed25519 تولید کنید و فایل .pub آن را نصب کنید. اگر نیاز به دسترسی فوری دارید، افزودن PubkeyAcceptedAlgorithms +ssh-rsa به سرور، امضاهای قدیمی را دوباره فعال می‌کند؛ پس از اینکه کلید جدید کار کرد، حتماً آن خط را حذف کنید.

فایل sshd_config را ویرایش کردم و اکنون اصلاً نمی‌توانم وارد شوم. چگونه دسترسی را بازیابی کنم؟

از کنسول ارائه‌دهنده سرویس خود استفاده کنید که از طریق SSH عمل نمی‌کند. با رمز عبور محلی وارد شوید، دستور sudo sshd -t را اجرا کنید تا خطای نحوی و شماره خط آن را ببینید، تغییرات را لغو کنید و سرویس را مجدداً راه‌اندازی نمایید. سپس sudo sshd -T را بررسی کنید تا مقادیر در حال اجرا تأیید شوند، زیرا ممکن است فایلی در /etc/ssh/sshd_config.d/ پیکربندی اصلی را بازنویسی کرده باشد. اگر رمز عبور محلی ندارید، ابتدا رمز عبور root را از طریق کنسول بازنشانی کنید و سپس فایل را اصلاح نمایید.