คีย์ Ssh ยอมรับโดยโฮสต์ แต่ลูกค้ายกเลิกการเชื่อมต่อ

Helo,

ฉันมีปัญหากับ SSH หลังจากการติดตั้ง fedora 23

เมื่อฉันไม่ต้องการเชื่อมต่อกับโฮสต์ระยะไกลของฉันด้วยคีย์ส่วนตัวโฮสต์ของฉันค้นหารหัส:

debug1: matching key found: file /home/theo/.ssh/authorized_keys, line 1 RSA {REDACTED}
debug1: restore_uid: 0/0
Postponed publickey for theo from {REDACTED} port 60351 ssh2 [preauth]
Connection closed by {REDACTED} [preauth]
debug1: do_cleanup [preauth]
debug1: monitor_read_log: child log fd closed

แต่ตามที่คุณเห็นลูกค้าของฉันตัดการเชื่อมต่อด้วยตนเอง

debug3: remaining preferred: keyboard-interactive,password
debug3: authmethod_is_enabled publickey
debug1: Next authentication method: publickey
debug1: Offering RSA public key: /home/tbouge/.ssh/id_rsa
debug3: send_pubkey_test
debug2: we sent a publickey packet, wait for reply
debug1: Server accepts key: pkalg ssh-rsa blen 1047
debug2: input_userauth_pk_ok: fp SHA256:{REDACTED}
debug3: sign_and_send_pubkey: RSA SHA256:{REDACTED}
debug2: we did not send a packet, disable method
debug1: No more authentication methods to try.
Permission denied (publickey).

ฉันสามารถเชื่อมต่อกับโฮสต์ของฉันด้วยผงสำหรับอุดรูบน windows โดยใช้รหัสส่วนตัวเดียวกันและฉันสามารถเชื่อมต่อกับโทรศัพท์ของฉันโดยใช้รหัสส่วนตัวอื่น

คุณมีความคิดใด ๆ

/ etc / SSH / ssh_conf

Host *
        GSSAPIAuthentication yes
# If this option is set to yes then remote X11 clients will have full access
# to the original X11 display. As virtually no X11 client supports the untrusted
# mode correctly we set this to yes.
        ForwardX11Trusted yes
# Send locale-related environment variables
        SendEnv LANG LC_CTYPE LC_NUMERIC LC_TIME LC_COLLATE LC_MONETARY LC_MESSAGES
        SendEnv LC_PAPER LC_NAME LC_ADDRESS LC_TELEPHONE LC_MEASUREMENT
        SendEnv LC_IDENTIFICATION LC_ALL LANGUAGE
        SendEnv XMODIFIERS

ขอบคุณ

แก้ไข: ฉันสามารถเชื่อมต่อด้วยรหัสผ่าน

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

แนวคิดพื้นฐานมากคือ (คัดลอกมาจากที่นี่ ):

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

ตอนนี้จากบันทึกการดีบักที่คุณโพสต์:

• ดูเหมือนว่ามีผู้ใช้สองคนที่แตกต่างกันเข้ามาเกี่ยวข้อง และ/home/theo/.ssh/authorized_keys /home/tbouge/.ssh/id_rsaคุณกำลังพยายามเข้าสู่ระบบในฐานะผู้ใช้รายหนึ่งไปยังไดเรกทอรีหลักของผู้ใช้รายอื่นหรือไม่?
• ข้อผิดพลาดPostponed publickey for theo..หมายถึงมีการลองใช้วิธีการรับรองความถูกต้องที่ไม่ต้องการก่อนวิธีการ publick key SSH จะลองใช้วิธีการตรวจสอบอัตโนมัติทุกวิธีที่เปิดใช้งานในการกำหนดค่าแบบต่อเนื่อง ในกรณีของคุณคุณได้GSSAPIAuthentication yesเปิดใช้งานสิ่งที่คุณไม่ได้ใช้ GSSAPIAuthentication noคุณสามารถปิดการใช้งานด้วยการทำ
• debug2: we did not send a packet, disable methodอาจเป็นไปได้ว่ามันไม่สามารถประมวลผลไฟล์กุญแจส่วนตัว (อาจเป็นปัญหาเกี่ยวกับสิทธิ์ของไฟล์หรือชื่อ) SSH มีความละเอียดอ่อนมากเกี่ยวกับการอนุญาตของไดเรกทอรีและไฟล์ทั้งในเครื่องคอมพิวเตอร์ ( chown user_name:user_group -R /home/user, chmod 700 /home/.ssh, chmod 600 /home/.ssh/authorized_keys) ดังนั้นตรวจสอบให้แน่ใจว่าได้ตั้งค่าไว้ถูกต้อง ดูที่นี่: /unix/131886/ssh-public-key-wont-send-to-server

• สำหรับข้อผิดพลาดที่สาม: Permission denied (public key).มีสองสิ่งที่ต้องตรวจสอบ

  • ชื่อผู้ใช้ผิด
  • คีย์คู่ไม่ถูกต้อง

  • โฮสต์เป้าหมายไม่ถูกต้อง

    • นี่คือรายละเอียดเพิ่มเติมได้ที่: /programming/18551556/permission-denied-publickey-when-ssh-access-to-amazon-ec2-instance

ส่วนต่อไปนี้สร้างความสับสนเล็กน้อย:

debug2: we sent a publickey packet, wait for reply
debug1: Server accepts key: pkalg ssh-rsa blen 1047
debug2: input_userauth_pk_ok: fp SHA256:{REDACTED}
debug3: sign_and_send_pubkey: RSA SHA256:{REDACTED}
debug2: we did not send a packet, disable method

เพื่อให้เข้าใจได้ดีขึ้นให้ทำตามขั้นตอนการรับรองความถูกต้องเป็นขั้นตอนดังที่อธิบายไว้ที่digitalocean :

1. ลูกค้าเริ่มต้นด้วยการส่ง ID สำหรับคู่คีย์ที่ต้องการตรวจสอบสิทธิ์กับเซิร์ฟเวอร์
2. การตรวจสอบเซิร์ฟเวอร์ของไฟล์ authorized_keys ของบัญชีที่ลูกค้าพยายามเข้าสู่ระบบสำหรับรหัสคีย์
3. หากพบพับลิกคีย์ที่มี ID ที่ตรงกันในไฟล์เซิร์ฟเวอร์จะสร้างหมายเลขสุ่มและใช้คีย์สาธารณะเพื่อเข้ารหัสหมายเลข
4. เซิร์ฟเวอร์ส่งข้อความที่เข้ารหัสนี้ให้กับลูกค้า
5. หากไคลเอนต์มีรหัสส่วนตัวที่เกี่ยวข้องจริงมันจะสามารถถอดรหัสข้อความโดยใช้คีย์นั้นโดยเปิดเผยหมายเลขเดิม
6. ไคลเอ็นต์รวมหมายเลขที่ถอดรหัสแล้วกับคีย์เซสชันที่แชร์ซึ่งใช้ในการเข้ารหัสการสื่อสารและคำนวณแฮช MD5 ของค่านี้
7. ไคลเอนต์ส่งแฮ MD5 นี้กลับไปยังเซิร์ฟเวอร์เป็นคำตอบของข้อความที่เข้ารหัสลับหมายเลข
8. เซิร์ฟเวอร์ใช้คีย์เซสชันที่แชร์แบบเดียวกันและหมายเลขดั้งเดิมที่ส่งไปยังไคลเอนต์เพื่อคำนวณค่า MD5 ด้วยตนเอง มันเปรียบเทียบการคำนวณของตัวเองกับที่ลูกค้าส่งกลับ หากค่าทั้งสองตรงกันตรงกันก็พิสูจน์ได้ว่าลูกค้าอยู่ในความครอบครองของคีย์ส่วนตัวและลูกค้าจะได้รับการรับรองความถูกต้อง

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

ฉันหวังว่าสิ่งนี้จะช่วยให้คุณเข้าใจปัญหาและแก้ไขได้

สิทธิพิเศษในไฟล์ ssh ของคุณถูกต้องหรือไม่?

.ssh โฟลเดอร์ -> 700

กุญแจสาธารณะ -> 644

รหัสส่วนตัว -> 600

ตรวจสอบผู้ใช้และกลุ่ม

คุณบอกว่าคุณมีรหัสเดียวกันบนเครื่อง windows; คุณแน่ใจหรือว่าไฟล์ไพรเวตคีย์ที่คุณมีในเครื่อง Linux ถูกต้อง? คีย์ส่วนตัวอาจอยู่ในรูปแบบผงสำหรับอุดรูที่ ssh ไม่เข้าใจได้ง่าย ไม่ว่าในกรณีใดถ้าฉันใส่ไฟล์กุญแจส่วนตัวที่ไม่ถูกต้องหรือไม่ถูกต้องฉันจะได้รับข้อผิดพลาดเดียวกับที่คุณมี

เพื่อแก้ไขปัญหามันจะเหมาะสมกว่าในการสร้างคีย์ใหม่บนเครื่อง Linux แทนที่จะนำกุญแจจากเครื่องอื่นมาใช้ซ้ำ คุณสามารถเพิ่มพับลิกคีย์ใหม่ไปยังไฟล์ authorized_keys บนโฮสต์จากนั้นคุณสามารถใช้ทั้งคีย์ Windows จาก Windows และคีย์ Linux ใหม่จาก Fedora

ปัญหาของคุณดูเหมือนจะค่อนข้างธรรมดาและฉันก็บอกได้อย่างชัดเจน

 Permission denied (publickey).

นั่นหมายความว่าอะไรกับคุณ? สำหรับฉันมันมีความหมายมากสำหรับฉัน

คุณสามารถตรวจสอบฝั่งเซิร์ฟเวอร์ถ้าคุณมี selinux runnin ในโหมดบังคับได้หรือไม่? ถ้าไม่บอกฉันว่าโหมด selinux กำลังทำงานอยู่

นอกจากนี้หากคุณสามารถลองอีกครั้งและจับบันทึกการตรวจสอบของความพยายามนั้นและโพสต์ที่นี่มันจะบอกเราว่าทำไม:

  tail -f /var/log/audit/audit.log  (and try to attempt)

มันเป็นปัญหาการอนุญาตที่ชัดเจน แต่ไม่ใช่การอนุญาตไฟล์ :-)

ดูเหมือนว่าปัญหา (ในกรณีของฉัน ... ) เกิดจากประเภทของคีย์

ฉันเพิ่งแก้ไขได้โดยเพิ่มสิ่งต่อไปนี้ลงใน~/.ssh/configไฟล์โลคัล(เครื่องไคลเอ็นต์ Fedora 23):

PubkeyAcceptedKeyTypes=+ssh-dss

แม้ว่าฉันจะเพิ่มบรรทัดนั้นไปยังเซิร์ฟเวอร์และไฟล์ปรับแต่งไคลเอนต์ แต่ฝั่งไคลเอ็นต์ก็สร้างความแตกต่างได้ โปรดทราบว่าการอนุญาตจะต้องเป็น600ไฟล์การอ่าน

ฉันไม่รู้ว่ามีใครยังคงมีปัญหานี้หรือไม่ แต่ในที่สุดฉันก็แก้ไขได้สำหรับเครื่องเดียว (แล็ปท็อป) ที่กำลังประสบปัญหา ฉันเชื่อว่าฉันรู้ว่าท้ายที่สุดแล้วฉันจะทิ้งข้อมูลไว้ที่นี่ด้วยความหวังว่ามันจะช่วยให้คนอื่นที่อาจประสบกับปัญหานี้ - และเพื่อให้ใครบางคนหวังว่าจะสามารถตรวจสอบวิธีการแก้ปัญหาของฉันได้ แก้ไขปัญหา

ปัญหาตามที่ปรากฏไม่ได้ (สำหรับฉัน) กับ SSH เลย แต่ด้วยวิธีที่ PAM กำหนดค่าคีย์ของฉัน การกำหนดค่าในการ/etc/pam.dออกจากวันที่ (แม้ว่ามันจะทำงานอย่างถูกต้องผ่าน Fedora 22) และเป็นผลให้สิ่งที่ถูกต้องไม่ถูกทำในการเข้าสู่ระบบ [อีกต่อไป] $HOME/.ssh/เพื่อรับกุญแจของฉันจาก ใช้คำสั่งนี้:

# sudo authconfig --updateall

สร้างการกำหนดค่า /etc/pam.d ใหม่อีกครั้งอย่างถูกต้อง ในการรีบูตครั้งถัดไปหลังจากที่ฉันเข้าสู่ระบบในครั้งแรกที่ฉันพยายามที่จะ ssh ออกไปยังเซิร์ฟเวอร์ของฉันกล่องโต้ตอบขอให้ฉันป้อนข้อความรหัสผ่านของฉันสำหรับคีย์ ssh ของฉัน ( $HOME/.ssh/id_rsa) ฉันทำเช่นนั้นเลือกช่อง "ปลดล็อกอัตโนมัติเมื่อเข้าสู่ระบบ" และ voila! ความสามารถในการ ssh ออกจากแล็ปท็อปของฉันถูกคืนค่า

พื้นหลัง

เบาะแสที่ทำให้ฉันแก้ไขปัญหานี้เกิดขึ้นเมื่อฉันนำเข้าคีย์ RSA จากแหล่งภายนอก (คีย์ USB I ดำเนินการรอบกับฉัน "การเข้าถึงระยะไกล" ที่สำคัญสำหรับเครือข่ายภายในบ้านของฉัน. ฉันปิด PasswordAuth ที่จะออกไปด้านนอกหันหน้าไปทางเซิร์ฟเวอร์ของฉันปีที่ผ่านมาหลังจากการบุกรุก.) หลังจากที่ssh-addไอเอ็นจีที่คีย์ RSA ซึ่งแตกต่างจากคนหนึ่งนั่งอยู่ใน$HOME/.ssh/id_rsa, เป็นที่ยอมรับจากรีโมตเซิร์ฟเวอร์โดยไม่มีปัญหา

แล้วฉันจะจบลงด้วยการทำในสิ่งที่ควรจะได้รับการซ้ำซ้อนเพื่อรับssh-add $HOME/.ssh/id_rsaฉันสังเกตว่าหลังจากฉันทำเสร็จแล้วssh-add -lมีสองรายการสำหรับคีย์เดียวกัน:

% ssh-add -l
2048 SHA256:XXXXXXXXXXXXXXXXXXXXXX id_rsa (RSA)
2048 SHA256:XXXXXXXXXXXXXXXXXXXXXX me@host (RSA)
2048 SHA256:YYYYYYYYYYYYYYYYYYYYYY imported@usbkey (RSA)

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

ฉันเชื่อว่าเป็นสิ่งที่เกิดขึ้นจริงและ PAM ส่ง "คีย์ผิด" ไปยังตัวแทน SSH ที่ไม่ได้ปลดล็อคด้วยข้อความรหัสผ่าน ดังนั้นเมื่อ ssh พยายามรับรองความถูกต้องกับคีย์จริง ๆ แล้วมันไม่ได้มี (ปลดล็อค) ส่วนตัวครึ่งหนึ่งของคู่คีย์และการรับรองความถูกต้องล้มเหลว

บิตสุดท้ายนั้นคือการคาดเดา แต่ไม่ว่าใครก็ตามที่มีปัญหาเกี่ยวกับคีย์ ssh จะไม่ได้รับการยอมรับจากโฮสต์ระยะไกล (ซึ่งเคยเป็น) หลังจากอัพเกรดเป็น F23 การสร้าง/etc/pam.d/ไดเรกทอรีใหม่โดยใช้authconfigนั้นคุ้มค่าที่จะลองใช้วิธีแก้ปัญหา

ตรวจสอบการอนุญาตไดเรกทอรีบ้านของผู้ใช้ มันสำคัญ. ต้องเป็น 755. 700 หรือ 770 จะไม่ทำงาน

ในคุณssh_configลอง uncommenting และ / หรือเพิ่ม / ลบ / ผนวกกับอย่างใดอย่างหนึ่งCipher, CiphersหรือMACsเส้น (s)

มันจะปรากฏขึ้นกับผมว่าที่กำลังมองหาตัวเลขโดยเฉพาะอย่างยิ่งของการจัดเรียงบางอย่างที่ไม่ได้ถูกรวมอยู่ในคำขอซึ่งสามารถเพิ่มได้โดยการกำหนดค่าไว้ในของคุณsshdssh_config

... และฉันสมมติว่าคุณไม่มีโอกาสได้PubkeyAuthenticationตั้งค่าnoบนเซิร์ฟเวอร์ระยะไกลเพราะนั่นจะทำให้สิ่งนี้ล้มเหลว