حل خطأ 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».

تُعد 6 محاولات كافية لشخص يكتب كلمة مرور. لكنها قليلة بالنسبة إلى agent يحمل 10 مفاتيح. عندما يصل عدد حالات الفشل إلى الحد الأقصى، يقطع 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 بمفرده «مفتاحاً واحداً». من دون سطر IdentityFile، تُحتسب ملفات الهوية الافتراضية ضمن الهويات المضبوطة، لذلك سيجرّب ssh أيضاً ~/.ssh/id_ed25519 و~/.ssh/id_rsa والملفات الافتراضية الأخرى التي يجدها. تحتاج إلى سطر IdentityFile كذلك؛ فبعد ضبطه، يتوقف ssh عن إضافة الملفات الافتراضية.
• ما زال agent ينفّذ عملية التوقيع. يتحكم IdentitiesOnly في المفاتيح التي تُعرض، وليس في الجهة التي توقّع. إذا كان المفتاح الخاص الذي يحدده IdentityFile محمّلاً في agent، فإن agent ينشئ التوقيع ولن يُطلب منك إدخال عبارة مرور. ويمكنك حتى توجيه IdentityFile إلى ملف .pub المطابق، وهذا ما تفعله عندما يكون المفتاح الخاص موجوداً في agent فقط أو على 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، يصبح مقبس agent متاحاً على الخادم الذي تتصل به. ويستخدم أمر ssh الذي يُشغَّل على ذلك الخادم agent المحلي الخاص بك، مع جميع مفاتيحك، عبر المقبس المُعاد توجيهه. لذلك قد يظهر الخطأ في القفزة من jump host إلى الخادم النهائي، بينما تنجح القفزة الأولى. شغّل echo $SSH_AUTH_SOCK على الجهاز الوسيط. يعني الناتج الفارغ عدم وجود agent يمكن الوصول إليه. أما ظهور مسار مقبس فيعني وجود agent ما، وليس بالضرورة agent الخاص بك، لأن agent الذي بدأ على ذلك الجهاز يضبط المتغير نفسه. شغّل ssh-add -l هناك أيضاً. إذا عرض المفاتيح الموجودة على جهازك أنت، فإعادة التوجيه مفعّلة.

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

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

يفتح ProxyJump اتصالاً عبر jump host، ويصادق على الخادم النهائي من جهازك أنت. لذلك ينطبق ~/.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. لا يبدأ ssh.socket في Ubuntu daemon جديداً لكل اتصال، بل يبدأ ssh.service عند وصول أول اتصال، وتستمر هذه الخدمة في العمل وتتولى الاتصالات اللاحقة. يظل إجراء إعادة التحميل أعلاه هو الذي يطبّق التغيير. إذا لم يكن ssh.service نشطاً بعد، فلا توجد خدمة لإعادة تحميلها، وسيبدأها الاتصال التالي باستخدام الملف الجديد.

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

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

لماذا قد يحظرك fail2ban بسبب ذلك

لا يسجّل sshd كل مفتاح مرفوض. في الإعداد الافتراضي LogLevel INFO، لا يُكتب المفتاح المرفوض لحساب حقيقي في السجل إلا عندما يصل عدد حالات فشل الاتصال إلى نصف قيمة MaxAuthTries، وهذا ما يقصده الدليل بعبارة «عندما يصل عدد حالات الفشل إلى نصف هذه القيمة، تُسجّل حالات الفشل الإضافية». عند استخدام القيمة الافتراضية 6، لا تُكتب عروض المفاتيح الثلاثة المرفوضة الأولى في السجل. وتظهر العروض الثلاثة الأخيرة في صورة أسطر مثل السطر التالي، ويتبعها سطر maximum authentication attempts exceeded:

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

تبدو هذه الأسطر كأنها مجموعة كبيرة من حالات الفشل، لكن مرشح fail2ban sshd لا يعدّها. يقرأ الإعداد الافتراضي المضمّن publickey = nofail سطر Failed publickey لمستخدم صالح فقط لاستخراج العنوان واسم المستخدم. أما السطر الذي يُحتسب فهو maximum authentication attempts exceeded، لذلك يضيف اتصال واحد يصل إلى الحد فشلاً واحداً، لا عدة حالات فشل. يحظر jail عنوان المصدر عند تسجيل maxretry حالات فشل خلال findtime، وتضبطها jail.conf الخاصة بـfail2ban على 5 و10 دقائق. تكفي نحو 5 اتصالات فاشلة خلال 10 دقائق لحظر عنوانك، وتصل أداة أو script يعيد المحاولة في حلقة إلى هذا الحد بسرعة.

يتغير العَرَض بعد ذلك، وهذا هو الجزء الذي يربك المستخدمين. تتوقف عن رؤية الرسالة "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 لتجاهل الـagent بالكامل في ذلك الاتصال.

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

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

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

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

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

نعم، لكن بوتيرة أبطأ مما يوحي به سجل الخادم. لا يَعدّ مرشح sshd الافتراضي في fail2ban أسطر Failed publickey للمستخدم الصالح. بل يَعدّ سطر maximum authentication attempts exceeded، لذلك يُعدّ كل اتصال يصل إلى الحد محاولة فاشلة واحدة. مع الإعدادات الافتراضية المضمّنة maxretry = 5 وfindtime = 10m، تؤدي نحو 5 اتصالات من هذا النوع خلال 10 دقائق إلى حظر عنوانك. العلامة الواضحة هي أن الخطأ يتحول إلى تعليق ثم إلى انتهاء مهلة، لأن الحزم تُسقط بدلاً من الرد عليها. أزل الحظر من وحدة التحكم باستخدام sudo fail2ban-client set sshd unbanip <your address>، وأصلح إعداد العميل قبل إعادة الاتصال.