SSH: กลุ่ม DH_GEX อยู่นอกช่วง


18

เมื่อเร็ว ๆ นี้เราได้นำ patch มาใช้กับผู้จำหน่ายสำหรับ OpenSSH โปรแกรมแก้ไขนี้ปิดใช้งานโปรโตคอลการแลกเปลี่ยนคีย์สองสามตัวเพื่อตอบสนองต่อการโจมตี Logjam ล่าสุด หลังจากใช้ชุดข้อมูลแก้ไขนี้เรามีผู้จำหน่ายไม่กี่รายที่เราไม่สามารถแลกเปลี่ยนไฟล์ผ่าน sftp ได้เนื่องจากการเจรจาการเชื่อมต่อล้มเหลว (น่าจะเกิดจากอัลกอริธึมการแลกเปลี่ยนคีย์ที่เลิกใช้

ฉันต้องการตรวจสอบบางสิ่งที่เราเห็นก่อนพูดคุยกับผู้ขายของเรา นี่คือเซสชัน SSH ตัวอย่างที่มีหนึ่งในผู้ขายที่มีปัญหา (เพิ่มหมายเลขบรรทัด):

# ssh -vv user@host.domain.com
01 OpenSSH_6.2p2, OpenSSL 0.9.8j-fips 07 Jan 2009
02 debug1: Reading configuration data /etc/ssh/ssh_config
03 debug1: /etc/ssh/ssh_config line 20: Applying options for *
04 debug2: ssh_connect: needpriv 0
05 debug1: Connecting to host.domain.com [1.2.3.4] port 22.
06 debug1: Connection established.
07 debug1: permanently_set_uid: 0/0
08 debug1: identity file /root/.ssh/id_rsa type -1
09 debug1: identity file /root/.ssh/id_rsa-cert type -1
10 debug1: identity file /root/.ssh/id_dsa type -1
11 debug1: identity file /root/.ssh/id_dsa-cert type -1
12 debug1: identity file /root/.ssh/id_ecdsa type -1
13 debug1: identity file /root/.ssh/id_ecdsa-cert type -1
14 debug1: Enabling compatibility mode for protocol 2.0
15 debug1: Local version string SSH-2.0-OpenSSH_6.2
16 debug1: Remote protocol version 2.0, remote software version GXSSSHD_Comments
17 debug1: no match: GXSSSHD_Comments
18 debug2: fd 3 setting O_NONBLOCK
19 debug1: SSH2_MSG_KEXINIT sent
20 debug1: SSH2_MSG_KEXINIT received
21 debug2: kex_parse_kexinit: ecdh-sha2-nistp256,ecdh-sha2-nistp384,ecdh-sha2-nistp521,diffie-hellman-group-exchange-sha256,diffie-hellman-group-exchange-sha1,diffie-hellman-group14-sha1,diffie-hellman-group1-sha1
22 debug2: kex_parse_kexinit: ecdsa-sha2-nistp256-cert-v01@openssh.com,ecdsa-sha2-nistp384-cert-v01@openssh.com,ecdsa-sha2-nistp521-cert-v01@openssh.com,ssh-rsa-cert-v01@openssh.com,ssh-dss-cert-v01@openssh.com,ssh-rsa-cert-v00@openssh.com,ssh-dss-cert-v00@openssh.com,ecdsa-sha2-nistp256,ecdsa-sha2-nistp384,ecdsa-sha2-nistp521,ssh-rsa,ssh-dss
23 debug2: kex_parse_kexinit: aes128-ctr,aes192-ctr,aes256-ctr,arcfour256,arcfour128,aes128-cbc,3des-cbc,blowfish-cbc,cast128-cbc,aes192-cbc,aes256-cbc,arcfour,rijndael-cbc@lysator.liu.se
24 debug2: kex_parse_kexinit: aes128-ctr,aes192-ctr,aes256-ctr,arcfour256,arcfour128,aes128-cbc,3des-cbc,blowfish-cbc,cast128-cbc,aes192-cbc,aes256-cbc,arcfour,rijndael-cbc@lysator.liu.se
25 debug2: kex_parse_kexinit: hmac-md5-etm@openssh.com,hmac-sha1-etm@openssh.com,umac-64-etm@openssh.com,umac-128-etm@openssh.com,hmac-sha2-256-etm@openssh.com,hmac-sha2-512-etm@openssh.com,hmac-ripemd160-etm@openssh.com,hmac-sha1-96-etm@openssh.com,hmac-md5-96-etm@openssh.com,hmac-md5,hmac-sha1,umac-64@openssh.com,umac-128@openssh.com,hmac-sha2-256,hmac-sha2-512,hmac-ripemd160,hmac-ripemd160@openssh.com,hmac-sha1-96,hmac-md5-96
26 debug2: kex_parse_kexinit: hmac-md5-etm@openssh.com,hmac-sha1-etm@openssh.com,umac-64-etm@openssh.com,umac-128-etm@openssh.com,hmac-sha2-256-etm@openssh.com,hmac-sha2-512-etm@openssh.com,hmac-ripemd160-etm@openssh.com,hmac-sha1-96-etm@openssh.com,hmac-md5-96-etm@openssh.com,hmac-md5,hmac-sha1,umac-64@openssh.com,umac-128@openssh.com,hmac-sha2-256,hmac-sha2-512,hmac-ripemd160,hmac-ripemd160@openssh.com,hmac-sha1-96,hmac-md5-96
27 debug2: kex_parse_kexinit: none,zlib@openssh.com,zlib
28 debug2: kex_parse_kexinit: none,zlib@openssh.com,zlib
29 debug2: kex_parse_kexinit:
30 debug2: kex_parse_kexinit:
31 debug2: kex_parse_kexinit: first_kex_follows 0
32 debug2: kex_parse_kexinit: reserved 0
33 debug2: kex_parse_kexinit: diffie-hellman-group1-sha1,diffie-hellman-group14-sha1,diffie-hellman-group-exchange-sha1,diffie-hellman-group-exchange-sha256
34 debug2: kex_parse_kexinit: ssh-dss,ssh-rsa
35 debug2: kex_parse_kexinit: aes128-cbc,3des-ctr,aes128-ctr,3des-cbc,blowfish-cbc,arcfour,arcfour128
36 debug2: kex_parse_kexinit: aes128-cbc,3des-ctr,aes128-ctr,3des-cbc,blowfish-cbc,arcfour,arcfour128
37 debug2: kex_parse_kexinit: hmac-md5,hmac-sha1,hmac-md5-96,hmac-sha1-96,hmac-sha256,hmac-sha256@ssh.com
38 debug2: kex_parse_kexinit: hmac-md5,hmac-sha1,hmac-md5-96,hmac-sha1-96,hmac-sha256,hmac-sha256@ssh.com
39 debug2: kex_parse_kexinit: none,zlib
40 debug2: kex_parse_kexinit: none,zlib
41 debug2: kex_parse_kexinit:
42 debug2: kex_parse_kexinit:
43 debug2: kex_parse_kexinit: first_kex_follows 0
44 debug2: kex_parse_kexinit: reserved 0
45 debug2: mac_setup: found hmac-md5
46 debug1: kex: server->client aes128-ctr hmac-md5 none
47 debug2: mac_setup: found hmac-md5
48 debug1: kex: client->server aes128-ctr hmac-md5 none
49 debug1: SSH2_MSG_KEX_DH_GEX_REQUEST(1536<3072<8192) sent
50 debug1: expecting SSH2_MSG_KEX_DH_GEX_GROUP
51 DH_GEX group out of range: 1536 !< 1024 !< 8192`

ดังนั้นในระหว่างการเจรจาแลกเปลี่ยนหลักลูกค้าและเซิร์ฟเวอร์แลกเปลี่ยนรายการอัลกอริทึมที่รองรับ (บรรทัด 21 และ 33) พวกเขาตกลงที่จะใช้นัดแรกที่พบในสองรายการในกรณีdiffie-hellman-group-exchange-sha1นี้ ดังที่ฉันเข้าใจแล้วอัลกอริธึมนี้สนับสนุนช่วงความยาวบิตที่ไคลเอนต์และเซิร์ฟเวอร์ต้องเจรจา ภายใต้สถานการณ์ปกติไคลเอ็นต์และเซิร์ฟเวอร์เห็นด้วยกับความยาวบิตและคีย์แลกเปลี่ยนทำให้การใช้งานของ DH สำคัญจากmoduliไฟล์เช่น/etc/ssh/moduli(ฉันรู้ว่าคำสั่งสุดท้ายนี้เป็นอย่างมาก "พูดของฆราวาส" แต่ที่เป็นประมาณยาวและระยะสั้นของ มัน).

ในกรณีนี้สิ่งที่ฉันคิดว่าฉันเห็นคือการเจรจาต่อรองความยาวบิตล้มเหลว ที่บรรทัดที่ 49 ไคลเอนต์ (ฉัน) กำลังพูดว่า "ฉันรองรับความยาวบิตระหว่าง 1536 ถึง 8192 และต้องการใช้ 3072 บิต" อย่างไรก็ตามเซิร์ฟเวอร์ตอบกลับและแจ้งว่า "ฉันรองรับ 1024 บิตเท่านั้น" เมื่อถึงจุดนี้ลูกค้าก็ยอมแพ้และพูดว่า "ฉันไม่สามารถคุยกับคุณได้" นี่เป็นคำอธิบายที่สมเหตุสมผลว่าเกิดอะไรขึ้นที่นี่

ดังที่ฉันเข้าใจแล้วปัญหานี้เกิดขึ้นที่จุดสิ้นสุดของเซิร์ฟเวอร์ทั้งหมด (สมมติว่าเราไม่ได้เจรจากับอัลกอริทึมที่อ่อนแอกว่านี้diffie-hellman-group1-sha1) เซิร์ฟเวอร์จะต้องได้รับการแก้ไขเพื่อรองรับความยาวบิตที่ใหญ่กว่าในระหว่างกระบวนการแลกเปลี่ยนคีย์

ฉันต้องการให้แน่ใจว่าฉันเข้าใจอย่างถูกต้องก่อนดำเนินการต่อ การป้อนข้อมูลเป็นที่นิยม


1
คุณอ่านถูกต้องแล้ว อะไรในโลกอยู่ที่ปลายอีกด้าน? ไม่เหมือนกับเซิร์ฟเวอร์ ssh ทั่วไป
Michael Hampton

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

คุณคิดว่าธนาคารจะเป็นบิตเพิ่มเติมเกี่ยวกับด้านบนของการรักษาความปลอดภัย แต่อนิจจา ...
ไมเคิลแฮมป์ตัน

2
การค้นหา "GXSSSHD_Comments" จะแสดงความคิดเห็นในฟอรัมลูกค้า SFTP ต่างๆซึ่งดูเหมือนจะแนะนำว่าเซิร์ฟเวอร์ของคุณเป็นแอปพลิเคชันGXS MFT ซึ่งเป็นสิ่งที่น่ากลัวมาก
Castaglia

คำตอบ:


21

หากคุณต้องการใช้ OpenSSH ที่ใหม่กว่าเพื่อเชื่อมต่อกับเซิร์ฟเวอร์ที่เลิกใช้แล้ว:

ssh -o KexAlgorithms=diffie-hellman-group14-sha1 -o HostKeyAlgorithms=+ssh-dss my.host.com

เพิ่ม -v หากคุณต้องการดูว่าเกิดอะไรขึ้นและ -o HostKeyAlgorithms = ssh-dss หากยังไม่ทำงาน:

ssh -v -o HostKeyAlgorithms=ssh-dss -o KexAlgorithms=diffie-hellman-group14-sha1 my.host.com

นอกจากนี้คุณยังสามารถแก้ไข / etc / ssh / ssh_config หรือ ~ / .ssh / ssh_config และเพิ่ม:

Host my.host.com *.myinsecure.net 192.168.1.* 192.168.2.*
    HostKeyAlgorithms ssh-dss
    KexAlgorithms diffie-hellman-group1-sha1    

https://forum.ctwug.za.net/t/fyi-openssh-to-access-rbs-openssh-7/6069กล่าวถึงการแก้ไขต่อไปนี้บนเราเตอร์ Mikrotik:

/ip ssh set strong-crypto=yes

(การสังเกตที่นี่เพราะคำตอบนี้เกิดขึ้นกับการค้นหาเว็บเมื่อค้นหาข้อความแสดงข้อผิดพลาดที่คล้ายกัน)

หากคุณต้องการใช้งานผ่าน Git โดยไม่ต้องแก้ไข ssh_config หรืออัปเดตเซิร์ฟเวอร์ SSH:

GIT_SSH="ssh -oHostKeyAlgorithms=+ssh-dss -oKexAlgorithms=diffie-hellman-group14-sha1" git clone ssh://user@host/path-to-repository

2
ใช้งานได้กับ SFTP ด้วย
bao7uo

11

ดูเหมือนว่าคุณจะได้รับข้อผิดพลาดนี้

สาเหตุ

มีการเปลี่ยนแปลงกับแพ็คเกจ openssh ซึ่งจัดการกับ Diffie-Hellman Group Exchange ก่อนหน้านี้กุญแจขนาด 1024 - 8192 สามารถแลกเปลี่ยนได้ ขั้นต่ำถูกยกระดับเป็น 1536 เพื่อเพิ่มความปลอดภัยและหลีกเลี่ยงช่องโหว่ "logjam" อย่างไรก็ตามหากใช้กับการใช้งาน ssh ของบุคคลที่สามซึ่งรองรับ 1024 เท่านั้นความล้มเหลวจะเกิดขึ้น เป็นการดีที่ควรมีการอัปเดตการกำหนดค่าหรือรหัสของบุคคลที่สามเพื่อใช้ขนาดคีย์ที่ใหญ่ขึ้น

...

คุณสามารถค้นหาความละเอียดที่แตกต่างกัน 3 แบบในลิงค์ ในสถานการณ์ที่คุณไม่มีอำนาจของผู้ดูแลระบบหรือมีระบบราชการมากเกินไปที่จะได้รับการเปลี่ยนแปลงที่ลึกกว่านั้นให้กำจัดอัลกอริธึมที่เป็นปัญหาขณะรอความพร้อมใช้งาน SHA-2 ในเซิร์ฟเวอร์ดูเหมือนจะเป็นตัวเลือกที่ดีที่สุดสำหรับฉัน คุณสามารถทำได้โดยใช้ผู้ใช้ในไฟล์ $ HOME / .ssh / config

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