ssh_exchange_identification: อ่าน: รีเซ็ตการเชื่อมต่อโดยเพียร์

106

ฉันใช้ OS X พยายาม ssh ไปยังเซิร์ฟเวอร์ ubuntu 12.04 ฉันสามารถใช้ SSH - จนกระทั่งสิ่งต่าง ๆ หยุดทำงานในทันที ฉันได้อ่านออนไลน์เพื่อใช้ใน-vการแก้ไขข้อบกพร่องนี้ เอาท์พุทที่แสดงด้านล่าง ถ้าฉัน ssh ลงในกล่องอื่นแล้ว ssh จากกล่องนั้นไปยังเซิร์ฟเวอร์ฉันสามารถเข้าสู่ระบบ ฉันไม่รู้ว่าจะแก้ไขปัญหานี้อย่างไร แต่ต้องการเรียนรู้

$ ssh -v me@server
OpenSSH_6.2p2, OSSLShim 0.9.8r 8 Dec 2011
debug1: Reading configuration data /etc/ssh_config
debug1: /etc/ssh_config line 20: Applying options for *
debug1: /etc/ssh_config line 53: Applying options for *
debug1: Connecting to server [IP] port 22.
debug1: Connection established.
debug1: identity file /Users/me/.ssh/id_rsa type 1
debug1: identity file /Users/me/.ssh/id_rsa-cert type -1
debug1: identity file /Users/me/.ssh/id_dsa type -1
debug1: identity file /Users/me/.ssh/id_dsa-cert type -1
debug1: Enabling compatibility mode for protocol 2.0
debug1: Local version string SSH-2.0-OpenSSH_6.2
ssh_exchange_identification: read: Connection reset by peer

จนถึงตอนนี้ (ตามคำแนะนำของกระดานข้อความ) ฉันได้ค้นหาโฮสต์ที่ปฏิเสธไฟล์ - แต่ไม่มีไฟล์ดังกล่าวในเครื่องของฉัน

$ cat /etc/hosts.deny 
cat: /etc/hosts.deny: No such file or directory

ฉันมีสิทธิ์การเข้าถึงระดับผู้ดูแลระบบบนเครื่องไคลเอนต์ แต่ไม่ใช่บนเซิร์ฟเวอร์

ssh

— bernie2436
แหล่งที่มา

ฉันอยากจะแนะนำให้เริ่มsshdฟังบนพอร์ตอื่นด้วยเอาต์พุต verbose และให้เอาต์พุตเมื่อพยายามเชื่อมต่อกับมัน $(which sshd) -d -p 23. หากคุณไม่มีความสามารถในการทำเช่นนี้ตัวเลือกของคุณค่อนข้าง จำกัด ทางออกที่ดีที่สุดคือรับคนที่มีสิทธิ์ของผู้ดูแลระบบบนเซิร์ฟเวอร์

— แพทริค

เป็นไปได้ไหมว่าผู้ดูแลระบบบนเซิร์ฟเวอร์ จำกัด การเข้าถึงของคุณด้วยเหตุผลบางอย่าง? ไม่ว่าในกรณีใดฉันอาจติดต่อบุคคลนั้น

— mdpc

12

ควรตรวจสอบไฟล์ hosts.deny และ hosts.allow บนเซิร์ฟเวอร์ไม่ใช่ที่ไคลเอ็นต์ นอกจากนี้ควรตรวจสอบระบบบันทึกในเซิร์ฟเวอร์ หากคุณไม่มีสิทธิ์เข้าถึงสิ่งเหล่านั้นคุณอาจต้องติดต่อผู้ดูแลระบบเซิร์ฟเวอร์เพื่อตรวจสอบ

— ckujau

คุณหาทางแก้มันได้หรือไม่ ปัญหาคืออะไร?

— MeV

2

เป็นรายการ hosts.deny ที่กรอกโดยผู้ดูแลระบบด้วยสคริปต์อัตโนมัติ ในขณะที่ฉันลืมรหัสผ่านในบางครั้งฉันพยายามเข้าสู่ระบบไม่สำเร็จบางครั้งซึ่งก็คือเมื่อ IP ของฉันถูกวางในรายการ hosts.deny มากสำหรับผลผลิตของการรักษาความปลอดภัยที่มากเกินไป

— K. -Michael Aye

24

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

บันทึกของคุณจะระบุสตริงเวอร์ชันโลคัลคุณควรตรวจสอบเวอร์ชันของการsshdรันบนเซิร์ฟเวอร์และเครื่องระดับกลาง

ถ้ารุ่นเหล่านี้แตกต่างกัน (โดยเฉพาะอย่างยิ่งระหว่างเครื่องท้องถิ่นและเซิร์ฟเวอร์และน้อยระหว่างเครื่องกลางและเซิร์ฟเวอร์) อาจจะมีบางเข้ากันไม่ได้เจรจาต่อรองนี้ได้เกิดขึ้นมาก่อนsshใน วิธีการแก้ปัญหาที่ใช้ในการที่จะลดยันต์ HostKeyAlgorithms และ / หรือรายการแม็คทั้งใน commandline ( ssh -c aes256-ctrอื่น ๆ ) /etc/ssh/ssh_configหรือในของคุณ

คุณควรตรวจสอบข้อมูลการดีบัก (จากการเชื่อมต่อผ่านสื่อกลางไปยังเซิร์ฟเวอร์) เพื่อหาค่าที่เหมาะสมเป็นอาร์กิวเมนต์สำหรับ-c/ Ciphers, -o HostKeyAlgorithms/ HostKeyAlgorithmsและ-m/ MACscommandline resp การเปลี่ยนแปลง ssh_config

ฉันไม่ได้มีปัญหานี้มาระยะหนึ่งแล้ว แต่ IIRC เมื่อฉันทำมันก็เพียงพอที่จะบังคับใช้การตั้งค่า Ciphers และ HostKeyAlgorithms ด้วยตนเองหลังจากนั้นฉันสามารถอัปเดตsshdเวอร์ชันของเซิร์ฟเวอร์และปัญหาหายไป

— โธ
แหล่งที่มา

3

ในกรณีของฉันsshdแพคเกจเซิร์ฟเวอร์ได้รับการอัปเดตเป็นรุ่นที่ใหม่กว่าและทำให้เกิดความไม่ลงรอยกันกับsshการกำหนดค่าไคลเอนต์ปัจจุบันของฉันตามที่คุณพูด การล้างsshไฟล์การกำหนดค่าเก่าของฉันนั้นเป็นเคล็ดลับ นี่ควรเป็นคำตอบที่ยอมรับได้

— chakrit

2

@chakrit คุณกำจัดไฟล์การกำหนดค่า ssh เก่าได้อย่างไร?

— Jonathan

@ Jonathan ฉันติดตั้งดิสก์กู้คืนเพื่อทำ

— chakrit

16

คุณอาจจะไม่ได้รับอนุญาตโดยหรือfail2ban denyhostsในกรณีดังกล่าว (และเพื่อตรวจสอบ) หากคุณไม่ต้องการรบกวนความช่วยเหลือจากผู้ให้บริการเซิร์ฟเวอร์ของคุณคุณต้องลงชื่อเข้าใช้เซิร์ฟเวอร์ของคุณจากที่อยู่ IP อื่น: เช่นเซิร์ฟเวอร์อื่นหรือการเชื่อมต่อที่บ้านของเพื่อนหรือ wifi hot spot หรือใช้ SSH กับ TOR

เมื่อเข้าสู่ระบบตรวจสอบว่าที่อยู่ IP ของคุณปรากฏขึ้นจริง/etc/hosts.deny(บนฝั่งเซิร์ฟเวอร์) ถ้าเป็นเช่นนั้นfail2banหรือdenyhostsจะต้องเป็นผู้กระทำผิดจริง

ดูคำตอบสำหรับคำถามนี้สำหรับขั้นตอนเพื่อป้องกันdenyhostsการบล็อกที่อยู่ของคุณอย่างต่อเนื่อง เพื่อfail2banค้นหาไอพีของคุณด้วยiptables -L --line-numberและยกเลิกการห้ามไอพีด้วยiptables -D <chain> <chain number>คุณตรวจสอบรายละเอียดเกี่ยวกับวิธีใช้จอร์จ

คุณอาจต้องการเพิ่มที่อยู่ IP ของคุณไปยังfail2banและdenyhostsรายการที่อนุญาต (ตามลำดับ/etc/fail2ban/jail.confบรรทัดignoreipและ/var/lib/denyhosts/allowed-hostsสร้างหากจำเป็น (แต่ระวังว่าเส้นทางอาจแตกต่างจากการแจกจ่ายของคุณ)) เพื่อป้องกันไม่ให้ปัญหาเกิดขึ้นอีกครั้ง

— Skippy le Grand Gourou
แหล่งที่มา

9

บนเซิร์ฟเวอร์โฮสต์ให้ลบ ssh pub.key ที่นี่: ~/.ssh/authorized_keysสำหรับ mac ของคุณ จากนั้นtail -f /var/log/auth.logในขณะที่คุณเปิด terminal อื่นและพยายามที่จะ ssh ssh -v me@serverอีกครั้ง หากคุณได้รับพร้อมท์ให้ใส่รหัสผ่านแสดงว่ามีปัญหากับคีย์ ssh ของคุณ หากคุณยังคงเห็นข้อความ 'ssh_exchange_identification: read: การเชื่อมต่อที่รีเซ็ทโดยเพียร์' คุณควรจะสามารถระบุได้ว่าปัญหาคืออะไรจากรายการบันทึกในไฟล์ '/var/log/auth.log' หลังจากพยายามล้มเหลว เพื่อเข้าสู่ระบบ

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

— devnull
แหล่งที่มา

ไม่จำเป็นต้องลบคีย์ SSH ในบางกรณี ตรงไปที่ tail -f /var/log/auth.log และตรวจสอบความพยายามล่าสุด

— Jack Robson

6

สิ่งนี้อาจเกิดขึ้นได้หากคุณมีเครื่องหลายเครื่องในเครือข่ายที่มีที่อยู่ MAC เดียวกัน (ตัวอย่างเช่นหากคุณทำสำเนาเครื่องเสมือนและลืมเปลี่ยน MAC)

— elCapitano
แหล่งที่มา

4

ผมได้รับนี้เนื่องจากเซิร์ฟเวอร์ ISP /etc/resolv.confของฉันใน เซิร์ฟเวอร์ชื่อเหล่านี้มักจะโอเวอร์โหลดและหากการค้นหา DNS ย้อนกลับล้มเหลวsshdจะทำให้การเชื่อมต่อลดลง 8.8.8.8ฉันจะแก้ไขปัญหาโดยใช้เซิร์ฟเวอร์เชื่อถือได้มากขึ้นเช่น

— njahnke
แหล่งที่มา

4

ฉันกำลังเผชิญกับปัญหาเดียวกัน ฉันจะเปิดเซสชันของ ssh ได้สำเร็จ แต่จะได้รับการรีเซ็ตหลังจากผ่านไประยะหนึ่ง เมื่อฉันพยายามเชื่อมต่อกำไรทันทีฉันจะได้รับข้อผิดพลาด "การเชื่อมต่อถูกปฏิเสธ" เมื่อฉัน debugged เซสชั่นฉันได้รับข้อความนี้ในเวลาที่การเชื่อมต่อได้รับการรีเซ็ต

debug1: client_input_channel_req: channel 0 rtype keepalive@openssh.com reply 1  
debug1: client_input_channel_req: channel 0 rtype keepalive@openssh.com reply 1  
debug1: client_input_channel_req: channel 0 rtype keepalive@openssh.com reply 1  
debug1: channel 0: free: client-session, nchannels 1                             
debug3: channel 0: status: The following connections are open:                   
  #0 client-session (t4 r0 i0/0 o0/0 fd 4/5 cfd -1)                              

debug3: channel 0: close_fds r 4 w 5 e 6 c -1                                    
Read from remote host 10.x.y.z: Connection reset by peer                    
Connection to 10.x.y.z closed.                                              
debug1: Transferred: stdin 0, stdout 0, stderr 100 bytes in 1029.9 seconds       
debug1: Bytes per second: stdin 0.0, stdout 0.0, stderr 0.1                      
debug1: Exit status -1

ณ จุดนี้ฉันตระหนักว่ามีความขัดแย้งที่อยู่ IP ในเครือข่าย ฉันเปลี่ยนเป็นที่อยู่อื่นและปัญหาได้รับการแก้ไขแล้ว

— เดวิด
แหล่งที่มา

2

Downvotes เกิดอะไรขึ้นกับคำตอบ? มันยังคงเป็นกรณีที่ถูกต้องในการตรวจสอบเมื่อลงรายการอาจไม่ใช่เรื่องธรรมดาในหมู่คนอื่น

— Pysis

@ รูปแบบ: ถูกต้องตอบ upvoted

— Daniel

3

บันทึกของคุณหมายความว่าฝั่งเซิร์ฟเวอร์ยกเลิกการเชื่อมต่อ เพื่อหาเหตุผลที่คุณควรปรึกษาบันทึกฝั่งเซิร์ฟเวอร์พวกเขาควรแสดงเหตุผลในการตัดการเชื่อมต่อ คุณควรจะสามารถค้นหาบันทึกใน / var / log / ข้อความได้เกือบตลอดเวลา

ฉันเดาได้ว่าเมื่อการเชื่อมต่อลดลงหลังจากที่ลูกค้าส่งหมายเลขเวอร์ชั่นเซิร์ฟเวอร์จะคุกคามไคลเอ็นต์ที่เข้ากันไม่ได้

— gena2x
แหล่งที่มา

3

ฉันมีปัญหาเดียวกัน แต่กลับกลายเป็นว่าสาเหตุแตกต่างกัน: ฉันใช้พอร์ตที่ไม่ถูกต้อง

ในรุ่นใหม่ของsshข้อผิดพลาดให้เป็นหรือConnection refusedBad port

ข้อผิดพลาดที่ระบุในรุ่นเก่าคือ ssh_exchange_identification: read: Connection reset by peer

ดังนั้นเมื่อคุณได้รับข้อผิดพลาดตรวจสอบว่าพอร์ตถูกต้อง

— Mugoma J. Okomba
แหล่งที่มา

1

ฉันรู้ว่าคำถามนี้เก่า แต่ฉันต้องการแบ่งปันสิ่งที่ฉันพบ ตรวจสอบว่า/var/empty/sshdบนเซิร์ฟเวอร์มีความเป็นเจ้าของและสิทธิ์ที่เหมาะสม

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

— Andrew Boerema
แหล่งที่มา

1

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

ข้อความสุดท้ายที่คุณได้รับจากเซิร์ฟเวอร์นั้นเป็นข้อความที่เกิดขึ้นก่อนที่คุณจะเริ่มการตรวจสอบความถูกต้องใด ๆ

ตัวอย่างของนโยบายกำลังดุร้ายดังกล่าวจากการสุ่มตัวอย่างผู้ขาย ได้แก่ :

— Jeff Schaller
แหล่งที่มา