سؤال فشل المصادقة أكثر من اللازم لـ * اسم المستخدم *


لدي حساب hostgator مع تمكين الوصول إلى ssh وعند محاولة تحميل ملف مفتاح pub الذي تم إنشاؤه باستخدام هذا الأمر:

rsync -av -e "ssh -p2222" /home/user/.ssh/key.pub username@111.222.33.44: .ssh / authorized_keys

أستمر في الحصول على:

تم قطع الاتصال من 111.222.33.44: 2: فشل مصادقة كثيرة جدًا لاسم المستخدم
rsync: اتصال مغلق بشكل غير متوقع (0 بايت تم تلقيه حتى الآن) [المرسل]
خطأ rsync: خطأ غير مبرر (رمز 255) في io.c (601) [sender = 3.0.7]

لقد تم اللعب في السابق مع ssh حتى حصلت على فشل المصادقة. ولكن يبدو الآن أن عداد فشل المصادقة لا يعيد (كان ينتظر أكثر من 12 ساعة الآن ، والدعم الفني "افترض" أنه يعيد التشغيل بعد 30 دقيقة إلى ساعة واحدة ، وأخبرني شخص آخر أنه "يعيد ضبط كل مرة تحاول فيها تسجيل الدخول مع اسم المستخدم "، jeesh).

هذا هو دفع لي المكسرات. حتى أنني قمت بإعداد هذا في خادم مخصص Slicehost وكان أقل القضايا من هؤلاء الرجال. أي نصيحة؟ ربما شيء جانب العميل وليس جانب الخادم.


231
2017-09-12 17:14


الأصل




الأجوبة:


هذا هو عادة تسبب عن طريق غير قصد تقديم عدة مفاتيح سه إلى الخادم. سيرفض الخادم أي مفتاح بعد عرض الكثير من المفاتيح.

يمكنك رؤية هذا بنفسك عن طريق إضافة -v علم لجهودكم ssh الأمر للحصول على إخراج مطول. سترى أنه يتم تقديم مجموعة من المفاتيح ، إلى أن يرفض الخادم الاتصال قائلاً: "فشل مصادقة كثيرة جدًا لـ [المستخدم]". بدون وضع verbose ، سترى الرسالة المبهمة فقط "تم إعادة الاتصال من قبل النظير".

لمنع عرض المفاتيح غير ذات الصلة ، يجب عليك تحديد هذا بوضوح في كل إدخال مضيف في ~/.ssh/config (على جهاز العميل) الملف عن طريق إضافة IdentitiesOnly مثل ذلك:

Host www.somehost.com
  IdentityFile ~/.ssh/key_for_somehost_rsa
  IdentitiesOnly yes
  Port 22

إذا كنت تستخدم وكيل ssh ، فإنه يساعد على تشغيل ssh-add -D لمسح الهويات.

إذا لم تكن تستخدم أي تكوين من مضيفي ssh ، فعليك تحديد المفتاح الصحيح بوضوح في ssh الأمر مثل ذلك:

ssh -i some_id_rsa -o 'IdentitiesOnly yes' them@there:/path/

ملاحظة: يجب أن تكون المعلمة "IdentitiesOnly yes" بين علامات الاقتباس.

أو

ssh -i some_id_rsa -o IdentitiesOnly=yes them@there:/path/

374
2017-09-12 17:53



ليس من الواضح بالنسبة لي أين وضع هذا الخط. على الخادم الذي أحاول تسجيل الدخول إليه ، لا يحتوي .ssh / config إلا على معلومات للخوادم الأخرى. هل تقصد أن هذا يجب أن يذهب في ملف .ssh / config على الكمبيوتر الذي أحاول الحصول منه على ssh؟ إذا كان الأمر كذلك ، فهذا غير واضح لأن إجابتك تقول "بمجرد تسجيل الدخول ..." - David LeBauer
يجب أن أضع هذا الخيار بين علامتي تنصيص ، مثل: ssh -i some_id_rsa -o "IdentitiesOnly yes" them@there:/path/ - knb
مستخدمو Windows الذين يقومون بتشغيل PAGENT (عميل المعجون) ، تأكد من أن لديك المفاتيح التي تريد تحميلها فقط. لقد واجهت هذه المشكلة بعد تحميل جميع مفاتيحي الخاصة عن طريق الخطأ. - Chris Rasco
ومع ذلك ، ل سشفس (فيوز) لا بد لي من كتابة الخيار مع علامة يساوي إلزامية ، مثل هذا: sshfs -o "IdentitiesOnly=yes" -o IdentityFile=~/.ssh/id_dsa them@there/var/tmp /mnt/tmp  (أوبونتو 13.10) - knb
يمكن استخدامه بدون علامات اقتباس ، مثل هذا: -o IdentitiesOnly=yes - Valentin Kantor


لقد وجدت طريقة أسهل للقيام بذلك (إذا كنت تستخدم مصادقة كلمة المرور):

ssh -o PubkeyAuthentication=no username@hostname.com

هذا يفرض مصادقة غير المفتاح. كنت قادرا على تسجيل الدخول على الفور.

مرجع


163
2018-03-25 00:14



+1 ، أتمنى أن أقدم لك المزيد. Raspberry Pi هو الجهاز الوحيد الذي استخدمه بدون مفتاح عام. تم الحصول على: "فشل مصادقة كثيرة جدًا لـ pi" - blak3r
واستخدام ذلك مع rsync: rsync -av -e 'ssh -o PubkeyAuthentication=no' 'user@host.com:~/remote_file' 'local_file' - Ciro Santilli 新疆改造中心 六四事件 法轮功
يمكنك أيضًا إنشاء اسم مستعار لجعله أسرع حتى بالنسبة إلى مصادقة كلمة المرور. الاسم المستعار sshp = 'ssh -o PubkeyAuthentication = no' - dhempler


كنت أتلقى هذا الخطأ أيضًا ووجدت أنه كان يحدث b / c تم تكوين الخادم لقبول ما يصل إلى 6 محاولات:

/etc/ssh/sshd_config
...
...
#MaxAuthTries 6

بالإضافة إلى ضبط IdentitiesOnly yes في حياتك ~/.ssh/config الملف لديك بضعة خيارات أخرى.

  1. زيادة MaxAuthTries (على خادم ssh)
  2. احذف بعض الأزواج الرئيسية التي لديك في حياتك ~/.ssh/ الدليل والتشغيل ssh-add -D 
  3. صراحة ربط مفتاح لمضيف معين في بلدكم ~/.ssh/config ملف

مثل ذلك:

host foo
hostname foo.example.com
IdentityFile /home/YOU/.ssh/foo
  1. ربما لا يكون طريقة جيدة للذهاب حول هذا الموضوع ، بالنظر إلى أنه يضعف خادم ssh الخاص بك قليلا لأنه سوف يقبل الآن المزيد من المفاتيح في محاولة اتصال معينة. اعتقد ناقلات هجوم القوة الغاشمة هنا.

  2. هي طريقة جيدة لفرض افتراض أنك تمتلك مفاتيح غير ضرورية ويمكن حذفها نهائيًا.

  3. وربما يكون أسلوب تحديد الهوية هو السبيل المفضل للتعامل مع هذه القضية!


24
2018-06-09 04:56



في السطر الأخير ، يكون لديك ملف تعريف /home/YOU/.ssh/foo ولكن يجب أن يكون ملفًا للتوضيح (ليس t f) - Nin
Nin - شكرًا ، ثابتة. - slm


لقد أضفت إلى ~ / .ssh / config هذا:

Host *
IdentitiesOnly yes

فهو يتيح الخيار IdentitiesOnly = yes افتراضيًا. إذا كنت بحاجة إلى الاتصال بالمفتاح الخاص ، فعليك تحديده باستخدام الخيار -i


6
2017-07-23 17:29





إذا كان لديك كلمة مرور ، وتريد ببساطة استخدام كلمة المرور لتسجيل الدخول ، فإليك كيفية القيام بذلك.

لاستخدام مصادقة كلمة المرور فقط وعدم استخدام المفتاح العام وعدم استخدام "لوحة المفاتيح التفاعلية" المضللة إلى حد ما (وهي عبارة عن مجموعة شاملة تتضمن كلمة المرور) ، يمكنك إجراء ذلك من سطر الأوامر:

ssh -o PreferredAuthentications=password user@example.com

6
2018-06-19 14:22





إذا حصلت على خطأ SSH التالي:

$ Received disconnect from host: 2: Too many authentication failures for root

يمكن أن يحدث هذا إذا كان لديك (افتراضي على نظامي) خمسة أو أكثر من ملفات هوية DSA / RSA المخزنة في دليل .ssh وإذا لم يتم تحديد الخيار "-i" في سطر الأوامر.

سيحاول عميل ssh أولاً تسجيل الدخول باستخدام كل هوية (مفتاح خاص) والمطالبة التالية لمصادقة كلمة المرور. ومع ذلك ، يسقط sshd الاتصال بعد خمس محاولات تسجيل الدخول غير صحيح (قد تختلف مرة أخرى الافتراضي).

إذا كان لديك عدد من المفاتيح الخاصة في دليل .ssh الخاص بك ، فيمكنك تعطيل "مصادقة المفتاح العام" في سطر الأوامر باستخدام الوسيطة الاختيارية "-o".

فمثلا:

$ ssh -o PubkeyAuthentication=no root@host

5
2017-09-20 21:44



كان هذا بالضبط ما كان يحدث لي! شكرا جزيلا للتفسير ؛) - El Ninja Trepador


الخروجDavid قائلا ، فقط قم بإضافة هذا IdentitiesOnly yes إلى .ssh / config الخاص بك ، يفعل نفس الشيء ssh -o PubkeyAuthentication=no.

بعد تسجيل الدخول ، قم بإزالة .ssh/authorized_keys. الآن ، ارجع إلى الجهاز المحلي واكتب ما يلي

cat ~/.ssh/id_rsa.pub | ssh -o PubkeyAuthentication=no user@IP_ADDR 'cat >> .ssh/authorized_keys'. يجب أن يؤدي ذلك إلى إعادة تمكين ssh باستخدام المفتاح العام


2
2018-01-25 05:48





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

sudo chown -R user:user /home/user/.ssh

قمت أيضًا بالتأكد من صحة الأذونات على المجلد .ssh:

sudo chmod 700 /home/user/.ssh

يجب أن تحصل الملفات الموجودة داخل دليل .ssh على إذن من 600:

sudo chmod 600 /home/user/.ssh/authorized_keys

2
2018-06-13 17:37



سأكون حذرا مع استخدام هذا دون أي تحذير. تقتصر أذونات مفتاح SSH عادة على 400 مفتاح لبعض المفاتيح ، خاصة AWS. وستؤدي محاولة تعيينهم أعلاه إلى عدم قبول المفتاح ، ويمكن أن يؤدي ذلك إلى إغلاق حسابك في حساب AWS. - Michael Ryan Soileau


في حالتي ، كانت المشكلة أذونات الدليل. هذه ثابتة بالنسبة لي:

$ chmod 750 ~;chmod 700 ~/.ssh

1
2018-02-20 22:57





في حالتي ، كان يحدث ذلك لأنني كنت أستخدم اسم المستخدم "ubuntu" ، ولكن اسم المستخدم في هذه الحالة كان "ec2-user"

بعد أن فعلت ما اقترحه "جون تي" ، تلقيت هذا الخطأ:

تم رفض الإذن (publickey).

ثم وجدت الحل (أي تغيير اسم المستخدم إلى "ec2-user") في هذه الإجابة: https://stackoverflow.com/questions/1454629/aws-ssh-access-permission-denied-publickey-issue


0
2017-11-19 08:10





كان لدي مفتاح عمومي .ssh/authorized_keys2، ولكن تم تكوين الخادم للقراءة فقط .ssh/authorized_keys:

# The default is to check both .ssh/authorized_keys and .ssh/authorized_keys2
# but this is overridden so installations will only check .ssh/authorized_keys
AuthorizedKeysFile .ssh/authorized_keys

بعد نقل الملف الخاص بي إلى .ssh/authorized_keys، يمكنني تسجيل الدخول بنجاح باستخدام مفتاحي.


0
2018-05-05 07:57