การกำหนดค่าลายนิ้วมือ ssh บน dns เพื่อแทนที่ known_hosts ล้มเหลว


13

เร็กคอร์ด SSHFP ถูกสร้างขึ้นบนเซิร์ฟเวอร์ ssh ดังต่อไปนี้จากนั้นเพิ่มลงในโซนในการโยง:

$ ssh-keygen -r www.test.us.
www.test.us. IN SSHFP 1 1 ad04dfaf343a93beeb939eed1612168f7eadbed7
www.test.us. IN SSHFP 2 1 432209c72c4f0e99546d601dd96c04ce804191f9

ระเบียนที่ต้องการสามารถคว้าจากไคลเอนต์ ssh ผ่าน DNS ดังที่แสดง:

$ dig www.test.us any
;; QUESTION SECTION:
;www.test.us.           IN  ANY

;; ANSWER SECTION:
www.test.us.        120 IN  SSHFP   1 1 AD04DFAF343A93BEEB939EED1612168F7EADBED7
www.test.us.        120 IN  SSHFP   2 1 432209C72C4F0E99546D601DD96C04CE804191F9
www.test.us.        120 IN  A   192.168.1.50

อย่างไรก็ตาม ssh บนไคลเอนต์ล้มเหลวในการค้นหาพวกเขาเมื่อเชื่อมต่อ:

$ rm .ssh/known_hosts
$ ssh -vo VerifyHostKeyDNS=yes www
OpenSSH_5.9p1, OpenSSL 0.9.8r 8 Feb 2011
debug1: Reading configuration data /Users/test/.ssh/config
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 www [192.168.1.50] port 22.
debug1: Connection established.
debug1: identity file /Users/test/.ssh/id_rsa type 1
debug1: identity file /Users/test/.ssh/id_rsa-cert type -1
debug1: identity file /Users/test/.ssh/id_dsa type -1
debug1: identity file /Users/test/.ssh/id_dsa-cert type -1
debug1: Remote protocol version 2.0, remote software version OpenSSH_5.8p2_hpn13v11
debug1: match: OpenSSH_5.8p2_hpn13v11 pat OpenSSH*
debug1: Enabling compatibility mode for protocol 2.0
debug1: Local version string SSH-2.0-OpenSSH_5.9
debug1: SSH2_MSG_KEXINIT sent
debug1: SSH2_MSG_KEXINIT received
debug1: kex: server->client aes128-ctr hmac-md5 none
debug1: kex: client->server aes128-ctr hmac-md5 none
debug1: SSH2_MSG_KEX_DH_GEX_REQUEST(1024<1024<8192) sent
debug1: expecting SSH2_MSG_KEX_DH_GEX_GROUP
debug1: SSH2_MSG_KEX_DH_GEX_INIT sent
debug1: expecting SSH2_MSG_KEX_DH_GEX_REPLY
debug1: Server host key: RSA 69:dc:47:97:e1:a5:c9:07:4a:2b:9e:3c:a2:2b:c8:8c
DNS lookup error: name does not exist
The authenticity of host 'www (192.168.1.50)' can't be established.
RSA key fingerprint is 69:dc:47:97:e1:a5:c9:07:4a:2b:9e:3c:a2:2b:c8:8c.
No matching host key fingerprint found in DNS.
Are you sure you want to continue connecting (yes/no)?

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

เซิร์ฟเวอร์ ssh คือ FreeBSD 9.1 พร้อม OpenSSH_5.8p2_hpn13v11 และยังโฮสต์ DNS โดยใช้ BIND 9.8.3-P4 ฉันได้ลองเชื่อมต่อจาก OS X 10.8.2 กับ OpenSSH_5.9p1 เช่นเดียวกับ Arch Linux 3.6.10-1-ARCH กับ OpenSSH_6.1p1

ปรับปรุง

ในความพยายามเพิ่มเติมในการแก้ไขปัญหานี้ฉันได้เปิดตัว OpenBSD 5.2 VM ใหม่ซึ่งมี OpenSSH_6.1 อยู่ภายในเป็นเซิร์ฟเวอร์ ssh เนื่องจากการใช้งานอื่น ๆ ทั้งหมดของเซิร์ฟเวอร์ OpenSSH เป็นเพียงพอร์ตของ OpenBSD หนึ่งจึงควรทำงาน บนเซิร์ฟเวอร์ฉันสร้างระเบียน SSHFP:

# ssh-keygen -r vm1.test.us.  
vm1.test.us. IN SSHFP 1 1 419c5338920e11183380d81f002fc998389b944f
vm1.test.us. IN SSHFP 1 2 cb5bbbf5aef231f57a1a4dcf1e790f1be032b124d0d591023f33cfd5f91ec556
vm1.test.us. IN SSHFP 2 1 0fdf92ce946b5cfee5f96a3e1ef710edc50280ff
vm1.test.us. IN SSHFP 2 2 f2ee7334ee9f9a426f51f20af8f4bc7155d567c9d38a6bffaa6c643af405711e
vm1.test.us. IN SSHFP 3 1 b5e94320f0bc0b46cc6627ca7221679a65c79962
vm1.test.us. IN SSHFP 3 2 60704213a0bbd8dae813d113bfe4ae190a780b89836e6e1c567b7cfde89805f8

ฉันเพิ่มลงในเซิร์ฟเวอร์ผูก FreeBSD และโหลดชื่อใหม่ จากนั้นทดสอบเพื่อดูว่าฉันสามารถเข้าถึงบันทึกได้หรือไม่:

$ host -t any vm1
vm1.test.us has SSHFP record 1 1 419C5338920E11183380D81F002FC998389B944F
vm1.test.us has SSHFP record 1 2 CB5BBBF5AEF231F57A1A4DCF1E790F1BE032B124D0D591023F33CFD5 F91EC556
vm1.test.us has SSHFP record 2 1 0FDF92CE946B5CFEE5F96A3E1EF710EDC50280FF
vm1.test.us has SSHFP record 2 2 F2EE7334EE9F9A426F51F20AF8F4BC7155D567C9D38A6BFFAA6C643A F405711E
vm1.test.us has SSHFP record 3 1 B5E94320F0BC0B46CC6627CA7221679A65C79962
vm1.test.us has SSHFP record 3 2 60704213A0BBD8DAE813D113BFE4AE190A780B89836E6E1C567B7CFD E89805F8
vm1.test.us has address 192.168.1.60


$ dig -t any vm1.test.us
;; QUESTION SECTION:
;vm1.test.us.           IN  ANY

;; ANSWER SECTION:
vm1.test.us.        120 IN  SSHFP   1 2 CB5BBBF5AEF231F57A1A4DCF1E790F1BE032B124D0D591023F33CFD5 F91EC556
vm1.test.us.        120 IN  SSHFP   2 1 0FDF92CE946B5CFEE5F96A3E1EF710EDC50280FF
vm1.test.us.        120 IN  SSHFP   2 2 F2EE7334EE9F9A426F51F20AF8F4BC7155D567C9D38A6BFFAA6C643A F405711E
vm1.test.us.        120 IN  SSHFP   3 1 B5E94320F0BC0B46CC6627CA7221679A65C79962
vm1.test.us.        120 IN  SSHFP   3 2 60704213A0BBD8DAE813D113BFE4AE190A780B89836E6E1C567B7CFD E89805F8
vm1.test.us.        120 IN  SSHFP   1 1 419C5338920E11183380D81F002FC998389B944F
vm1.test.us.        120 IN  A   192.168.1.60

มีการแสดงระเบียนอย่างชัดเจนผ่าน DNS ดังนั้นฉันจึงลองใช้ ssh:

$ rm .ssh/known_hosts
$ ssh -vo VerifyHostKeyDNS=yes root@vm1
OpenSSH_5.9p1, OpenSSL 0.9.8r 8 Feb 2011
debug1: Reading configuration data /etc/ssh_config
debug1: Connecting to vm1 [192.168.1.60] port 22.
debug1: Connection established.
debug1: identity file /Users/test/.ssh/id_rsa type 1
debug1: identity file /Users/test/.ssh/id_rsa-cert type -1
debug1: identity file /Users/test/.ssh/id_dsa type -1
debug1: identity file /Users/test/.ssh/id_dsa-cert type -1
debug1: Remote protocol version 2.0, remote software version OpenSSH_6.1
debug1: match: OpenSSH_6.1 pat OpenSSH*
debug1: Enabling compatibility mode for protocol 2.0
debug1: Local version string SSH-2.0-OpenSSH_5.9
debug1: SSH2_MSG_KEXINIT sent
debug1: SSH2_MSG_KEXINIT received
debug1: kex: server->client aes128-ctr hmac-md5 none
debug1: kex: client->server aes128-ctr hmac-md5 none
debug1: SSH2_MSG_KEX_DH_GEX_REQUEST(1024<1024<8192) sent
debug1: expecting SSH2_MSG_KEX_DH_GEX_GROUP
debug1: SSH2_MSG_KEX_DH_GEX_INIT sent
debug1: expecting SSH2_MSG_KEX_DH_GEX_REPLY
debug1: Server host key: RSA d8:01:b5:b2:3e:c7:55:ce:19:c1:6d:77:39:92:7d:0f
DNS lookup error: name does not exist
The authenticity of host 'vm1 (192.168.1.60)' can't be established.
RSA key fingerprint is d8:01:b5:b2:3e:c7:55:ce:19:c1:6d:77:39:92:7d:0f.
No matching host key fingerprint found in DNS.
Are you sure you want to continue connecting (yes/no)? 

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

Update2

ตกลงนี่คือผลลัพธ์ของการจับแพ็คเก็ตของฉัน ssh www; ล้มเหลวด้วยมาตรฐาน

No matching host key fingerprint found in DNS.

และการดักจับแพ็กเก็ตแสดงว่า DNS ล้มเหลวในการส่งคืนเรกคอร์ดสำหรับการค้นหา

mbp13.test.us   www.test.us DNS Standard query 0x1c5e  SSHFP www
www.test.us   mbp13.test.us DNS Standard query response 0x1c5e No such name

เปรียบเทียบกับ ssh www.test.us; ซึ่งยังล้มเหลวด้วยข้อความ

No matching host key fingerprint found in DNS.

อย่างไรก็ตามการดักจับแพ็กเก็ตแสดงให้เห็นว่า DNS ส่งกลับระเบียนจริง

mbp13.test.us   www.test.us DNS Standard query 0x0ebd  SSHFP www.test.us
www.test.us   mbp13.test.us DNS Standard query response 0x0ebd  SSHFP SSHFP`

ครั้งแรกเป็นเรื่องเล็กน้อยที่จะเกิดข้อผิดพลาดเหมือนกันทั้งสองกรณี ฉันสามารถเพิ่มระเบียนบางอย่างเพื่อแก้ไขกรณีที่ 1 ซึ่งไม่มีการส่งคืนระเบียน แต่ปัญหาใหญ่คือกรณีที่ 2 DNS ทำงานและระเบียน SSHFP กำลังถูกส่งคืนไปยังไคลเอ็นต์ ssh ไม่มีแพ็กเก็ตถูกส่งหลังจากการตอบสนองการค้นหา DNS และไคลเอ็นต์ ssh แสดงข้อความลายนิ้วมือที่ไม่ตรงกันในทันที ซึ่งหมายความว่าลูกค้า ssh ทั้งหมดที่ฉันกำลังทดสอบใช้งานไม่ได้หรือลายนิ้วมือที่จัดเก็บใน DNS ไม่ถูกต้องและไม่ตรงกัน ฉันสงสัยว่ามันเป็นลูกค้าดังนั้นทำไมลายนิ้วมือใน DNS ผิด? ลายนิ้วมือถูกสร้างขึ้นจากเครื่องมือ ssh ssh-keygen ในตัวตามที่อธิบายไว้ในตอนต้นของบทความนี้ นอกจากนี้ปัญหาไม่ได้รับการช่วยเหลือจากข้อเท็จจริงที่ว่าลายนิ้วมือจะแสดงในรูปแบบที่แตกต่างกันขึ้นอยู่กับบริบท

DNS record format:      ad04dfaf343a93beeb939eed1612168f7eadbed7
ssh client mesg format: 69:dc:47:97:e1:a5:c9:07:4a:2b:9e:3c:a2:2b:c8:8c

ไม่มีใครมีข้อเสนอแนะเกี่ยวกับสาเหตุที่ลายนิ้วมือออกจาก ssh-keygen -r ไม่ตรงกับกุญแจสาธารณะที่ส่งคืนโดยเซิร์ฟเวอร์ ssh เดียวกันหรือไม่

Update3

ฉันลงไปที่ตัวเลือกสุดท้ายของฉัน ถ้าไม่มีใครชี้ให้ฉันไปในทิศทางที่ถูกต้องก่อนวันหยุดสุดสัปดาห์ฉันจะใช้เวลาวันเสาร์ของฉันในการสร้างสภาพแวดล้อมที่ซ้ำกันโดยใช้ VM ที่ใช้ OpenBSD อย่างสมบูรณ์ เนื่องจาก OpenBSD เป็นเจ้าของ OpenSSH สิ่งนี้จะต้องเป็นเงื่อนไขในอุดมคติสำหรับ SSHFP ผ่าน DNS เพื่อให้ทำงานได้ หากเซิร์ฟเวอร์ OpenBSD OpenSSH ที่มีการผูกการให้บริการลูกค้า OpenBSD OpenSSH ไม่ทำงาน SSHFP จะไม่ทำงานตามที่ใช้งานและฉันจะย้ายสิ่งต่าง ๆ ไปยังฟอรัม OpenBSD และอาจรายงานข้อผิดพลาด ฉันยังคงหวังว่าฉันไม่มีอะไรที่ชัดเจนและการตอบกลับที่เป็นประโยชน์จะช่วยให้วันหยุดสุดสัปดาห์ของฉันจบลง


คุณพยายามเชื่อมต่อเพื่อเชื่อมต่ออย่างชัดเจนwww.test.usหรือไม่?
Ulrich Dangel

ใช่. ขออภัยฉันควรได้กล่าวว่าฉันได้ลองรูปแบบทั้งหมด: ssh www; ssh www.test.us; ssh www.test.us .; ผลลัพธ์ทั้งหมดตอบกลับแบบเดียวกัน
Michael Yasumoto

อาจเป็นที่น่าสนใจที่จะเห็นจาก Wireshark / tcpdump สิ่งที่ถูกสอบถามจากเซิร์ฟเวอร์ DNS และการตอบสนองที่ถูกส่ง การรู้คำค้นหาและคำตอบที่แน่นอนจะช่วยในการค้นหาปัญหา
Gert van den Berg

Gert ฉันตอบกลับในการอัปเดตด้านบนเพราะฉันไม่สามารถตอบสนองในช่องแสดงความคิดเห็นนี้ไม่เหมาะสม
Michael Yasumoto

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

คำตอบ:


5

เห็นได้ชัดว่าปัญหาของฉันเกิดจากสองปัญหาที่แตกต่างกัน

ปัญหา # 1 SSHFP ไม่สนับสนุนการใช้พา ธ การค้นหา ดังนั้นหากคุณเพิ่ม "domain example.com" ลงใน /etc/resolv.conf คุณจะคาดหวังว่า ssh myhost จะทำงานกับ SSHFP ได้เนื่องจาก ssh ปกติจะแก้ไขชื่อเป็น myhost.example.com ได้อย่างถูกต้อง เห็นได้ชัดว่าผู้พัฒนา OpenBSD ตระหนักถึงปัญหานี้ตั้งแต่มีการติดตั้งแพตช์ 2 ปีที่ผ่านมา แต่ไม่เคยใช้งานเลย แทนที่จะแนะนำให้ใช้แฮ็ค ssh_config แต่นั่นก็ไม่ได้ผลเหมือนกัน ดังนั้นวิธีแก้ไขปัญหาแรกคือต้องใช้ FQDN กับ SSHFP เสมอ

ปัญหา # 2 การใช้ FQDN เพื่อแก้ไขปัญหาก่อนหน้านี้ทุกอย่างทำงานได้ถ้าฉันใช้ไคลเอนต์ OpenSSH เวอร์ชันปัจจุบันซึ่งเป็น OpenSSH_6.1 ไคลเอ็นต์ OpenSSH_5.8p2 บนระบบ FreeBSD ของฉันสามารถค้นหาระเบียน SSHFP สำหรับเซิร์ฟเวอร์ OpenSSH_6.1 ใหม่ได้ แต่ไม่สามารถจับคู่ลายนิ้วมือที่ได้รับจาก DNS กับที่ได้รับจากเซิร์ฟเวอร์ ไคลเอนต์ OpenSSH_5.9p1 บนเครื่อง OS X 10.8.2 ของฉันไม่สามารถดึงข้อมูลระเบียน SSHFP สำหรับเซิร์ฟเวอร์ OpenSSH_6.1 ใหม่แม้จะเป็นไคลเอนต์รุ่นที่ไม่เคยมีมามากกว่าเครื่อง FreeBSD เห็นได้ชัดว่าไม่สามารถจับคู่ระเบียน SSHFP ที่ไม่มีอยู่กับลายนิ้วมือที่ส่งคืนโดยเซิร์ฟเวอร์ OpenSSH สุดท้าย ssh-keygen ในกล่อง FreeBSD จะสร้างระเบียน SSHFP ที่ไม่ดีตามไคลเอนต์ OpenSSH_6.1 ซึ่งบ่นเกี่ยวกับการโจมตีของ MITM เนื่องจากพวกเขาไม่ได้โจมตี ไม่ตรงกับลายนิ้วมือที่เซิร์ฟเวอร์ส่งคืน วิธีแก้ปัญหาดูเหมือนว่าคุณต้องใช้งานเวอร์ชันปัจจุบันของทั้งไคลเอนต์ OpenSSH และเซิร์ฟเวอร์เพื่อให้ SSHFP ทำงานได้ การใช้เวอร์ชันเก่ากว่าของไคลเอนต์หรือเซิร์ฟเวอร์กำลังถามถึงปัญหา

ความคิดสุดท้ายที่ ใช้ SSHFP กับ DNS นั้นทันสมัยเกินกว่าที่จะใช้ในระบบปฏิบัติการแบบผสมและมีทุกอย่าง "ใช้งานได้" เนื่องจากระบบที่ไม่ใช่ของ OpenBSD ต้องเชื่อมต่อกับพอร์ตแบบพกพา OpenSSH ซึ่งล้าสมัยเมื่อถึงเวลาที่พอร์ต บางทีใน 3-5 ปี SSHFP จะมีความเสถียรพอที่แม้กระทั่งเวอร์ชั่นเก่าที่เชื่อมต่อกับระบบปฏิบัติการอื่น ๆ ก็จะเสถียรและเข้ากันได้กับเวอร์ชั่นล่าสุด


2
แม้ว่าข้อเท็จจริงที่ว่าตอนนี้ OS X (10.9) รวม OpenSSH เวอร์ชั่น 6.X แล้ว แต่ SSHFP ก็ยังใช้งานไม่ได้เนื่องจากมีการใช้งาน OS X ที่ไม่สมบูรณ์ตามที่รายงานโดย GitHub การแทนที่ด้วยไคลเอนต์ OpenSSH ที่แตกต่างกันเช่นหนึ่งจาก MacPorts เป็นทางออกเดียวในปัจจุบัน
Michael Yasumoto

0

ชื่อโฮสต์ของเซิร์ฟเวอร์ SSH กำลังเชื่อมต่อด้วยจะต้องตรงกับชื่อโฮสต์ในระเบียน SSHFP ทุกประการ นั่นคือมันไม่เพียงพอสำหรับเพียงสองชื่อโฮสต์ที่จะแก้ไขไปยังที่อยู่ IP เดียวกัน ดังนั้นssh wwwจะไม่ทำงานกับ SSHFP สำหรับ www.test.us. เว้นแต่ว่า www อยู่ในการกำหนดค่า SSH ของคุณเช่นนี้:

Host www
    Hostname www.test.us

ลองssh www.test.usดู


1
ขออภัยดูเหมือนว่าคุณจะไม่ได้อ่านการโพสต์แบบเต็มของฉันด้านบน ฉันทดสอบโดยใช้ชื่อโดเมนที่ผ่านการรับรองแบบเต็ม (FQDN) และนั่นไม่ใช่ปัญหา
Michael Yasumoto

0

คุณต้องระบุชื่อไฟล์ของรหัสสาธารณะของบริการที่คุณกำลังสร้างระเบียน DNS มิฉะนั้นจะใช้ไฟล์กุญแจสาธารณะส่วนบุคคลของคุณจาก. ssh / *. pub เป็นทางเลือกเริ่มต้น

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