การเชื่อมต่อ SSH จะถามรหัสผ่านแม้ว่าจะยอมรับรหัสก็ตาม


12

ฉันได้รับพร้อมท์ให้ใส่รหัสผ่านแม้ว่าดูเหมือนว่าจะยอมรับคีย์ SSH แล้วก็ตาม เท่าที่ฉันสามารถบอกได้บรรทัด "เซิร์ฟเวอร์ยอมรับคีย์: pkalg ssh-rsa blen 277" ในบันทึกด้านล่างหมายความว่ากุญแจของฉันได้รับการยอมรับ

นี่คือบันทึกการดีบัก:

debug1: Next authentication method: publickey
debug1: Offering RSA public key: /home/sam/.ssh/id_rsa
debug2: we sent a publickey packet, wait for reply
debug1: Server accepts key: pkalg ssh-rsa blen 277
debug2: input_userauth_pk_ok: fp <<HASH REDACTED>>
debug1: Authentications that can continue: publickey,password,keyboard-interactive
debug1: Trying private key: /home/sam/.ssh/id_dsa
debug1: Trying private key: /home/sam/.ssh/id_ecdsa
debug2: we did not send a packet, disable method
debug1: Next authentication method: keyboard-interactive
debug2: userauth_kbdint
debug2: we sent a keyboard-interactive packet, wait for reply
debug2: input_userauth_info_req
debug2: input_userauth_info_req: num_prompts 1

ช่วยชื่นชมมาก ๆ ทุกคนที่ฉันพบว่ามีปัญหา SSH ล้มเหลวในจุดก่อนหน้านี้ที่ฉันเห็น

คำตอบ:


11

รหัสส่วนตัวของคุณไม่ได้รับการยอมรับอย่างแน่นอนมันเป็นเพียงความพยายาม มีหลายวิธีที่การรับรองความถูกต้องโดยใช้คีย์ SSH อาจล้มเหลวได้และการบันทึกไม่ดีมากดังนั้นการแก้ไขข้อบกพร่องของปัญหานี้เป็นหนึ่งในปัญหาส่วนตัวของฉัน ฉันพบว่าข้อผิดพลาดมักเกิดจากหนึ่งในสถานการณ์ต่อไปนี้

  • ~/.ssh/authorized_keysไฟล์ของคุณเปิดเกินไป สำหรับการป้องกันของคุณเองsshdพยายามที่จะปกป้องคุณจากตัวคุณเอง หากสิทธิ์ของไฟล์คีย์ที่ได้รับอนุญาตของคุณนั้นจะไม่ผ่านการตรวจสอบสิทธิ์ chmod -R go-rwx ~/.sshวิ่ง
  • รหัสสาธารณะของคุณ~/.ssh/authorized_keysมีรูปแบบไม่ถูกต้อง นี่อาจเป็นผลมาจากปัญหาต่าง ๆ จำนวนมาก แต่ปัญหาที่พบบ่อยที่สุดคือปัญหาการคัดลอก เทอร์มินัลบางตัวเมื่อคัดลอก / วางข้ามหน้าจอจะตีความการตัดบรรทัดเป็นบรรทัดใหม่ แต่ละรายการในauthorized_keysไฟล์จะต้องเป็นบรรทัดเดียว คุณสามารถตรวจสอบสิ่งนี้ได้โดยการเปลี่ยนขนาดของเทอร์มินัลอีมูเลเตอร์ของคุณและดูว่ามีการหยุดพักหรือไม่เปรียบเทียบผลลัพธ์ของwc -l ~/.ssh/authorized_keysกับจำนวนของคีย์ที่ควรอยู่ในนั้นหรืออะไรก็ตามที่ดีที่สุดสำหรับคุณ เพียงให้แน่ใจว่าแต่ละคีย์เป็นหนึ่งบรรทัดและคุณควรจะปรับ

7

เอาต์พุต ssh -v ที่คุณวางแนะนำว่าพยายามใช้คีย์ แต่ไม่ได้ผลดังนั้นจึงย้ายไปยังแป้นพิมพ์แบบโต้ตอบ

คุณได้ตรวจสอบบันทึกการรับรองความถูกต้องบนเซิร์ฟเวอร์ที่คุณกำลังเชื่อมต่อหรือไม่? (เช่น /var/log/auth.log) หากการตั้งค่าของคุณที่ปลายระยะไกลไม่ถูกต้องเช่นการอนุญาตที่ไม่ถูกต้อง ssh -v (หรือ -vv หรือ -vvv) จะไม่บอกคุณ แต่จะถูกบันทึกโดย sshd


/var/log/auth.log ถือคำตอบสำหรับฉัน: "การรับรองความถูกต้องถูกปฏิเสธ: ความเป็นเจ้าของหรือโหมดสำหรับไดเรกทอรี / root"
kevlar1818

5

ในกรณีของฉันไฟล์/var/log/authlogแสดง:

[ID 800047 auth.info] Authentication refused: bad ownership or modes for directory 

ฉันตรวจสอบการเป็นเจ้าของ / การอนุญาตที่ถูกต้อง.sshแต่$HOMEมีการอนุญาต 777 ครั้ง การตั้งค่า 755 สิทธิ์บน$HOMEsftp ที่ได้รับอนุญาตให้ทำงาน ขอบคุณอีกครั้ง.


2

หากคุณสามารถเข้าถึงเซิร์ฟเวอร์ (โดยตรงหรือผ่านการเข้าสู่ระบบอื่น) ให้ตรวจสอบการเข้าสู่ระบบเซิร์ฟเวอร์ (พูด) /var/log/sshdหรือ/var/log/secureขึ้นอยู่กับระบบของคุณ

โดยทั่วไปจะเกิดจากข้อผิดพลาดการอนุญาตใน~/.ssh/authorized_keysไฟล์ของคุณ ตรวจสอบให้แน่ใจว่ามันไม่สามารถอ่านได้ทั่วโลก แต่ที่สำคัญคือผู้ใช้สามารถอ่านได้ (บางครั้งเป็นผู้ใช้บริการ) ที่กำลังเรียกใช้ sshd


1
ซึ่งใช้ระบบ/var/log/sshd? ฉันรู้ว่าระบบการใช้งานอย่างใดอย่างหนึ่งหรือ/var/log/auth.log /var/log/secure
kasperd

1

สิทธิ์~/.ssh/authorized_keysในระยะไกลเป็นสิ่งสำคัญ ( 600สำหรับระบบของฉัน RHEL และ Solaris)

สิทธิ์ของโฮมไดเร็กตอรี่ของคุณในระยะไกลเป็นสิ่งสำคัญ ( 700ในระบบของฉัน)

เมื่อสิ้นสุดการทำงานsshdในเครื่องระยะไกลในโหมดดีบักบนพอร์ตอื่นจะมีประโยชน์:

sudo /usr/sbin/sshd -p 5555 -dd

5555เป็นพอร์ตตัวอย่างคุณสามารถเปลี่ยนได้ สำหรับข้อมูลเพิ่มเติมในเรื่องนี้คุณสามารถดู: http://ubuntuforums.org/archive/index.php/t-2219973.html


0

ฉันพบว่ามีปัญหาหากฉันใช้sshdบริการ เพื่อหลีกเลี่ยงปัญหานี้หยุดsshdให้บริการกับservice sshd stopและจะเริ่มต้นภูตจากพรอมต์คำสั่งด้วยsshdsudo /usr/sbin/sshd


0

ลอง

/sbin/restorecon -r /root/.ssh

ปัญหาที่เป็นไปได้เกี่ยวกับการตั้งค่าการอนุญาต

โดยการใช้ไซต์ของเรา หมายความว่าคุณได้อ่านและทำความเข้าใจนโยบายคุกกี้และนโยบายความเป็นส่วนตัวของเราแล้ว
Licensed under cc by-sa 3.0 with attribution required.