SSH Permission Denied (publickey): الإصلاح الحقيقي

في الثانية عشرة والدقيقة العاشرة فجرًا مات نشرٌ على سطرٍ كتبته ألف مرة: ssh deploy@staging → Permission denied (publickey). المفتاح سليم. العرض لم يكن.

الخلاصة: Permission denied (publickey) يعني أن كل مفتاح قدّمه العميل رفضه الخادم — حكم تفاوض لا خطأ إملائي في كلمة مرور. شخّص بـ ssh -vvv (أي مفاتيح قُدمت) وسجل الخادم journalctl -u ssh (أي مفاتيح رُفضت ولماذا). ثم أصلح أحد الأسباب الأربعة: مستخدم خاطئ، مفتاح غائب من authorized_keys، أذونات مفتوحة أكثر من اللازم، أو مفتاح ssh-rsa رفضه OpenSSH 8.8+. وssh-copy-id يمنع معظم التكرارات.

$ ssh -T [email protected]
[email protected]: Permission denied (publickey).

الخطأ حكم لا تلميح: كل ما في العرض رُفض.

لماذا يقول SSH “Permission denied (publickey)“؟

مصادقة المفتاح العام تفاوض عرضٍ ورفض. يعرض العميل كل مفتاح يجده — هويات من وكيلك، من ~/.ssh/config، أسماء الملفات الافتراضية (id_ed25519، id_rsa) وكل ما مررته بـ -i. ويقارن الخادم كل عرض بـ ~/.ssh/authorized_keys للحساب الهدف. حين لا يطابق شيء، ومصادقة كلمة المرور معطلة أو مستنفدة، يطبع العميل السطر الواحد الذي حفظه كل مهندس devops.

حقيقتان مهمتان للتصحيح. الأولى: الرسالة لا تخبرك بأي مستخدم صدمت — نصف الحالات مفتاح ممتاز جالس في authorized_keys لحساب آخر. والثانية أن الخادم سبقك إلى السبب: يسجل sshd كل عرض مرفوض. وتتبع الاستدعاء الذي لم يطلبه أحد ويحتاجه الجميع هو -vvv.

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

ssh -vvv deploy@staging 2>&1 | grep -iE "offering|identity|denied|authentications"
# debug1: Offering public key: /home/you/.ssh/id_ed25519 RSA-SHA256 (explicit)
# debug1: Authentications that can continue: publickey
# deploy@staging: Permission denied (publickey).

اقرأ ثلاثة أسطر: Offering public key (ما اقترحه العميل)، وAuthentications that can continue (ما سيتقبله الخادم بعد ذلك — إذا غاب password فلن يأتي أي سؤال كلمة مرور)، والحكم النهائي. وإذا لم يظهر مفتاحك المقصود في قائمة العرض، فالمشكلة في جانب العميل: مسار -i خاطئ، أو IdentityFile في ~/.ssh/config نسيتَه، أو وكيل (ssh-add -l) يحمل هوية عتيقة تجيب أولًا.

ما الأسباب الأربعة الحقيقية؟

السبب	العلامة	الإصلاح
مستخدم خاطئ	المفتاح يعمل مع root@host ويفشل مع deploy@host	يجب أن يكون المفتاح في ~/.ssh/authorized_keys لذلك المستخدم
المفتاح غير مثبت	يظهر السجل Failed publickey لكل عرض	ssh-copy-id user@host
أذونات مفتوحة	العميل: WARNING: UNPROTECTED PRIVATE KEY FILE — يُتجاهل المفتاح ولا يُعرض	chmod 700 ~/.ssh; chmod 600 ~/.ssh/*
مفتاح ssh-rsa قديم	الخادم يشغّل OpenSSH 8.8+؛ مفتاح RSA القديم لا يقبل قط	أعد توليده بصيغة ed25519 أو رقّ المفتاح

وسبب الأذونات يستحق ملاحظة خاصة لأن OpenSSH ينفذها بصرامة: المفتاح الخاص القابل للقراءة من المجموعة أو العالم يرفضه العميل نفسه ويسقط بصمت من العرض. والإصلاح أمران:

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

وسبب ssh-rsa يزحم صور CI القديمة وRaspberry Pi: عطّل OpenSSH 8.8 (الصادر 2021-10-01، openssh.com/txt/release-8.8) توقيعات ssh-rsa — المتغير المعتمد على SHA-1 — افتراضيًا. وبحسب ملاحظات الإصدار: “the ssh-rsa signature scheme is … disabled by default”. مفتاح RSA وُلد عام 2018 ليس مكسورًا؛ صيغة توقيعه فقط لم تعد محل حديث. توليد مفتاح ed25519 (ssh-keygen -t ed25519) هو الجواب الدائم، وأجهزة التحكم السحابية تمنحك وحدة تحكم تسلسلية حين تقفل نفسك في منتصف الإصلاح.

كيف أرى لماذا رفض الخادم المفتاح؟

السجل من جهة الخادم هو الشاهد الصادق. على Ubuntu (systemd)، يسجل sshd حكمًا لكل عرض:

journalctl -u ssh -n 50 --no-pager | grep -iE "publickey|denied|accepted"
# sshd[4421]: Failed publickey for deploy from 203.0.113.7 port 51422 ssh2: RSA SHA256:...
# sshd[4421]: Accepted publickey for deploy from 203.0.113.7 port 51422 ssh2: ED25519 SHA256:...

Failed publickey مع بصمة لم تتوقعها يعني أن العميل عرض مفتاحًا غير الذي ظننت — عد إلى -vvv. وFailed publickey مع بصمتك يعني أن المفتاح صحيح لكنه غير مثبت لذلك الحساب، أو أن أذونات المجلد المنزلي من جهة الخادم خاطئة (القاعدة 700/600 نفسها تنطبق على ~/.ssh و~/.ssh/authorized_keys في الخادم). وإذا رفض sshd البدء وأنت تعدّل التكوينات فذلك صيد مختلف — انظر خدمة systemd لا تبدأ.

كيف أثبّت مفتاحي بالطريقة الصحيحة؟

ssh-copy-id deploy@staging
# Number of key(s) added: 1
ssh -o BatchMode=yes deploy@staging 'echo ok'   # إثبات بلا تفاعل

يُلحق ssh-copy-id مفتاحك العام بـ authorized_keys للحساب الهدف ويضبط أذونات معقولة — وهو موجود لأن اللصق اليدوي في authorized_keys يفشل عند سطر جديد زائد أو مجلد مفقود بمعدل مزعج بالكاد. وفحص BatchMode هو الاختبار الحقيقي: يعطل كل الأسئلة، فالنجاح يعني أن المفتاح وحده حمل الدخول. وحين يعمل المفتاح يرث scp وrsync المصادقة نفسها مجانًا — والاختيار بينهما شأن عرض النطاق لا بيانات الاعتماد (rsync مقابل scp).

الفرز في 30 ثانية

ssh -vvv user@host 2>&1 | grep -i offering      # 1. أي مفاتيح عُرضت؟
journalctl -u ssh -n 50 | grep -i publickey     # 2. لماذا رُفضت؟
ls -ld ~/.ssh ~/.ssh/authorized_keys            # 3. 700 / 600؟
ssh-copy-id user@host                           # 4. ثبّت، ثم تحقق بـ BatchMode

Permission denied (publickey) نتيجة تفاوض لا سؤال كلمة مرور — رفض الخادم كل مفتاح في العرض، وسجله يعرف السبب من قبل.

شغّل الأوامر الأربعة بالترتيب ويتوقف الفشل عن الغموض: أحدها يسمّي الفاعل في كل مرة. كان حالي هويةً عتيقة للوكيل تجيب قبل المفتاح الصحيح — ssh-add -d، وذهب النشر إلى الأخضر في 02:31.