إصلاح خطأ SSH: Too many authentication failures

ما المقصود بالرسالة "Too many authentication failures"

تعني الرسالة "Too many authentication failures" أن عميل SSH عرض على الخادم مفاتيح أكثر من العدد الذي كان الخادم مستعداً لفحصه، فأغلق الخادم الاتصال قبل تجربة مفتاحك الصحيح. هذه مشكلة في العميل في معظم الحالات. يوجد المفتاح على القرص، ويحتوي الخادم على المفتاح في authorized_keys، لكن لا تفيد أي من هاتين الحقيقتين لأن الاتصال انتهى مبكراً جداً.

تسلسل العملية كالتالي. يحتوي ssh-agent على كل المفاتيح الخاصة التي حمّلتها إليه. يعرض عميلك هذه المفاتيح على الخادم واحداً تلو الآخر، لأنه لا يستطيع معرفة المفتاح الذي يقبله الحساب. يرفض الخادم كل مفتاح غير موجود في authorized_keys، ويحتسب كل رفض كمحاولة مصادقة فاشلة. يحدّد MaxAuthTries في sshd_config عدد محاولات الفشل المسموح بها في اتصال واحد. القيمة الافتراضية هي 6. إذا كان agent يحتوي على عشرة مفاتيح وكان المفتاح الصحيح هو الثامن في الترتيب، فسيغلق الخادم الاتصال قبل الوصول إليه.

لذلك، يكمن الحل في جعل العميل يعرض مفتاحاً واحداً فقط: المفتاح الصحيح.

ما الذي يحسبه الخادم، وما علاقة MaxAuthTries بذلك

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

تصف صفحة الدليل sshd_config(5) الحدّ كما يلي: «تحدد الحد الأقصى لعدد محاولات المصادقة المسموح بها لكل اتصال. بعد أن يصل عدد حالات الفشل إلى نصف هذه القيمة، تُسجَّل حالات الفشل الإضافية. القيمة الافتراضية هي 6».

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

error: maximum authentication attempts exceeded for deploy from 203.0.113.10 port 51292 ssh2

يطبع عميلك النصف الآخر من الحدث نفسه:

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

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

لماذا يعمل المفتاح نفسه من حاسوب زميلك المحمول

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

يزداد العدد بهدوء. يضيف AddKeysToAgent yes في ~/.ssh/config كل مفتاح تستخدمه إلى الوكيل ويُبقيه فيه. تحمّل وكلاء مخزن المفاتيح على سطح المكتب، مثل GNOME Keyring في Linux أو login keychain في macOS، المفاتيح عند تسجيل الدخول من دون طلب تأكيد. أضف مفتاح عميل، ومفتاح مضيف Git، ومفتاح خادم مختبر خلال عام، ثم يبدأ خادم كان يعمل دائماً برفض اتصالك. لم يتغير شيء على الخادم. أصبح وكيلك ممتلئاً بالمفاتيح.

كيفية عرض المفاتيح المقدَّمة باستخدام ssh -v

شغّل الاتصال الفاشل مع -v واقرأ التتبّع.

ssh -v deploy@203.0.113.10

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

debug1: Will attempt key: /home/you/.ssh/id_ed25519 ED25519 SHA256:AAAA... agent
debug1: Will attempt key: /home/you/.ssh/id_rsa RSA SHA256:BBBB... agent
debug1: Offering public key: /home/you/.ssh/id_ed25519 ED25519 SHA256:AAAA... agent
debug1: Authentications that can continue: publickey,password
debug1: Offering public key: /home/you/.ssh/id_rsa RSA SHA256:BBBB... agent

ستختلف المسارات وأنواع المفاتيح وبصمات الأصابع لديك. ما تعدّه هو عدد أسطر Offering public key: قبل قطع الاتصال. إذا استمر عرض المفاتيح وانتهت الجلسة من دون ظهور المفتاح المقصود، فقد حُسم التشخيص. تعني الكلمة agent في نهاية السطر أن تلك الهوية جاءت من ssh-agent. وتعني الكلمة explicit أنها جاءت من سطر IdentityFile أو من -i في سطر الأوامر.

بعد ذلك، اسأل الوكيل عمّا يحتفظ به:

ssh-add -l

كل سطر في الناتج يمثّل مفتاحاً محمّلاً. إذا طبع The agent has no identities.، فالمشكلة ليست في الوكيل، وعليك فحص أسطر IdentityFile في ~/.ssh/config بدلاً من ذلك. وإذا طبع Could not open a connection to your authentication agent.، فلا يوجد وكيل قيد التشغيل، والمفاتيح المقدَّمة تأتي من ملفات المفاتيح الافتراضية لديك.

الإصلاح 1: استخدام IdentitiesOnly مع مفتاح واحد لكل مضيف

يخبر IdentitiesOnly yes ‏ssh بتقديم الهويات التي ضبطتها فقط، وتجاهل الهويات الإضافية التي يعرضها agent تلقائياً. استخدمه مع سطر IdentityFile، وعندها يرسل العميل عرضاً واحداً.

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

احفظ ذلك في ~/.ssh/config، ثم شغّل chmod 600 ~/.ssh/config. إذا كان الملف قابلاً للكتابة من المجموعة أو من جميع المستخدمين، فسيرفض ssh التشغيل مع ظهور Bad owner or permissions on /home/you/.ssh/config. الآن سيعرض ssh vps مفتاحاً واحداً، ويجب أن يعرض ssh -v vps سطر Offering public key: واحداً بالضبط.

هناك تفصيلان يفاجئان بعض المستخدمين.

• لا يعني IdentitiesOnly yes وحده «مفتاحاً واحداً». تُحتسب ملفات الهوية الافتراضية ضمن الهويات المضبوطة، ولذلك يواصل ssh تجربة ~/.ssh/id_ed25519 و~/.ssh/id_rsa والافتراضيات الأخرى التي يجدها. تحتاج إلى سطر IdentityFile أيضاً.
• يظل agent هو الذي ينفّذ التوقيع. يتحكم IdentitiesOnly في المفاتيح التي تُعرض، وليس في الجهة التي تنفّذ التوقيع. إذا كان المفتاح الخاص الذي يشير إليه IdentityFile محمّلاً في agent، فسينشئ agent التوقيع ولن يُطلب منك إدخال عبارة المرور. ويمكنك حتى توجيه IdentityFile إلى ملف .pub المطابق، وهذا ما تفعله عندما يكون المفتاح الخاص موجوداً فقط في agent أو في hardware token.

يوجد فخ في ~/.ssh/config يُبطل هذا الإصلاح بصمت. تأخذ معظم الكلمات المفتاحية القيمة الأولى التي يعثر عليها، ولذلك يجب وضع كتل Host المحددة قبل Host *. لكن IdentityFile لا يتبع هذه القاعدة. يذكر الدليل: «يمكن تحديد عدة ملفات هوية في ملفات الإعداد؛ وستُجرَّب جميع هذه الهويات بالتتابع». تتم إضافة IdentityFile الموجود تحت Host * إلى الإعداد الخاص بالمضيف، ولا يستبدل به. لذلك يعيد سطر عام منسي عرضاً إضافياً إلى كل اتصال.

إذا أردت شبكة أمان عامة، فاضبط العلم فقط في أسفل الملف:

Host *
  IdentitiesOnly yes

بعد ذلك يحتاج كل مضيف إلى IdentityFile الخاص به، وهذا هو الناتج المطلوب في كل الأحوال. كما أن تسمية مفتاح واحد لكل خادم تتيح لك إبطال وصول جهاز واحد لاحقاً دون إعادة إصدار كل المفاتيح. من المفيد ترسيخ هذه الممارسة مبكراً: راجع كيفية إدارة مفاتيح SSH لكل جهاز.

الإصلاح 2: تنظيف الوكيل أو إعادة تشغيله

إذا لم تتمكن من تعديل الإعداد بعد، فأفرغ الوكيل وحمّل ما تحتاج إليه فقط.

ssh-add -l                    # list what is loaded
ssh-add -d ~/.ssh/id_rsa      # remove one key
ssh-add -D                    # remove every key
ssh-add ~/.ssh/id_ed25519_vps # load the one you need

إذا نجح الاتصال مباشرة بعد ssh-add -D، فالوكيل هو سبب المشكلة. اعتبر ذلك اختباراً، وليس إصلاحاً. يعيد وكيل حلقة مفاتيح سطح المكتب تحميل مفاتيحه عند تسجيل الدخول التالي، لذلك ستعود المشكلة غداً. يبقى سطر IdentitiesOnly في ~/.ssh/config بعد إعادة التشغيل. أما الوكيل الفارغ فلا يبقى كذلك.

يمكنك أيضاً تحديد مدة صلاحية للمفتاح كي يزيله الوكيل تلقائياً:

ssh-add -t 1800 ~/.ssh/id_ed25519_vps

يُحذف المفتاح بعد 1800 ثانية من إضافته. وتنجح إعادة تشغيل الوكيل أيضاً، لكن طريقة تنفيذها تعتمد على الجهة التي شغّلته. يتوقف ssh-agent الذي شغّلته بنفسك باستخدام ssh-agent -k. وإذا كنت تشغّله من خلال وحدة systemd للمستخدم أنشأتها بنفسك، فأعد تشغيل تلك الوحدة باستخدام systemctl --user restart <unit>. يُعاد تشغيل وكيل حلقة المفاتيح مع جلسة سطح المكتب.

الإصلاح 3: أمر لمرة واحدة لخادم تتصل به مرة واحدة

بالنسبة إلى مضيف لن تضيفه إلى إعداداتك، ضع الإعدادات نفسها في سطر الأوامر:

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

استخدام -i وحده هو الإصلاح الخاطئ الأكثر شيوعاً. يضيف -i مفتاحاً إلى قائمة الهويات. لكنه لا يزيل مفاتيح الـagent من تلك القائمة، لذلك تُرسَل جميع عروض المفاتيح الأخرى قبل مفتاحك، ويظل الاتصال يفشل عند بلوغ الحد. شغّل ssh -v -i ~/.ssh/id_ed25519_vps deploy@203.0.113.10 من دون IdentitiesOnly، وستراقب إرسال مفاتيح الـagent أولاً. يحتاج -i إلى -o IdentitiesOnly=yes بجانبه.

لإخراج الـagent من العملية تماماً في اتصال واحد:

ssh -o IdentityAgent=none -i ~/.ssh/id_ed25519_vps deploy@203.0.113.10

يقرأ ssh بعد ذلك المفتاح الخاص من القرص ويطلب عبارة مروره إذا كانت موجودة.

تقبل الأدوات المبنية على ssh الخيار نفسه:

scp -o IdentitiesOnly=yes -i ~/.ssh/id_ed25519_vps report.tar.gz deploy@203.0.113.10:/tmp/
rsync -av -e "ssh -o IdentitiesOnly=yes -i ~/.ssh/id_ed25519_vps" ./site/ deploy@203.0.113.10:/srv/site/
GIT_SSH_COMMAND="ssh -o IdentitiesOnly=yes -i ~/.ssh/id_ed25519_vps" git clone git@example.com:team/repo.git

لماذا يظهر الخطأ عند القفزة الثانية

مع ForwardAgent yes، تصبح مقبس الوكيل متاحة على الخادم الذي تتصل به. يستخدم أمر ssh الذي يُنفَّذ على ذلك الخادم وكيلك المحلي، مع جميع مفاتيحك، عبر المقبس المُمرَّر. لذلك قد يظهر الخطأ عند الانتقال من مضيف القفز إلى الخادم النهائي، رغم نجاح القفزة الأولى. نفّذ echo $SSH_AUTH_SOCK على الجهاز الوسيط: يدل ظهور مسار مقبس على إمكانية الوصول إلى وكيل مُمرَّر، بينما تعني النتيجة الفارغة عدم وجوده.

يترتب على تمرير الوكيل خطر إضافي. يستطيع أي شخص يملك صلاحيات root على الجهاز الوسيط استخدام وكيلك للمصادقة بهويتك طوال مدة بقاء جلستك مفتوحة. يتجنب ProxyJump المشكلتين معاً:

ssh -J deploy@jump.example.com deploy@10.0.0.5

يفتح ProxyJump اتصالاً عبر مضيف القفز، ويُجري المصادقة على الخادم النهائي من جهازك أنت. لذلك يُطبَّق ~/.ssh/config المحلي لديك في كل قفزة، بما في ذلك IdentitiesOnly. يُعد إيقاف ForwardAgent خطوة قياسية عند تعزيز أمان SSH على VPS.

هل ينبغي أن ترفع MaxAuthTries على الخادم؟

عادةً لا. تحقّق من القيمة الحالية أولاً:

sudo sshd -T | grep -i maxauthtries

يعرض sshd -T الإعداد الفعّال، بما في ذلك القيم الافتراضية. لذلك يعرض القيمة الفعلية حتى عندما لا يذكر sshd_config شيئاً عنها. أضف -C user=deploy,host=example.com,addr=203.0.113.10 إذا كنت تستخدم كتل Match، لأن هذه الكتل تُقيَّم لكل اتصال، ويُتجاوز عنها بخلاف ذلك.

رفع الحد ينجح بالمعنى الضيق فقط، إذ يمنح العدد الأكبر عميلاً سيئ السلوك مجالاً أوسع:

MaxAuthTries 20

تحقّق من صحة الملف وأعد تحميل الخدمة، وأبقِ جلسة ثانية مفتوحة أثناء ذلك:

sudo sshd -t
sudo systemctl reload ssh      # Debian and Ubuntu
sudo systemctl reload sshd     # RHEL family

إذا أبلغ systemctl is-enabled ssh.socket عن enabled في Ubuntu 24.04، فهذا يعني أن sshd يُفعَّل عبر socket: تبدأ عملية جديدة لكل اتصال وتقرأ sshd_config من جديد، لذلك تلتقط الاتصالات الجديدة التغيير تلقائياً.

انظر الآن إلى أثر هذا التغيير. يقدّم العميل مفاتيح لن يقبلها هذا الخادم مطلقاً. رفع الحد يعني أن الخادم سيعالج عشرين مفتاحاً مرفوضاً لكل اتصال بدلاً من ستة، وذلك لكل عميل يتصل ولكل من يحاول تخمين كلمات المرور على الإنترنت. يتطلب كل عرض مفتاح عملية بحث في authorized_keys. سيظل تسجيل دخولك بطيئاً، لأن المفتاح الصحيح ما زال في نهاية القائمة. أضف مفتاحاً ثالث عشر إلى agent الخاص بك، وستعود إلى المشكلة نفسها وتطلب رقماً أكبر مرة أخرى.

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

لماذا يمكن أن يحظرك fail2ban بسبب ذلك

في مستوى السجل الافتراضي، يسجّل sshd كل مفتاح عام مرفوض:

Failed publickey for deploy from 203.0.113.10 port 51292 ssh2: ED25519 SHA256:AAAA...

ينتج اتصال واحد من وكيل ممتلئ عدة أسطر من هذه الأسطر من العنوان نفسه خلال ثانية أو ثانيتين. تحسب jail في fail2ban sshd أسطر فشل sshd، وتحظر عنوان المصدر عند بلوغ maxretry ضمن findtime. تكون هذه النوافذ قصيرة افتراضياً، لذلك قد تكفي محاولتان لإعادة اتصال معطّل لحظر عنوانك أنت.

يتغير العَرَض بعد ذلك، وهذا هو الجزء الذي يربك المستخدمين. لن ترى بعد الآن الرسالة "Too many authentication failures"، ولن ترى شيئاً على الإطلاق: يظل الاتصال معلّقاً ثم تنتهي مهلته، لأن جدار الحماية يسقط حزمك الآن بدلاً من الرد عليها. انتهاء المهلة بعد أن كنت تحصل على رسالة خطأ هو الإشارة المهمة، وهذا الفرق موضح في رفض اتصال SSH مقابل انتهاء مهلة اتصال SSH.

من وحدة تحكم مزوّد الخدمة، أو من عنوان مختلف، افحص jail وألغِ الحظر:

sudo fail2ban-client status sshd
sudo fail2ban-client set sshd unbanip 203.0.113.10

ضع عنوانك أنت في ignoreip ضمن jail.local أثناء معالجة مشكلة العميل، ثم أزله عند الانتهاء. إعداد jail نفسه موضح في دليل fail2ban لـ Ubuntu 24.04.

ما ينبغي فعله مرة واحدة لمنع تكرار المشكلة

امنح كل خادم كتلة Host خاصة به في ~/.ssh/config، مع HostName وUser وIdentityFile وIdentitiesOnly yes. بعد ذلك، يصبح ssh vps قصيراً وسهل الكتابة، ويعرض مفتاحاً واحداً بالضبط، ولا يمكن أن يتسبب في MaxAuthTries مهما امتلأ وكيلك. كما يحافظ ذلك على قِصر مخرجات ssh -v بما يكفي لقراءتها في اليوم الذي يتعطل فيه شيء آخر.

FAQ

كيف أصلح الخطأ "Too many authentication failures" الآن؟

استخدم مفتاحاً واحداً بدلاً من جميع المفاتيح. للاتصال فوراً، نفّذ ssh -o IdentitiesOnly=yes -i ~/.ssh/your_key user@host. ولإصلاح المشكلة نهائياً، أضف كتلة إلى ~/.ssh/config تتضمن HostName وUser وIdentityFile للإشارة إلى ذلك المفتاح، ثم IdentitiesOnly yes. بعد ذلك نفّذ chmod 600 ~/.ssh/config. تحقّق من الإعداد باستخدام ssh -v؛ يجب أن ترى سطراً واحداً من Offering public key: لهذا المضيف.

لماذا يستمر ssh -i في عرض مفاتيحي الأخرى؟

لأن -i يضيف هوية إلى القائمة، ولا يقيّد القائمة. تبقى المفاتيح المحمّلة في ssh-agent ضمن القائمة، ويستمر عرضها، وغالباً قبل مفتاحك. لذلك قد يصل الخادم إلى MaxAuthTries قبل تجربة مفتاحك. الخيار -o IdentitiesOnly=yes هو الذي يقيّد ssh بالهويات التي تحددها. استخدم -i و-o IdentitiesOnly=yes معاً، أو استخدم -o IdentityAgent=none لتجاهل الوكيل بالكامل في ذلك الاتصال.

هل ينبغي أن أزيد MaxAuthTries على الخادم لإصلاح المشكلة؟

لا، في جميع الحالات تقريباً. يرسل العميل مفاتيح لن يقبلها هذا الخادم أبداً، وزيادة الحد لا تؤدي إلا إلى جعل الخادم يقيّم عروضاً مرفوضة أكثر في كل اتصال، لكل عميل ولكل محاولة تخمين كلمات مرور تصل إليه. كما أن المشكلة ستعود فوراً عند إضافة مفتاح آخر إلى وكيلك. تحقّق من القيمة الفعلية باستخدام sudo sshd -T | grep -i maxauthtries إذا أردت، ثم أصلح إعداد العميل باستخدام IdentitiesOnly.

لماذا بدأت المشكلة على خادم كان يعمل جيداً الشهر الماضي؟

لأن الوكيل لديك أصبح يحتوي على مفاتيح أكثر. يحتفظ AddKeysToAgent yes في ~/.ssh/config بكل مفتاح تستخدمه محمّلاً، كما تعمل وكلاء keyring على سطح المكتب على تحميل المفاتيح تلقائياً عند تسجيل الدخول. عندما يتجاوز عدد المفاتيح المحمّلة قيمة MaxAuthTries على الخادم، يبدأ كل خادم يقع مفتاحه في موضع متأخر من ترتيب العرض بالفشل. نفّذ ssh-add -l وقارن العدد بالحد الموجود على الخادم.

هل يمكن أن يؤدي ذلك إلى حظر عنوان IP الخاص بي بواسطة fail2ban؟

نعم. ينتج كل مفتاح مرفوض سطراً من Failed publickey for ... في سجل الخادم. لذلك قد ينشئ اتصال واحد عدة حالات فشل من عنوانك خلال ثوانٍ، ويحظر jail الخاص بـfail2ban، sshd، العنوان عند بلوغ maxretry ضمن findtime. العلامة الواضحة هي أن الخطأ يتحول إلى تعليق ثم إلى انتهاء مهلة، لأن الحزم يجري إسقاطها بدلاً من الرد عليها. أزل الحظر من وحدة التحكم باستخدام sudo fail2ban-client set sshd unbanip <your address>، وأصلح إعداد العميل قبل إعادة الاتصال.