حل خطأ SSH ‏Permission denied (publickey)

ما الذي يعنيه 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 مفقوداً من تلك القائمة الأولى، فهذا يعني أن الخادم عطّل تسجيل الدخول باستخدام المفتاح العام، ولذلك لن يعمل أي مفتاح.

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

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

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

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

السبب 1: أنت تتصل باسم المستخدم الخطأ

السبب الأكثر شيوعاً هو أيضاً الأقل إثارة للاهتمام. لا يخبرك sshd، وهو daemon خادم SSH (secure 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، والنسخ الخاصة بالأجهزة و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 المحاولة بالملف الذي مررته. اعرض المفاتيح التي يحتفظ بها agent باستخدام 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، ثم أعد تحميل الخدمة. بعد ذلك يسجّل كل إ attempt بصمة المفتاح التي استلمها الخادم فعلياً:

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. افتح وحدة تحكم مزوّد الخدمة عبر الاتصال التسلسلي أو 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 تحت اسم افتراضي، ولم يُحمّل في 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 أو المجلد الرئيسي قابل للكتابة من قبل المجموعة أو جميع المستخدمين، أو مملوك لحساب غير صحيح. لا يثق 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 من وحدة التحكم أولاً، ثم أصلح الملف.