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

شده که وقتی می خوایم با SSH به یک سرور مجازی وصل بشیم با خطایی مثل این مواجه شدیم:

user@203.0.113.10: Permission denied (publickey).

اولین نکته این است که معمولاً مشکل از اینترنت یا بسته بودن Port SSH نیست.

در این وضعیت Client توانسته به SSH Server برسد، اما مرحله Authentication موفق نشده است. به زبان ساده، Server کلیدی را که Client ارائه کرده پذیرفته نشده یا اصلاً کلید موردانتظار به Server ارائه نشد.

رایج‌ترین علت‌ها می تونن یکی از حالت های زیر باشد:

• Username اشتباه است

• Private Key اشتباهی استفاده می‌شود

• Public Key برای همان User روی Server ثبت نشده

• Permission یا Owner فایل‌های .ssh اشتباه است

• Public Key Authentication در SSH Server غیرفعال یا محدود شده

• مسیر authorized_keys تغییر کرده است

• تنظیماتی مثل PermitRootLogin یا AllowUsers مانع Login شده‌اند

اما بهتره که به‌جای تغییر تصادفی تنظیمات، ابتدا مشخص کنیم خطا سمت Client است یا Server.

سریع‌ترین ابزار برای این کار:

ssh -vvv user@SERVER_IP

است.

خطای Permission denied (publickey) دقیقاً یعنی چه؟

SSH قبل از ورود چند مرحله را پشت سر می‌گذارد.

به شکل ساده:

Client
  │
  ▼
Network Connection
  │
  ▼
SSH Handshake
  │
  ▼
Authentication
  │
  ├── Password
  ├── Public Key
  └── Other Methods
  │
  ▼
Login

وقتی به:

Permission denied (publickey)

می‌رسید، معمولاً Network Connection و SSH Handshake انجام شده‌اند و مشکل در Authentication اتفاق افتاده است.

این موضوع با خطاهایی مثل:

Connection refused

یا:

Connection timed out

فرق دارد.

در آن خطاها ممکن است هنوز اصلاً به مرحله Authentication نرسیده باشید.

بنابراین اولین قانون اینه که :

برای رفع Permission denied (publickey) ابتدا روی Authentication تمرکز کنید، نه Firewall و Network.

قدم اول: SSH را با حالت Verbose اجرا کنید

قبل از تغییر هر فایل یا Permission، یک بار اتصال را با جزئیات کامل اجرا کنید:

ssh -vvv user@SERVER_IP

اگر Private Key مشخصی دارید:

ssh -vvv -i ~/.ssh/id_ed25519 user@SERVER_IP

در PowerShell ویندوز نیز می‌توانید مثلاً بنویسید:

ssh -vvv -i "$env:USERPROFILE\.ssh\id_ed25519" user@SERVER_IP

خروجی زیاد است، اما چند خط برای ما اهمیت ویژه دارند.

به Username واقعی نگاه کنید

در خروجی Verbose مشخص می‌شود SSH با چه Userی تلاش می‌کند Login کند.

اگر تصور می‌کردید با:

root

وارد می‌شوید، اما Config شما deploy را انتخاب کرده باشد، ممکن است Public Key در Account اشتباهی جستجو شود.

دنبال Offering public key بگردید

ممکن است خطی شبیه این ببینید:

Offering public key: ...

این یعنی Client واقعاً آن Key را برای Authentication پیشنهاد داده است.

اگر Key موردنظر شما اصلاً در خطوط Offering public key دیده نمی‌شود، مشکل احتمالاً در سمت Client است.

مثلاً:

• مسیر Private Key اشتباه است

• Key توسط Agent بارگذاری نشده

• SSH Config یک Identity دیگر مشخص کرده

• Client اصلاً Key موردنظر را پیدا نمی‌کند

اگر Key ارائه می‌شود ولی پذیرفته نمی‌شود

اگر Client همان Key موردنظر را ارائه می‌کند ولی Login باز هم با:

Permission denied (publickey)

تمام می‌شود، باید سمت Server را بررسی کنیم.

در این حالت یکی از موارد رایج این‌هاست:

authorized_keys
Permissions
Ownership
Username
sshd_config
Access Rules

این تقسیم‌بندی جلوی مقدار زیادی آزمون و خطای بی‌دلیل را می‌گیرد.

علت اول: با Username اشتباه وصل می‌شوید

این یکی از ساده‌ترین و در عین حال رایج‌ترین علت‌هاست.

فرض کنید Public Key در این فایل قرار دارد:

/home/deploy/.ssh/authorized_keys

اما شما تلاش می‌کنید:

ssh root@SERVER_IP

را اجرا کنید.

SSH برای root کلیدهای مجاز Account deploy را بررسی نمی‌کند.

این دو Login کاملاً متفاوت‌اند:

root@server

و:

deploy@server

راه‌حل

Username صحیح VPS را مشخص کنید.

برای مثال:

ssh deploy@203.0.113.10

بعضی Imageهای Cloud نیز User پیش‌فرض مشخصی دارند؛ بنابراین Username را از اطلاعات همان سرویس یا Image بررسی کنید و از حدس زدن آن خودداری کنید.

اگر از SSH Config استفاده می‌کنید، فایل زیر را نیز بررسی کنید:

~/.ssh/config

مثلاً ممکن است داشته باشید:

Host production
    HostName 203.0.113.10
    User deploy
    IdentityFile ~/.ssh/production

در این صورت:

ssh production

از User و Key تعریف‌شده در همان Config استفاده می‌کند.

علت دوم: Private Key اشتباهی استفاده می‌شود

اگر چند SSH Key روی کامپیوتر داشته باشید، ممکن است SSH کلیدی غیر از Key موردنظر شما را امتحان کند.

مثلاً:

id_ed25519
work_key
production_key
github_key

در این شرایط بهتر است Key را صریح مشخص کنید.

در Linux و macOS:

ssh -i ~/.ssh/production_key user@SERVER_IP

در Windows PowerShell:

ssh -i "$env:USERPROFILE\.ssh\production_key" user@SERVER_IP

برای عیب‌یابی:

ssh -vvv -i ~/.ssh/production_key user@SERVER_IP

را اجرا کنید و بررسی کنید همان Key در خروجی Offering public key ظاهر شود.

چطور مطمئن شویم Private Key و Public Key متعلق به یک جفت هستند؟

اگر شک دارید Public Key نصب‌شده روی Server با Private Key فعلی شما متناظر است، می‌توانید از Private Key یک Public Key استخراج کنید.

مثلاً:

ssh-keygen -y -f ~/.ssh/id_ed25519

خروجی Public Key متناظر را نمایش می‌دهد.

حالا آن را با Public Key موجود روی Server مقایسه کنید.

همچنین برای مشاهده Fingerprint یک Public Key:

ssh-keygen -lf ~/.ssh/id_ed25519.pub

این روش مخصوصاً زمانی مفید است که Keyهای زیادی دارید و نام فایل‌ها دیگر قابل اعتماد نیستند.

علت سوم: Public Key داخل authorized_keys نیست

در OpenSSH، Public Keyهای مجاز یک User معمولاً داخل:

~/.ssh/authorized_keys

قرار می‌گیرند.

اگر برای User deploy وارد شده‌اید:

cat ~/.ssh/authorized_keys

را بررسی کنید.

باید Public Key موردنظر را در یک خط ببینید؛ مثلاً:

ssh-ed25519 AAAAC3NzaC1lZDI1NTE5AAAAI... user@computer

اگر Key وجود ندارد، آن را اضافه کنید.

برای مثال:

nano ~/.ssh/authorized_keys

و Public Key را به‌صورت یک خط کامل اضافه کنید.

اگر از ssh-copy-id استفاده می‌کنید:

ssh-copy-id user@SERVER_IP

نیز می‌تواند Public Key را برای User مقصد اضافه کند.

OpenSSH به‌طور پیش‌فرض Public Keyهای مجاز User را از ~/.ssh/authorized_keys می‌خواند.

اشتباه مهم: Private Key را داخل authorized_keys نگذارید

فایل:

authorized_keys

باید Public Key داشته باشد، نه Private Key.

Public Key معمولاً چیزی شبیه این است:

ssh-ed25519 AAAA...

ولی Private Key معمولاً ساختاری شبیه این دارد:

-----BEGIN OPENSSH PRIVATE KEY-----
...
-----END OPENSSH PRIVATE KEY-----

اگر چنین محتوایی را روی Server داخل authorized_keys قرار داده‌اید، فوراً آن را حذف کنید.

و اگر Private Key در جایی غیرقابل اعتماد منتشر شده، بهتر است آن Key Pair را دیگر معتبر ندانید و یک Key جدید بسازید.

مطالعه پیشنهادی: آموزش ساخت SSH Key در ویندوز و اتصال امن به سرور لینوکس

علت چهارم: Permission فایل‌های SSH اشتباه است

این یکی از مهم‌ترین علت‌های Permission denied (publickey) در Serverهای Linux است.

OpenSSH نسبت به Permission و Ownership فایل‌های Authentication حساس است.

اگر فایل یا Directory توسط دیگر کاربران قابل تغییر باشد، sshd ممکن است برای جلوگیری از دستکاری Keyها آن را قبول نکند. مستندات OpenSSH نیز اشاره می‌کند که اگر Home، پوشه .ssh یا authorized_keys توسط کاربران دیگر قابل نوشتن باشد، در حالت StrictModes کلید می‌تواند رد شود.

برای User موردنظر، ابتدا وضعیت را ببینید:

ls -ld ~ ~/.ssh ~/.ssh/authorized_keys

یک تنظیم رایج و امن:

chmod 700 ~/.ssh
chmod 600 ~/.ssh/authorized_keys

است.

همچنین Home Directory نباید برای کاربران دیگر قابل Write باشد:

chmod go-w ~

Ubuntu نیز در راهنمای رسمی OpenSSH تأکید می‌کند که کاربران دیگر نباید روی authorized_keys دسترسی نوشتن داشته باشند.

Ownership را هم بررسی کنید

Permission صحیح کافی نیست؛ Owner هم باید درست باشد.

مثلاً برای User:

deploy

بررسی کنید:

ls -ld /home/deploy/.ssh
ls -l /home/deploy/.ssh/authorized_keys

اگر این فایل‌ها اشتباهاً متعلق به root یا User دیگری باشند، آن‌ها را برای User صحیح اصلاح کنید.

مثلاً:

sudo chown -R deploy:deploy /home/deploy/.ssh

این Command را با Username واقعی خودتان جایگزین کنید و آن را روی مسیر اشتباه اجرا نکنید.

بعد دوباره:

ls -ld /home/deploy/.ssh
ls -l /home/deploy/.ssh/authorized_keys

را بررسی کنید.

چرا این مشکل زیاد اتفاق می‌افتد؟

یک سناریوی رایج این است:

sudo mkdir /home/deploy/.ssh
sudo nano /home/deploy/.ssh/authorized_keys

چون دستورات با sudo اجرا شده‌اند، ممکن است فایل‌ها متعلق به root شوند.

در ظاهر Public Key در محل درست است، ولی Owner فایل با Userی که قصد Login دارد تطابق ندارد.

علت پنجم: Public Key Authentication در SSH Server غیرفعال شده

اگر به Console سرور یا Session دیگری دسترسی دارید، Effective Configuration سرویس SSH را بررسی کنید.

مثلاً:

sudo sshd -T | grep -i pubkeyauthentication

خروجی مورد انتظار معمولاً:

pubkeyauthentication yes

است.

PubkeyAuthentication مشخص می‌کند آیا Public Key Authentication اجازه دارد یا خیر و در OpenSSH به‌طور پیش‌فرض فعال است.

همچنین مسیر Keyها را بررسی کنید:

sudo sshd -T | grep -i authorizedkeysfile

ممکن است چیزی شبیه:

authorizedkeysfile .ssh/authorized_keys .ssh/authorized_keys2

ببینید.

اگر Administrator مسیر دیگری برای AuthorizedKeysFile تعیین کرده باشد، قرار دادن Key در مسیر پیش‌فرض ممکن است تأثیری نداشته باشد.

چرا بهتر است sshd -T را ببینیم؟

فقط خواندن:

/etc/ssh/sshd_config

همیشه تصویر کامل Configuration را نشان نمی‌دهد.

SSH ممکن است Configurationهای دیگری را از:

/etc/ssh/sshd_config.d/

هم Include کند.

بنابراین:

sshd -T

برای مشاهده بسیاری از تنظیمات Effective مفیدتر است.

اگر sshd_config را تغییر دادید، قبل از Reload آن را تست کنید

فرض کنیم تغییری در:

/etc/ssh/sshd_config

یا:

/etc/ssh/sshd_config.d/

ایجاد کردید.

قبل از Reload ابتدا Syntax را بررسی کنید:

sudo sshd -t

اگر Command بدون خطا برگشت، Configuration از نظر Syntax معتبر است.

بعد در Ubuntu می‌توانید:

sudo systemctl reload ssh

را اجرا کنید.

هشدار مهم

اگر از راه دور به Server وصل هستید:

Session فعلی SSH را نبندید.

یک Terminal دوم باز کنید و Login جدید را تست کنید.

اگر Configuration اشتباه باشد، Session فعلی می‌تواند تنها راه باقی‌مانده شما برای اصلاح مشکل باشد.

علت ششم: Root Login محدود شده است

گاهی Key کاملاً صحیح است، اما فقط هنگام Login با root خطا می‌گیرید.

یکی از تنظیمات مهم SSH:

PermitRootLogin

است.

وضعیت Effective آن:

sudo sshd -T | grep -i permitrootlogin

ممکن است مثلاً:

permitrootlogin no

باشد.

در این حالت Login مستقیم Root مجاز نیست.

اگر:

prohibit-password

باشد، Password Login برای Root محدود است ولی Public Key می‌تواند همچنان قابل استفاده باشد. جزئیات این رفتار در تنظیم PermitRootLogin توسط OpenSSH تعریف شده است.

اگر سیاست Server اجازه Root Login نمی‌دهد، به‌جای تغییر عجولانه این تنظیم بهتر است با User معمولی وارد شوید:

ssh deploy@SERVER_IP

و سپس در صورت نیاز:

sudo -i

استفاده کنید.

علت هفتم: User یا Group توسط SSH محدود شده است

SSH Server می‌تواند دسترسی Userها را با Ruleهایی مثل:

AllowUsers
DenyUsers
AllowGroups
DenyGroups

محدود کند.

برای بررسی Configuration:

sudo grep -RniE '^(AllowUsers|DenyUsers|AllowGroups|DenyGroups)' /etc/ssh/sshd_config /etc/ssh/sshd_config.d/

مثلاً اگر فقط این Userها مجاز باشند:

AllowUsers admin deploy

Login با User دیگری حتی با Key صحیح ممکن است انجام نشود.

پس همیشه فرض نکنید مشکل از خود Key است.

یک روش سریع برای تشخیص سمت مشکل

اگر می‌خواهید بدون آزمون و خطای زیاد جلو بروید، این Flow را دنبال کنید.

ssh -vvv
   │
   ▼
آیا Key موردنظر Offering می‌شود؟
   │
 ┌─┴─────────────┐
 │               │
نه               بله
 │               │
 ▼               ▼
Client را      Server Key را
بررسی کن       قبول می‌کند؟
 │               │
 │          ┌────┴────┐
 │          │         │
 │         بله        نه
 │          │         │
 ▼          ▼         ▼
Key path   مشکل      authorized_keys
Agent      بعدی      Permissions
Config     را ببین   Username
                    sshd_config

به‌صورت عملی:

اگر Key اصلاً Offering نمی‌شود

این موارد را بررسی کنید:

Private Key Path
IdentityFile
ssh-agent
SSH Config
-i option

اگر Key Offering می‌شود ولی رد می‌شود

این موارد را بررسی کنید:

Username
authorized_keys
Public Key
Ownership
Permissions
PubkeyAuthentication
AuthorizedKeysFile
Access Rules

این دسته‌بندی سریع‌ترین مسیر برای رسیدن به علت واقعی است.

Server Log را هم‌زمان با Login مشاهده کنید

Client فقط نصف داستان را می‌بیند.

اگر دسترسی Console، Session قبلی یا User دیگری به Server دارید، Logهای SSH را هنگام تلاش برای Login مشاهده کنید.

در Ubuntu:

sudo journalctl -fu ssh.service

سپس در سیستم Client دوباره Login کنید:

ssh user@SERVER_IP

ممکن است Log Server دلیل بسیار واضح‌تری نشان دهد؛ مثلاً:

Authentication refused

یا مشکلی درباره Ownership، Permission یا User.

Ubuntu برای Troubleshooting اتصال با SSH Key نیز مشاهده Live Log سرویس ssh.service را پیشنهاد می‌کند.

چطور بفهمیم Public Key Server همان Key ماست؟

روی Client Fingerprint Key خود را ببینید:

ssh-keygen -lf ~/.ssh/id_ed25519.pub

اگر فقط Private Key دارید:

ssh-keygen -y -f ~/.ssh/id_ed25519 > /tmp/my-public-key.pub
ssh-keygen -lf /tmp/my-public-key.pub

روی Server می‌توانید Keyهای داخل authorized_keys را نیز بررسی کنید.

این روش برای Environmentهایی با تعداد Key زیاد بهتر از مقایسه چشمی رشته‌های طولانی AAAA... است.

مشکل ssh-agent را بررسی کنید

اگر برای مدیریت Keyها از ssh-agent استفاده می‌کنید:

ssh-add -l

را اجرا کنید.

اگر Key موردنظر وجود ندارد:

ssh-add ~/.ssh/id_ed25519

در Windows PowerShell نیز در صورت فعال بودن Agent:

ssh-add "$env:USERPROFILE\.ssh\id_ed25519"

قابل استفاده است.

بعد دوباره:

ssh -vvv user@SERVER_IP

را اجرا کنید.

اما برای Troubleshooting اولیه، مشخص‌کردن صریح Key با -i معمولاً ساده‌تر است:

ssh -i ~/.ssh/id_ed25519 user@SERVER_IP

اگر چند Key دارید، IdentitiesOnly کمک می‌کند

فرض کنید Agent شما تعداد زیادی Key دارد.

می‌توانید به SSH بگویید فقط Key مشخص‌شده را امتحان کند:

ssh -o IdentitiesOnly=yes -i ~/.ssh/production user@SERVER_IP

یا در ~/.ssh/config:

Host production
    HostName 203.0.113.10
    User deploy
    IdentityFile ~/.ssh/production
    IdentitiesOnly yes

این تنظیم برای Serverهایی که چند Identity مختلف دارید بسیار مفید است.

اگر Permissionها درست است ولی هنوز Key پذیرفته نمی‌شود

در این مرحله چند مورد پیشرفته‌تر را بررسی کنید.

SELinux

روی Distributionهایی مثل AlmaLinux، Rocky Linux یا RHEL، Contextهای SELinux هم می‌توانند روی SSH Key Authentication اثر بگذارند.

اگر فایل‌های .ssh را دستی جابه‌جا یا Restore کرده‌اید، Contextها را بررسی کنید.

در صورت نیاز و با آگاهی:

restorecon -Rv ~/.ssh

می‌تواند Context استاندارد مسیر را برگرداند.

این مرحله معمولاً برای Ubuntu لازم نیست.

الگوریتم قدیمی یا ناسازگار

اگر Client یا Server بسیار قدیمی باشد، ممکن است Algorithmهای پشتیبانی‌شده با یکدیگر سازگار نباشند.

در چنین شرایطی معمولاً Verbose Output پیام دقیق‌تری درباره Algorithm یا Signature نمایش می‌دهد.

به‌جای فعال‌کردن Algorithmهای قدیمی و ضعیف بدون بررسی، ابتدا:

• نسخه OpenSSH Client

• نسخه Server

• نوع Key

• Algorithmهای مورد قبول

را مشخص کنید.

برای بیشتر Environmentهای جدید، Keyهای Ed25519 انتخاب مناسبی هستند.

خطای Permission denied با Connection refused فرق دارد

این دو خطا را با هم اشتباه نگیرید.

Permission denied

مثلاً:

Permission denied (publickey)

معمولاً یعنی:

Server reachable ✓
SSH running ✓
Authentication failed ✗

Connection refused

Connection refused

می‌تواند نشان دهد:

SSH Service Down
Wrong Port
Firewall Reject
Service Not Listening

Connection timed out

Connection timed out

بیشتر ما را به سمت:

Network
Routing
Firewall Drop
Wrong IP
Provider Filtering

می‌برد.

بنابراین برای هرکدام مسیر Troubleshooting متفاوتی داریم.

مقاله بعدی این Cluster را به رفع خطای Connection refused در SSH اختصاص می‌دهیم.

ترتیب پیشنهادی رفع Permission denied

برای اینکه وقتتان تلف نشود، به این ترتیب جلو بروید:

1. دستور زیر را اجرا کنید:

ssh -vvv -i PRIVATE_KEY user@SERVER_IP

2. Username را بررسی کنید.

3. مطمئن شوید Key موردنظر Offering می‌شود.

4. Public Key متناظر را در authorized_keys بررسی کنید.

5. Ownership را بررسی کنید.

6. Permissionهای .ssh و authorized_keys را اصلاح کنید.

7. PubkeyAuthentication و AuthorizedKeysFile را با sshd -T بررسی کنید.

8. Ruleهایی مثل PermitRootLogin و AllowUsers را بررسی کنید.

9. هم‌زمان Log سرویس SSH را ببینید.

10. فقط پس از تشخیص علت Configuration را تغییر دهید.

[[IMAGE-4: چک‌لیست رفع Permission denied در SSH]]

چند Command کاربردی برای عیب‌یابی

Client

ssh -vvv user@SERVER_IP

با Key مشخص:

ssh -vvv -o IdentitiesOnly=yes -i ~/.ssh/id_ed25519 user@SERVER_IP

مشاهده Fingerprint:

ssh-keygen -lf ~/.ssh/id_ed25519.pub

Keyهای Agent:

ssh-add -l

Server

بررسی فایل‌ها:

ls -ld ~ ~/.ssh ~/.ssh/authorized_keys

Permission:

chmod go-w ~
chmod 700 ~/.ssh
chmod 600 ~/.ssh/authorized_keys

Configuration مؤثر SSH:

sudo sshd -T | grep -Ei 'pubkeyauthentication|authorizedkeysfile|permitrootlogin'

تست Syntax:

sudo sshd -t

مشاهده Log:

sudo journalctl -fu ssh.service

این مجموعه Commandها معمولاً اطلاعات کافی برای پیدا کردن بخش بزرگی از خطاهای Public Key Authentication فراهم می‌کند.

اگر هیچ راهی برای ورود به Server نداریم چه کنیم؟

اینجا یک مشکل عملی داریم:

برای تعمیر:

authorized_keys
sshd_config
Permissions

باید به خود Server دسترسی داشته باشیم.

اگر همه Sessionهای SSH را بسته‌اید و هیچ User دیگری وارد نمی‌شود، باید از روش دسترسی خارج از SSH استفاده کنید؛ مثلاً Console یا Recovery Console ارائه‌دهنده VPS، در صورتی که سرویس شما چنین قابلیتی داشته باشد.

بعد مشکل را از داخل Server اصلاح کنید.

به همین دلیل هنگام تغییر SSH همیشه توصیه می‌کنیم:

Session فعلی را باز نگه دارید تا Login جدید را با موفقیت تست کرده باشید.

این کار ساده می‌تواند جلوی Lockout کامل را بگیرد.

جمع‌بندی

خطای:

Permission denied (publickey)

به این معنی نیست که SSH خراب شده یا Server خاموش است.

در بیشتر موارد، اتصال تا مرحله Authentication پیش رفته اما Key موردنظر پذیرفته نشده است.

بهترین شروع این نیست که فوراً sshd_config را ویرایش کنید.

اول اجرا کنید:

ssh -vvv user@SERVER_IP

و مشخص کنید:

آیا Client اصلاً Key درست را ارائه می‌کند؟

اگر نه، سمت Client را بررسی کنید.

اگر Key درست ارائه می‌شود ولی Server آن را رد می‌کند، سراغ این موارد بروید:

Username
authorized_keys
Ownership
Permissions
PubkeyAuthentication
AuthorizedKeysFile
PermitRootLogin
Access Rules
Server Logs

در بسیاری از موارد مشکل چیزی ساده مثل Username اشتباه، Private Key اشتباه یا Permission نادرست authorized_keys است.

و مهم‌تر از همه:

هنگام تعمیر SSH چند تنظیم را هم‌زمان تغییر ندهید. یک تغییر انجام دهید، نتیجه را Verify کنید و بعد سراغ مرحله بعد بروید.

این روش هم سریع‌تر است، هم احتمال قطع کامل دسترسی به Server را کاهش می‌دهد.

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

خطای Permission denied (publickey) یعنی چه؟

یعنی SSH Client به Server رسیده اما Public Key Authentication موفق نشده است. Server کلید ارائه‌شده را نپذیرفته یا Client اصلاً Key موردانتظار را ارائه نکرده است.

اولین کار برای رفع این خطا چیست؟

اتصال را با حالت Verbose اجرا کنید:

ssh -vvv user@SERVER_IP

و بررسی کنید Username صحیح است و Key موردنظر در خروجی Offering public key دیده می‌شود.

Permission مناسب authorized_keys چیست؟

یک تنظیم رایج:

chmod 700 ~/.ssh
chmod 600 ~/.ssh/authorized_keys

است. همچنین فایل‌ها باید متعلق به User صحیح باشند و Home یا فایل‌های Authentication نباید به‌صورت ناامن توسط دیگران قابل تغییر باشند.

چرا Key روی Server وجود دارد ولی SSH آن را قبول نمی‌کند؟

ممکن است Public Key برای User دیگری باشد، Owner یا Permission فایل اشتباه باشد، مسیر AuthorizedKeysFile تغییر کرده باشد، Public Key Authentication محدود شده باشد یا Ruleهای SSH مانع Login همان User شوند.

چگونه Private Key صحیح را به SSH معرفی کنیم؟

با -i:

ssh -i ~/.ssh/id_ed25519 user@SERVER_IP

و برای اطمینان از استفاده فقط از همان Identity:

ssh -o IdentitiesOnly=yes -i ~/.ssh/id_ed25519 user@SERVER_IP

برای دیدن علت خطا در سمت Server چه کنیم؟

در Ubuntu می‌توانید:

sudo journalctl -fu ssh.service

را اجرا کنید و هم‌زمان از Client دوباره Login را امتحان کنید.