SSD Nodes Learn 🎉 VPS من $5.50/شهر
الأدلة Matt Connorبقلم Matt Connor

حل خطأ SSH ‏Permission denied (publickey) بخمس خطوات

يخفي الخطأ Permission denied (publickey) خمسة أعطال مختلفة. اقرأ 3 أسطر من خرج ssh -v لتحدد السبب وتصلحه دون أن تفقد الوصول إلى الخادم.

ما الذي يعنيه Permission denied (publickey) فعلياً

تعني Permission denied (publickey) أن العميل أرسل مفتاحاً عاماً واحداً أو أكثر، وأن الخادم لم يقبل أياً منها. الشبكة تعمل، وsshd قيد التشغيل؛ ويحدث الرفض في الخطوة الأخيرة من المصادقة. لا تعتمد المعالجة على التخمين، لأن ssh -v يحدد أيّاً من خمسة أسباب ينطبق عليك.

توضح الكلمات بين القوسين طرق المصادقة التي كان الخادم مستعداً لقبولها. تعني Permission denied (publickey) وحدها أن تسجيل الدخول بكلمة المرور معطّل على ذلك الخادم، ولذلك لا توجد كلمة مرور يمكن استخدامها كخيار بديل. وتعني Permission denied (publickey,password) أن كلمات المرور كانت متاحة، لكن محاولاتك باستخدامها فشلت أيضاً.

تغطي رسالة واحدة خمسة أعطال منفصلة، وهي مبهمة عمداً. فإذا ردّ الخادم بعبارة «لا يوجد مستخدم بهذا الاسم» أو «هذا المفتاح غير مثبّت»، فسيساعد ذلك أي شخص يبحث عن الحسابات الصالحة. لذلك لا تبدأ بتبديل المفاتيح وتعديل ملفات الإعداد. نفّذ أمراً واحداً، واقرأ 3 أسطر من الخرج، وستنخفض الأسباب المحتملة الخمسة إلى سبب واحد.

شغّل ssh -v أولاً، واقرأ 3 أسطر

كرّر الأمر الذي فشل، مع إضافة -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).

تحتوي 3 أسطر على كل ما تحتاج إليه.

Authenticating to 203.0.113.10:22 as 'deploy' هو اسم المستخدم الذي سيُستخدم فعلياً. ليس الاسم الذي قصدت استخدامه، بل الاسم الذي استنتجه ssh من سطر الأوامر، أو من ~/.ssh/config، أو من اسم تسجيل الدخول المحلي لديك.

Authentications that can continue: publickey هي قائمة طرق المصادقة المقبولة على الخادم، ويُرسلها قبل تجربة أي مفتاح. إذا كان publickey مفقوداً من تلك القائمة الأولى، فهذا يعني أن تسجيل الدخول باستخدام المفتاح العام معطّل على الخادم، ولذلك لن يعمل أي مفتاح.

Offering public key: ... هو سطر واحد لكل مفتاح أرسله العميل فعلياً، مع اسم الملف الذي أُخذ منه وبصمة SHA256 الخاصة به. إذا لم يظهر للمفتاح سطر Offering، فلم يُرسل ذلك المفتاح إلى الخادم قط.

قسّم المشكلة الآن إلى جزأين:

  • لا يوجد سطر Offering public key للمفتاح الذي تتوقعه. الخلل في جهازك، لأن الخادم لم يستلم مفتاحك أصلاً.
  • عُرض المفتاح، ثم ظهر Authentications that can continue: publickey مرة أخرى. استلم الخادم ذلك المفتاح ورفضه، ولذلك فالخلل في الخادم.

الأسباب أدناه مرتبة حسب مدى تكرار كونها السبب الفعلي.

السبب 1: تتصل باسم مستخدم غير صحيح

السبب الأكثر شيوعاً هو أيضاً الأقل أهمية. لا يخبرك sshd، وهو البرنامج الخدمي لخادم SSH (shell الآمن)، بأن الحساب غير موجود. ينفّذ التبادل كاملاً باسم مستخدم مختلق، ثم يرفض الاتصال في نهايته بالرسالة نفسها، لأن كشف أسماء الحسابات الصحيحة يساعد المهاجم. ويبدو الخطأ المطبعي في اسم المستخدم تماماً كأنه مشكلة في المفتاح.

تحقق من سطر Authenticating to ... as قبل أي شيء آخر. إذا كان يذكر اسم تسجيل الدخول على حاسوبك المحمول بدلاً من حساب الخادم، فقد حذفت اسم المستخدم من الأمر.

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

يعتمد الحساب الافتراضي على الصورة التي ينشئها مزود الخدمة. اعتباراً من August 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، ومتغيرات hardware وDSA لهذه الأسماء. يكون المفتاح المحفوظ باسم ~/.ssh/vps-prod غير مرئي لـ ssh حتى تحدده بالاسم، ولذلك لا يعرض الإخراج التفصيلي أي سطر Offering public key له.

حدّد الملف، وامنع مفاتيح الوكيل من التقدم عليه:

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

لا يكفي استخدام -i وحده عندما يحتوي الوكيل على مفاتيح، لأن ssh يظل يعرض مفاتيح الوكيل أولاً والملف المحدد أخيراً. وهذا مهم لأن الخادم يحتسب كل مفتاح مرفوض ضمن MaxAuthTries، الذي تكون قيمته الافتراضية 6. يمكن لوكيل يحتوي على سبعة مفاتيح أن يستنفد الحد قبل الوصول إلى مفتاحك الصحيح، وعندها تتغير الرسالة إلى:

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

يحد IdentitiesOnly=yes المحاولات بالملف الذي مررته فقط. اعرض المفاتيح الموجودة لدى الوكيل باستخدام ssh-add -l، وامسحها باستخدام ssh-add -D إذا كان قد جمع مفاتيح قديمة على مدى سنوات. ثم دوّن الإعدادات حتى لا يعتمد تسجيل الدخول التالي على تذكّر الخيارات:

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

هناك مشكلة أخرى من جهة العميل. يرفض ssh استخدام مفتاح خاص يمكن للحسابات الأخرى على جهازك قراءةُه. ويطبع تحذيراً ثم يتجاهل المفتاح، لذلك لا يُعرض المفتاح أبداً ولا يراه الخادم:

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

يصلح chmod 600 ~/.ssh/vps-prod ذلك. يُعد نقل المفتاح عبر وحدة USB أو مشاركة Windows الطريقة المعتادة لفقدان الوضع. يوضّح أساسيات إدارة مفاتيح 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 بصمة واحدة لكل إدخال:

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، أو حدث العكس. الملف خاص بكل حساب، ولا يوجد ملف مشترك بين الحسابات.
  • كتب مربع مزود الخدمة "إضافة مفتاحي" المفتاح إلى المستخدم الافتراضي للصورة فقط، ولذلك يكون مجلد .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 العمل نفسه ويضبط الأذونات بالشكل الصحيح تلقائياً.

السبب 4: لماذا يتجاهل sshd ملف authorized_keys عندما تكون الصلاحيات واسعة جداً

StrictModes yes هو الإعداد الافتراضي لـ sshd. بموجبه، يرفض sshd قراءة authorized_keys إذا كان هذا الملف، أو الدليل .ssh، أو الدليل الرئيسي للحساب قابلاً للكتابة من أي مستخدم غير المالك. السبب مباشر: إذا كان بإمكان المجموعة أو جميع المستخدمين الكتابة في دليلك الرئيسي، فيمكن لأي حساب يملك ذلك الوصول استبدال 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:

  • الدليل الرئيسي: غير قابل للكتابة من المجموعة وغير قابل للكتابة من جميع المستخدمين. 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 أو أكثر تقييداً، وأن يكون drwx------ على .ssh. إذا لم تكن هذه السلاسل واضحة بعد، فاقرأ كيفية قراءة سلسلة صلاحيات مثل drwxr-xr-x قبل تغيير الأوضاع على خادم قيد التشغيل.

في Rocky Linux وAlmaLinux، أضف SELinux (Linux المحسّن للأمان) إلى قائمة الاحتمالات. قد يحمل دليل .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 بأول قيمة يعثر عليها لأي إعداد. لذلك يُقرأ ملف الإعداد المنفصل مثل 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. عندها يُتجاهل الملف الموجود في الدليل الرئيسي بالكامل، وتنطبق قواعد الأذونات من السبب 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 القديم. إذا كان المفتاح محمياً بعبارة مرور، فسيطلب الأمر إدخالها، وهذا يثبت أيضاً أنك ما زلت تعرف عبارة المرور.

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

يطبع الأمر الأول بصمة ملف مفتاح عام واحد. ويطبع الأمر الثاني البصمات التي يحتفظ بها الوكيل. طابق الآن أربع طرق لعرض السلسلة نفسها: البصمة الموجودة في سطر 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 ثم أعد تحميل الخدمة. بعد ذلك، تسجّل كل محاولة بصمة المفتاح التي استلمها الخادم فعلياً:

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

يوضح لك هذا السطر أي جانب فيه الخلل. إذا تعرّفت على البصمة، فهذا يعني أن مفتاحك وصل ورفضه الخادم، لذا افحص الأسباب 3 و4 و5. إذا لم تتعرّف على البصمة، فهذا يعني أن العميل أرسل مفتاحاً لم تقصده، لذا ارجع إلى السبب 2.

عندما يظل السجل غير واضح، شغّل نسخة ثانية من sshd على منفذ آخر في وضع التصحيح. ستبقى هذه النسخة في المقدمة، وتخدم اتصالاً واحداً، وتطبع آلية اتخاذ القرار، ثم تنتهي:

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 جدار الحماية خارج الاختبار. يوضح خرج التصحيح اسم الملف الذي فتحه، والبصمة التي قارنها، وسبب الرفض الدقيق، بما في ذلك أسطر مثل Authentication refused: bad ownership or modes for directory /home/deploy. اضغط Ctrl+C بعد معرفة السبب. تظل خدمة sshd الفعلية على المنفذ 22 دون تغيير طوال العملية.

كيفية تجنّب فقدان الوصول

تحتاج كل خطوة تعدّل إعدادات الخادم إلى وسيلة وصول بديلة لا تعتمد على SSH. أعدّ هذه الوسيلة أثناء استمرار SSH في العمل، وليس بعد تعطّله.

  1. افتح وحدة التحكم الخاصة بمزوّد الخدمة عبر serial أو VNC (الحوسبة الشبكية الافتراضية)، وتأكد من قدرتك على تسجيل الدخول إليها.
  2. تأكد من معرفتك بكلمة مرور محلية صالحة لحساب يملك صلاحية sudo. إذا لم تكن لديك كلمة مرور، أعد تعيين كلمة مرور root من وحدة تحكم مزوّد الخدمة أولاً.
  3. أبقِ جلسة SSH الحالية مفتوحة. تستمر الجلسة المفتوحة بعد systemctl restart ssh، ولذلك تبقى وسيلة للوصول مجدداً إذا كان الإعداد الجديد خاطئاً.
  4. افحص الصياغة قبل إعادة التشغيل: يعرض sudo sshd -t لا شيء عندما يكون الملف صالحاً، ويعرض اسم الملف ورقم السطر عندما يكون غير صالح.
  5. افتح طرفية ثانية وسجّل الدخول من جديد قبل إغلاق الطرفية الأولى. يمنع الإعداد المعطّل عمليات تسجيل الدخول الجديدة ويترك الجلسات الحالية دون تغيير، لذلك لا يمكن للجلسة المفتوحة أمامك أن تؤكد نجاح التغيير.

أعد التشغيل باستخدام sudo systemctl restart ssh على Debian وUbuntu، أو باستخدام sudo systemctl restart sshd على Rocky Linux وAlmaLinux. في Ubuntu 24.04، يبدأ sshd من وحدة socket، لذلك يحتاج التغيير في Port أو ListenAddress أيضاً إلى sudo systemctl restart ssh.socket قبل أن يصبح نافذاً.

FAQ

لماذا تظهر رسالة Permission denied (publickey) رغم أن المفتاح نفسه يعمل على خادم آخر؟

لأن المفتاح سليم، لكن هناك مشكلة في أحد المكونات المحيطة به. شغّل ssh -v وابحث عن السطر Offering public key. إذا لم يكن مفتاحك مدرجاً، فهذا يعني أن ssh لم يرسله: فالملف ليس موجوداً في ~/.ssh باسم افتراضي، ولم يُحمّل في الوكيل، لذا أضفه باستخدام -i /path/to/key -o IdentitiesOnly=yes. إذا كان المفتاح مدرجاً وما زال الخادم يرفضه، فإما أن المفتاح مفقود من authorized_keys الخاص بالحساب، أو أن المسار المؤدي إليه قابل للكتابة من مجموعة، أو أن إعداد sshd يمنع المستخدم. يميّز سجل الخادم بين هذه الحالات.

كيف أعرف أي مفتاح يرسله SSH فعلياً؟

يطبع ssh -v host سطراً واحداً من debug1: Offering public key: لكل مفتاح، ويتضمن كل سطر اسم الملف المصدر وبصمة SHA256. يعرض ssh-add -l بصمات المفاتيح التي يحتفظ بها الوكيل. يطبع 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 أو الدليل الرئيسي قابل للكتابة من المجموعة أو من جميع المستخدمين، أو مملوك للحساب الخطأ. لن يثق sshd بمسار يستطيع شخص آخر تغييره، ولذلك يتصرف كما لو لم يوجد أي مفتاح. اضبط أذونات الدليل الرئيسي على 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 افتراضياً، ولذلك يُرفض الآن المفتاح الذي لا يستطيع التوقيع إلا بهذه الطريقة. يعرض خرج العميل المطوّل 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 من وحدة التحكم أولاً، ثم أصلح الملف.

#SSH#openssh#troubleshooting#permissions#vps