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

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

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

عبارات داخل پرانتز، روش‌هایی هستند که سرور مایل به پذیرش آن‌هاست. عبارت 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 (دیمون 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

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

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 است. تحت این تنظیم، sshd از خواندن authorized_keys خودداری می‌کند اگر آن فایل، دایرکتوری .ssh یا دایرکتوری home حساب کاربری توسط هر کسی غیر از مالک قابل نوشتن باشد. دلیل این امر واضح است: اگر گروه یا سایر کاربران (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.

مالکیت به اندازه حالت (mode) اهمیت دارد. فایلی در داخل /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 که از مسیر غیرمعمولی ایجاد شده باشد، ممکن است برچسب فایل اشتباهی داشته باشد؛ بنابراین با وجود درست بودن مجوزها، 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 کاملاً نادیده گرفته می‌شود و قوانین مجوز (mode) از دلیل 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 (محاسبات شبکه مجازی) باز کنید و مطمئن شوید که می‌توانید از آن طریق وارد شوید.
2. اطمینان حاصل کنید که رمز عبور محلی معتبری برای یک حساب کاربری با دسترسی sudo دارید. اگر ندارید، ابتدا رمز عبور root را از طریق کنسول ارائه‌دهنده بازنشانی کنید.
3. نشست SSH فعلی خود را باز نگه دارید. یک نشست باز، systemctl restart ssh را تاب می‌آورد، بنابراین اگر پیکربندی جدید اشتباه باشد، همچنان راهی برای بازگشت باقی می‌ماند.
4. پیش از restart، نحو (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 به مسیری که شخص دیگری امکان تغییر آن را داشته باشد اعتماد نمی‌کند، بنابراین طوری رفتار می‌کند که گویی هیچ کلیدی وجود ندارد. دسترسی دایرکتوری 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 امضاهای ssh-rsa SHA-1 را به‌طور پیش‌فرض غیرفعال کرده است، بنابراین کلیدی که فقط با آن روش امضا می‌کند، رد می‌شود. خروجی verbose کلاینت، debug1: send_pubkey_test: no mutual signature algorithm را نشان می‌دهد. یک کلید مدرن با ssh-keygen -t ed25519 تولید کنید و فایل .pub آن را نصب کنید. اگر فوراً به دسترسی نیاز دارید، PubkeyAcceptedAlgorithms +ssh-rsa در سرور امضاهای قدیمی را دوباره فعال می‌کند؛ پس از اینکه کلید جدید کار کرد، باید آن خط را حذف کنید.

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

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