سؤال لماذا أحصل على "تم رفض الإذن (publickey)" عند محاولة SSH من أوبونتو المحلي إلى خادم Amazon EC2؟


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

أفكر في نوع من المشاكل المتعلقة بإعدادات الأمان في Amazon EC2 التي لديها وصول IP محدود إلى مثيل واحد أو قد تحتاج إلى إعادة إنشاء الشهادة.

لا أحد يعرف الحل؟


213
2017-07-13 07:38


الأصل


"لقد اعتادت العمل من قبل" - من قبل ماذا؟ - womble♦
لدي مثيل Beanstalk EC2 مطاطا. في أغسطس 2013 ، كان الحل هو الوصول إلى المثيل باسم مستخدم المستخدم ec2 الذي جعل الخطأ "رفض الوصول" (publicKey) يزول. Viz: ssh -i ./mike-key-pairoregon.pem ec2-user@ec2-some-address.us-west-2.compute.amazonaws.com. بالطبع لديك لجميع الأشياء الأخرى حسب stackoverflow.com/questions/4742478/... - mikemay
تحصل على هذه المشكلة إذا كان لديك اسم مستخدم غير صحيح محدد. مستندات اوس (docs.aws.amazon.com/AWSEC2/latest/UserGuide/...) حاليا إعطاء مثال مع مستخدم EC2 المستخدم [ssh -i / path/my-key-pair.pem ec2-user@ec2-198-51-100-1.compute-1.amazonaws.com] ، في حين أن ( القديم) مربع أوبونتو لديه اسم مستخدم من أوبونتو ، لذلك عندما استخدمت المثال تلقيت هذا الخطأ ، تغيير إلى اسم المستخدم الصحيح يحل. - david.barkhuizen
@ david.barkhuizen ، ساعدني تعليقك. كان لدي مشكلة مماثلة. اتضح أن لها علاقة باسم المستخدم. شكر. - NaijaProgrammer


الأجوبة:


أول شيء يجب القيام به في هذه الحالة هو استخدام -v خيار ل ssh، لذلك يمكنك معرفة أنواع التوثيق التي تتم تجربتها وما هي النتيجة. هل هذا يساعد على تنوير الوضع؟

في التحديث الخاص بك لسؤالك ، يمكنك ذكر "على أوبونتو المحلية الأخرى". هل قمت بنسخ المفتاح الخاص ssh إلى الجهاز الآخر؟


140
2017-07-13 07:44



لقد قمت بنسخ المفتاح الخاص ssh إلى الجهاز الآخر كما اقترحGreg. انه يعمل الان. شكر! - Vorleak Chy
FYI يمكنك استخدام علم -i للإشارة إلى مسار المفاتيح دون تثبيتها - Jorge Vargas
في حالتي ، كنت أستخدم bitnami .ami ولم أكن أدرك أنك تحتاج إلى تسجيل الدخول باسم المستخدم الذي يطلق عليه bitnami ، مثل: ssh -i <keyfile> bitname@<ec2-address>. لسوء الحظ، ال -v لم يساعدني الخيار في العثور على هذا ، ولكن لا يزال من المفيد جدًا التحقق! - Matt Connolly
حسنا ، في حالتي كنت باستخدام اسم المستخدم الخطأ. كان يستخدم "أوبونتو" بدلا من "بيتنامي". مثل هذا: ssh -i key.pem bitnami @ hostaddress - Lucas Pottersky
كما أن هناك نقطة اتصال جيدة هي العقدة البعيدة نفسها ، انظر إلى /var/log/auth.log، في بعض الأحيان سترى الرسائل التالية: Authentication refused: bad ownership or modes for file /var/lib/jenkins/.ssh/authorized_keys أو أي شيء آخر - Jonas Libbrecht


بما أنه لم يتم ذكره بشكل صريح ، فإن sshd يكون صارمًا بشكل صارم جدًا على الأذونات الخاصة بـ authorized_keys الملفات. حتى إذا authorized_keys هو للكتابة لأي شخص آخر غير المستخدم أو يمكن جعلها قابلة للكتابة من قبل أي شخص آخر غير المستخدم ، سوف يرفض المصادقة (ما لم يتم تكوين sshd به StrictModes no)

ما أعنيه بـ "يمكن جعل الكتابة" هو أنه إذا كان أي من الدلائل الأصل قابل للكتابة لأي شخص آخر غير المستخدم ، يمكن للمستخدمين المسموح لهم بتعديل هذه الدلائل بدء تعديل الأذونات بطريقة يمكنهم تعديل / استبدال authorized_keys.

هذا لن تظهر ssh -v، ستظهر في السجلات المنبعثة من sshd (عادة ما يتم وضعها في /var/log/secure أو /var/log/auth.log، يعتمد على توزيعة و syslogd ترتيب).

من الرجل sshd (8):

 ~/.ssh/authorized_keys
         Lists the public keys (RSA/DSA) that can be used for logging in
         as this user.  The format of this file is described above.  The
         content of the file is not highly sensitive, but the recommended
         permissions are read/write for the user, and not accessible by
         others.

         If this file, the ~/.ssh directory, or the user's home directory
         are writable by other users, then the file could be modified or
         replaced by unauthorized users.  In this case, sshd will not
         allow it to be used unless the StrictModes option has been set to
         “no”.

73
2018-01-05 14:38



هذا الشيء "يمكن جعله قابل للكتابة" هو ما حصل لي - wmarbut
FWIW الأذونات الصحيحة لملفات المفتاح هي 600 (انظر هنا) - Matt Lyons
نعم ، ملفي .authorized_keys كان قابل للكتابة بواسطة المجموعة لذا رفضت القبول. - Aditya M P
كنت أضرب رأسي ضد الجدار! كان مجلد المستخدم الخاص بي لديه أذونات خاطئة. شكرا لكم! - XJones
وينطبق نفس الشيء على المجلد ~ / .ssh نفسه. قد تحصل على رسالة الخطأ التالية: Authentication refused: bad ownership or modes for directory - Yevgeniy M.


تلقيت هذا الخطأ ، لأنني نسيت أن أضيف -l اختيار. اسم المستخدم المحلي الخاص بي لم يكن هو نفسه كما في النظام البعيد.

هذا لا يجيب على سؤالك ، لكنني وصلت هنا للبحث عن إجابة لمشكلتي.


37
2018-04-01 21:51



ssh host -l user بالضبط مثل ssh user@host، حق؟ - Znarkus
@ Znarkus نعم ، هو نفسه. - cregox
نعم ، هذا حل مشكلتي مما تسبب في الخطأ "تم رفض الإذن (publickey)" كذلك. - Brooks Moses
هذه كانت المشكلة بالنسبة لي كنت أتوقع المستخدم "الجذر" للعمل ، ولكن كنت تستخدم صورة Ubuntu EC2 التي كان المستخدم الافتراضي "أوبونتو". - Cerin


حصلت على هذه الرسالة على نسخة جديدة تقوم على أساس Ubuntu AMI. كنت أستخدم الخيار -i لتوفير PEM ولكنه كان لا يزال يعرض "تم رفض الإذن (publickey)".

كانت مشكلتي أنني لم أكن أستخدم المستخدم الصحيح. عن طريق تشغيل ssh مع ubuntu @ ec2 ... لقد عملت بشكل طبيعي.


19
2017-11-17 16:29



نعم ... كنت أدير الأمر مع sudo، وهذا هو السبب في أنها لم تكن تعمل. - thaddeusmt


شيء أسهل في القراءة من ssh -i (في رأيي بالطبع) ، هو tail -f /var/log/auth.log. يجب تشغيل ذلك على الخادم الذي تحاول الاتصال به أثناء محاولة الاتصال. سوف تظهر الأخطاء في نص عادي.

ساعدني ذلك في حل مشكلتي:

المستخدم [اسم المستخدم] من xx.yy.com غير مسموح به لأنه لا يتم سرد أي من مجموعات المستخدم في AllowGroups


16
2018-02-01 14:07



أعتقد أنك تقصد -v - Tim Tisdall
هذا سجل الخادم. لـ RHEL / CentOS 7: tail -f /var/log/secure - Gianfranco P.


افحص / الخ / سه / sshd_config ملف. هناك ، ابحث عن الخط الذي يقول

PasswordAuthentication no

هذا الخط يحتاج إلى تعديل ليقول نعم بدلا من لا. أيضا ، إعادة تشغيل خادم sshd بعد ذلك.

sudo /etc/init.d/ssh restart

11
2017-12-10 06:15



من شأنه أن يجعل الخادم أقل أمنا. - Znarkus
كانت هذه المشكلة التي واجهتها: كنت أرغب في إعداد حساب لمستخدم آخر ، والمصادقة باستخدام كلمة مرور فقط. أردت أيضًا أن أكون قادرًا على تسجيل الدخول بنفسي من الأماكن التي لم يكن عندي مفتاحها الخاص. - Daniel
كيف نذهب إلى /etc/ssh/sshd_config - إذا لم نتمكن حتى من الدخول إلى الخادم؟ - kyo
للوصول إلى الخادم نفسه ، يجب عليك استخدام ملف PEM الذي قدموه عند إنشاء المثيل. التعليمات تذهب بعد ذلك. - Sudipta Chatterjee
هذا العمل بالنسبة لي ، على الرغم من أن إعادة تشغيل sshd يتطلب الأمر التالي: sudo service sshd reload - pacoverflow


ربما لا تكون ذات صلة بالملصق الحالي ، ولكنها قد تساعد الآخرين الذين يجدون ذلك عند البحث عن إجابات لحالات مماثلة. بدلاً من السماح للأمازون بتوليد keyshire ssh ، فإنني أوصيك بتحميل مفتاح ssh العام الخاص بك ، القياسي ، الافتراضي إلى Amazon وتحديد أنه عند تشغيل مثيل EC2.

هذا يتيح لك إسقاط بناء جملة "-i" في ssh ، واستخدام rsync مع الخيارات القياسية ، وأيضا يتيح لك استخدام نفس المفتاح ssh عبر جميع المناطق EC2.

كتبت مقالا حول هذه العملية هنا:

تحميل مفاتيح ssh الشخصية للأمازون EC2
http://alestic.com/2010/10/ec2-ssh-keys


6
2017-09-29 21:15



+1 بحث عن هذا السؤال بالضبط لهذا السبب. - John Riselvato
أرى هذا الخطأ في متابعة مقالك. المناطق = $ (ec2-describ-regions | cut -f2) الخيار المطلوب '-K ، مفتاح-المفتاح الخاص' مفقود (-h للاستخدام) - KashifAli
KashifAli سترغب في إعداد بيانات اعتماد أداة سطر الأوامر EC2 API حتى لا تضطر دائمًا إلى تمرير بيانات الاعتماد على كل سطر أوامر. - Eric Hammond


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


5
2017-08-08 21:00



شكرا لكم! كانت هذه مشكلتي بالضبط. لم أكن أدرك تغيير اسم DNS عند إعادة تشغيل مثيل. - Tim Swast
في حالتي ، تغير عنوان URL * .compute.amazonaws.com عندما عينت عنوان IP مرنًا. - Geoffrey Booth