ล่าช้านานเมื่อเข้าสู่ระบบด้วย CentOS7


15

ฉันมีระบบ CentOS 7 และเมื่อฉันเข้าสู่ระบบด้วย putty หรือ ssh มีความล่าช้านานก่อนที่ฉันจะได้รับพรอมต์รหัสผ่าน ฉันวิ่ง ssh -v และฉันพบว่ามันทำให้ดีขึ้น:

debug1: ssh_ecdsa_verify: signature correct
debug1: SSH2_MSG_NEWKEYS sent
debug1: expecting SSH2_MSG_NEWKEYS
debug1: SSH2_MSG_NEWKEYS received
debug1: SSH2_MSG_SERVICE_REQUEST sent
debug1: SSH2_MSG_SERVICE_ACCEPT received

จากนั้นมันจะอยู่ที่นั่นประมาณ 1-2 นาทีแล้วเอาท์พุทนี้จะระเบิดออก:

debug1: Authentications that can continue:
publickey,gssapi-keyex,gssapi-with-mic,password
debug1: Next authentication method: gssapi-keyex
debug1: No valid Key exchange context
debug1: Next authentication method: gssapi-with-mic
debug1: Unspecified GSS failure.  Minor code may provide more information
No Kerberos credentials available
debug1: Unspecified GSS failure.  Minor code may provide more information
No Kerberos credentials available
debug1: Unspecified GSS failure.  Minor code may provide more information
debug1: Unspecified GSS failure.  Minor code may provide more information
No Kerberos credentials available
debug1: Next authentication method: publickey
debug1: Trying private key: /home/motor/.ssh/id_rsa
debug1: Trying private key: /home/motor/.ssh/id_dsa
debug1: Trying private key: /home/motor/.ssh/id_ecdsa
debug1: Trying private key: /home/motor/.ssh/id_ed25519
debug1: Next authentication method: password

แล้วรหัสผ่านจะปรากฏขึ้น สิ่งนี้เกิดขึ้นไม่ว่าผู้ใช้รายใดกำลังเข้าสู่ระบบ แต่จะเกิดขึ้นในระบบ 1 เท่านั้น ฉันมี 5 คนที่มันดำเนินการโดยไม่ล่าช้า

ไม่มีดิสก์หรือหน่วยความจำหรือข้อผิดพลาดอื่น ๆ ในบันทึก

อะไรจะทำให้ล่าช้าเช่นนี้?

UPDATE:

ฉันพยายามตั้งค่าGSSAPIAuthenticationเป็นไม่และไม่ได้แก้ปัญหา

ฉันวิ่งอีกครั้งคราวนี้ด้วย -vvv เอาท์พุทนี้ออกมาแล้วก็แขวน:

debug1: SSH2_MSG_SERVICE_ACCEPT received
debug2: key: /home/motor/.ssh/id_rsa ((nil)),
debug2: key: /home/motor/.ssh/id_dsa ((nil)),
debug2: key: /home/motor/.ssh/id_ecdsa ((nil)),
debug2: key: /home/motor/.ssh/id_ed25519 ((nil)),

หลังจาก 1-2 นาทีสิ่งนี้จะออกมา:

debug1: Authentications that can continue: publickey,password
debug3: start over, passed a different list publickey,password
debug3: preferred gssapi-keyex,gssapi-with-mic,publickey,keyboard-interactive,password
debug3: authmethod_lookup publickey
debug3: remaining preferred: keyboard-interactive,password
debug3: authmethod_is_enabled publickey
debug1: Next authentication method: publickey
debug1: Trying private key: /home/motor/.ssh/id_rsa
debug3: no such identity: /home/motor/.ssh/id_rsa: No such file or directory
debug1: Trying private key: /home/motor/.ssh/id_dsa
debug3: no such identity: /home/motor/.ssh/id_dsa: No such file or directory
debug1: Trying private key: /home/motor/.ssh/id_ecdsa
debug3: no such identity: /home/motor/.ssh/id_ecdsa: No such file or directory
debug1: Trying private key: /home/motor/.ssh/id_ed25519
debug3: no such identity: /home/motor/.ssh/id_ed25519: No such file or directory
debug2: we did not send a packet, disable method
debug3: authmethod_lookup password
debug3: remaining preferred: ,password
debug3: authmethod_is_enabled password
debug1: Next authentication method: password

จากนั้นให้ใส่รหัสผ่าน

คำตอบ:


16

ใน/etc/ssh/sshd_configเซิร์ฟเวอร์ระยะไกลของคุณคุณควรเปลี่ยนตัวเลือกGSSAPIAuthenticationเป็นไม่ รีสตาร์ท sshd และคุณน่าจะดี

แก้ไข: GSSAPI (Generic Security Service Application Application Interface) เป็นหลัก API ที่ใช้ไลบรารี Kerberos เพื่อให้การเข้ารหัสเครือข่ายที่แข็งแกร่ง หากไม่มีเหตุผลเฉพาะที่ทำให้คุณต้องเปิดใช้งาน GSSAPI วิธีนี้ควรแก้ไขปัญหาที่คุณมีอยู่

edit2: เพื่อความชัดเจนอาจเป็นไปได้ว่าการตรวจสอบ DNS ย้อนกลับนั้นหมดเวลา (โดยเฉพาะการตรวจสอบบันทึก PTR ของโฮสต์ที่เชื่อมต่อ) SSH ทำการตรวจสอบนี้เป็นเรื่องแน่นอนเพราะทำหน้าที่เป็นมาตรการรักษาความปลอดภัยเพื่อตรวจสอบความถูกต้องของโฮสต์ที่เชื่อมต่อ

กล่าวว่ากระบวนการไม่ได้เพิ่มความปลอดภัยอย่างมากเพราะในความเป็นจริงมีสัดส่วนที่สำคัญของโฮสต์ที่ไม่มี PTR อยู่ดี มีสามวิธีในการแก้ไขปัญหานี้:

1) คุณสามารถแก้ไขsshd_configไฟล์เพื่อใช้UseDNS noพารามิเตอร์ สิ่งนี้จะหยุดการค้นหา DNS ย้อนกลับ มันปลอดภัยที่จะทำ

2) เพิ่มระเบียน PTR ในระบบ DNS ที่เหมาะสมสำหรับโฮสต์ที่ช้าในการเชื่อมต่อ

3) เพิ่มรายการคู่มือลงในhostsไฟล์OS พร้อมกับรายการที่เกี่ยวข้อง

หวังว่าจะช่วย!


1
สิ่งนี้ไม่ได้แก้ไขปัญหา ยังคงมีความล่าช้า ฉันจะอัปเดตโพสต์ดั้งเดิมของฉันด้วยข้อมูลเพิ่มเติม
Larry Martell

6
อาจเป็นการค้นหา DNS ย้อนกลับที่ใช้เวลา คุณสามารถลองเพิ่มUseDNS noในไฟล์ sshd_config และโหลดบริการใหม่เพื่อดูว่ามันสร้างความแตกต่างหรือไม่
Brett Levene

ฉันจะไม่สามารถลองได้จนกว่าจะถึงสัปดาห์ถัดไป ฉันจะให้คุณรู้ว่ามันไปอย่างไร ขอบคุณ
Larry Martell

2
ใช่นั่นเป็นปัญหา ใช้UseDNS noแก้ไขและลบความล่าช้า ขอบคุณ
Larry Martell

4

ดูเหมือนว่าปัญหา DNS - ในระหว่างที่พยายามเข้าสู่ระบบการค้นหา DNS ย้อนกลับจะดำเนินการเพื่อให้ชื่อโฮสต์ระยะไกลในบันทึกรับรองความถูกต้อง

ตรวจสอบเพื่อให้แน่ใจว่าเซิร์ฟเวอร์ไม่มีตัวแก้ปัญหาที่ไม่ตอบสนองใน/etc/resolv.confไฟล์


ใช่นั่นเป็นปัญหา แก้ไขสิ่งนี้ลบความล่าช้า ขอบคุณ!
Larry Martell

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

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