วิธีแก้ไข known_hosts เมื่อโฮสต์หลาย ๆ แห่งใช้ชื่อ IP และ DNS ร่วมกัน


28

ฉันเข้าสู่คอมพิวเตอร์เป็นประจำซึ่งเป็นคอมพิวเตอร์ดูอัลบูตระบบปฏิบัติการ X / Linux อินสแตนซ์ของระบบปฏิบัติการสองรายการไม่ใช้รหัสโฮสต์เดียวกันดังนั้นจึงสามารถเห็นได้ว่าเป็นโฮสต์สองรายการที่ใช้ IP และ DNS เดียวกัน สมมติว่า IP คือ192.168.0.9และชื่อคือhostnameและhostname.domainname

เท่าที่ฉันเข้าใจทางออกที่จะสามารถเชื่อมต่อกับโฮสต์ทั้งสองคือการเพิ่มพวกเขาทั้งสองไปยัง~/.ssh/know_hostsไฟล์ แต่ก็เป็นที่พูดง่ายกว่าทำเพราะไฟล์จะถกกันและมีหลายรายการอาจจะต่อโฮสต์ ( 192.168.0.9, hostname, hostname.domainname) ดังนั้นฉันได้รับคำเตือนดังต่อไปนี้

Warning: the ECDSA host key for 'hostname' differs from the key for the IP address '192.168.0.9'

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

ทางออกที่ดีจะช่วยให้ฉันเพื่อเชื่อมต่อกับต่อเนื่องไปยังคอมพิวเตอร์เครื่องนี้กับ SSH ไม่ว่าผมเรียกมันว่าไม่192.168.0.9, hostnameหรือhostname.domainnameหรือถ้าจะใช้ hostkey ลินุกซ์หรือ hostkey ของ OSX อย่างไรก็ตามฉันยังต้องการรับการเตือนหากมีการโจมตีจากกลางคนจริง ๆเช่นถ้ามีการใช้คีย์อื่นนอกเหนือจากทั้งสองนี้


คุณต้องการทำอะไร แก้ไขเพื่ออะไร
Rhyuk

@Rhyuk: แก้ไขเพื่อให้สามารถรับรู้ว่าถูกต้องทั้ง OSX และคีย์โฮสต์ linux สำหรับที่อยู่ IP, ชื่อโฮสต์และชื่อโฮสต์ชื่อโดเมน
Frédéric Grosshans

@Rhyuk: ฉันได้แก้ไขคำถามที่ ชัดเจนขึ้นแล้วหรือ
Frédéric Grosshans

2
คุณคิดว่าการติดตั้งทั้งสองแบบมีรหัสเดียวกันหรือไม่?
Zoredache

3
มีบางกรณีที่มีเหตุผลที่จะใช้ที่อยู่ IP หนึ่งรายการเพื่อเข้าถึงเอนทิตีหลาย ๆ แห่ง (แต่ละแห่งมีคีย์โฮสต์ SSH แต่ละรายการ) และยังคงมีการควบคุมที่เข้มงวดว่าเฉพาะโฮสต์คีย์เหล่านั้นเท่านั้นที่เป็นที่เห็นโดยไคลเอ็นต์ SSH เช่นการตั้งค่าความพร้อมใช้งานสูงบางอย่างที่มีการเข้าถึงกลุ่มของหน่วยโดยใช้ที่อยู่ IP ที่ใช้ร่วมกันที่หนึ่ง แต่ที่ (สำหรับเหตุผลบางประการ) คีย์โฮสต์ SSH ที่ลูกค้าเห็นการเปลี่ยนแปลงขึ้นอยู่กับหน่วยคลัสเตอร์ที่เป็นที่ใช้งานอยู่ในปัจจุบัน อีกกรณีหนึ่งคือเมื่อโฮสต์ SSH หลายแห่งอยู่หลังไฟร์วอลล์ NATed และเข้าถึงได้จากภายนอกพวกเขาทั้งหมดดูเหมือนจะมี IP เดียวกัน
IllvilJa

คำตอบ:


11

ทางออกที่ตรงไปตรงมาที่สุดคือการใช้คีย์โฮสต์เดียวกันสำหรับ Linux และ OS X นั่นคือเลือก/etc/ssh/ssh_host_*_key*ไฟล์หนึ่งชุดแล้วคัดลอกไปยังระบบปฏิบัติการอื่น จากนั้นคีย์โฮสต์เดียวกันจะนำเสนอให้กับลูกค้า SSH โดยไม่คำนึงถึงระบบปฏิบัติการที่คุณได้บูตเครื่องไว้และไคลเอนต์ SSH จะไม่ฉลาดเท่านี้


ฉันต้องการเวอร์ชันของลูกค้า แต่ฉันจะลองอันนี้หากฉันไม่พบ โดยวิธีการที่ OSX (ที่ไม่ได้มาตรฐาน) การแปลของไฟล์ที่เป็นไม่ได้/private/etc/ssh_host* /etc/ssh/ssh_host*
Frédéric Grosshans

การคัดลอกไฟล์จากเครื่องหนึ่งไปยังอีกเครื่องหนึ่ง (สองเครื่อง linux) ไม่ได้ผลสำหรับฉัน แม้ว่าเนื้อหาของไฟล์จะเหมือนกันแฮชไม่ได้เป็นเช่นนั้นดังนั้นฉันจึงยังคงได้รับปัญหา วิธีแก้ปัญหาด้านล่างนั้นดีกว่ามาก
Stav

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

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

เป็นการดีที่จะทำเช่นนี้กับสองโฮสต์ในคลัสเตอร์ที่ใช้ที่อยู่ VRRP เดียวกันหรือไม่ บน failover โฮสต์ที่ตอบสนองจะแตกต่างกัน ฉันไม่ต้องการรับคำเตือน
โคลิน 't ฮาร์ต

26

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

(คุณสามารถใช้ssh-keygen -H -F <hostname>เพื่อค้นหาบรรทัดในไฟล์ known_hosts ของคุณที่ตรงกับชื่อโฮสต์นั้นการรันหลังจากคัดลอกบรรทัดที่ถูกลบกลับควรแสดงสองรายการ)

หากใครรู้วิธีที่จะทำให้ PuTTY ทำสิ่งเดียวกันฉันก็สนใจอยากได้ยินเรื่องนี้มาก


4
ที่จริงแล้วถ้าคุณมีไคลเอนต์ linux คุณไม่จำเป็นต้องลบบรรทัดที่ละเมิดออกไปคุณต้องแสดงความคิดเห็นด้วยอักขระแฮช ('#') ที่อยู่ด้านหน้า จากนั้นเมื่อคุณยอมรับคีย์ใหม่คุณสามารถแก้ไขไฟล์ known_hosts และยกเลิกการลบเครื่องหมายบรรทัดด้วยคีย์เก่า แต่ใช่มันจะมีประโยชน์ใน Putty เช่นกัน
IllvilJa

1
หากมีสองโฮสต์ที่มีชื่อเหมือนกัน แต่ที่อยู่ IP ที่แตกต่างกันและคีย์โฮสต์ที่แตกต่างกันการแก้ปัญหานี้ยังใช้งานได้: แสดงความคิดเห็น (หรือลบชั่วคราว) จากนั้นทั้งสองบรรทัดสำหรับโฮสต์นั้น (อันที่อยู่ IP ชื่อ) เชื่อมต่อกับโฮสต์ที่ยังไม่รู้จักจากนั้นเพิ่มบรรทัดใหม่ที่ใส่เครื่องหมายความคิดเห็นหรือลบออก
Kai Petzke

11

ฉันพบสิ่งนี้ซึ่งอาจช่วยคุณในสิ่งที่คุณต้องการบรรลุ

ที่มา: https://stackoverflow.com/questions/733753/how-to-handle-ssh-host-key-verification-with-2-different-hosts-on-the-same-but

สร้างไฟล์กำหนดค่าในไดเรกทอรี. ssh ของคุณดังนี้:

Host server1
  Hostname x1.example.com
  HostKeyAlias server1
  CheckHostIP no
  Port 22001
  User karl

Host server2
  Hostname x2.example.com
  HostKeyAlias server2
  CheckHostIP no
  Port 22002
  User karl

คำอธิบายด้านล่าง (จาก man ssh_config)

CheckHostIP

หากการตั้งค่าสถานะนี้เป็น "ใช่", ssh (1) จะตรวจสอบที่อยู่ IP ของโฮสต์เพิ่มเติมในไฟล์ known_hosts สิ่งนี้อนุญาตให้ ssh ตรวจพบว่ามีการเปลี่ยนแปลงรหัสโฮสต์เนื่องจากการปลอมแปลง DNS หากตั้งค่าตัวเลือกเป็น "ไม่" การตรวจสอบจะไม่ถูกดำเนินการ ค่าเริ่มต้นคือ "ใช่"

HostKeyAlias

ระบุนามแฝงที่ควรใช้แทนชื่อโฮสต์จริงเมื่อค้นหาหรือบันทึกคีย์โฮสต์ในไฟล์ฐานข้อมูลคีย์โฮสต์ ตัวเลือกนี้มีประโยชน์สำหรับการเชื่อมต่อช่องสัญญาณ SSH หรือสำหรับเซิร์ฟเวอร์หลายเครื่องที่ทำงานบนโฮสต์เดียว

บรรทัดชื่อผู้ใช้และพอร์ตหลีกเลี่ยงการให้ตัวเลือกเหล่านั้นในบรรทัดคำสั่งด้วยดังนั้นคุณสามารถใช้:

% ssh server1
% ssh server2

ฉันเห็นบทความนี้ แต่ไม่ตรงกับกรณีของฉัน: เซิร์ฟเวอร์สองเครื่องมีความโดดเด่นด้วยหมายเลขพอร์ตในบทความไม่ใช่ในกรณีของฉัน นอกจากนี้ผมอยากจะให้ชั้นพิเศษของการรักษาความปลอดภัยนำโดยแฮชเค็มในและknown_hosts CheckHostIP
Frédéric Grosshans

1
@ FrédéricGrosshansฉันตรวจสอบการตรวจสอบ คุณไม่จำเป็นต้องมีพอร์ตแยกและตัวเลือก HashKnownHosts ทำงานได้ดีกับ HostKeyAlias
Zoredache

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

2

วิธีที่ง่ายที่สุดในการแก้ปัญหาของคุณคือการให้ที่อยู่ IP ของตนเอง / โฮสต์ที่แตกต่างกัน ด้วยที่อยู่ 253 แห่งในเครือข่าย (ส่วนตัว) และ IPv4 ของคุณนั่นจึงไม่ใช่เรื่องใหญ่อะไร กำหนด IP ที่คงที่ให้พวกเขา (เนื่องจากเซิร์ฟเวอร์ DHCP จะระบุเครื่องตามที่อยู่ MAC ของการ์ดเครือข่ายและทั้งคู่จะได้รับที่อยู่เดียวกัน) ฉันไม่เห็นวิธีแก้ปัญหาอื่น ๆ หากคุณต้องการรักษามาตรการรักษาความปลอดภัย (ซึ่งฉันจะไม่ยอม "ความสะดวกสบาย" อย่างนั้น)


ที่จริงแล้วที่อยู่ IP นั้นไม่ใช่192.168.0.xxและไม่ได้เป็นส่วนตัว มันเป็นที่อยู่ IPv4 'ของจริง' ที่กำหนดโดยมหาวิทยาลัยของฉันซึ่งฉันไม่สามารถเปลี่ยนแปลงได้
Frédéric Grosshans

หากคุณตรวจสอบกับWikipediaคุณจะเห็น 192.168.0.0 - 192.168.255.255 (คำถามของคุณระบุ 192.168.0.9 ซึ่งอยู่ในช่วงนี้) เป็นของ "ช่องว่างที่อยู่ IPv4 ส่วนตัว" ดังนั้นโดย "ส่วนตัว" ผมไม่ได้หมายถึงคุณ "เป็นเจ้าของ" แต่กับรายละเอียดของIETF ในคำถามของคุณคุณไม่ได้ระบุว่าคุณไม่สามารถเปลี่ยน IP ขออภัย - แต่เมื่อป้อนข้อมูลแล้วคำตอบของฉันก็เหมาะสม
Izzy

ขออภัยสำหรับคำถามที่ใช้ถ้อยคำไม่ดี ฉันไม่ได้ลงคะแนน
Frédéric Grosshans

ไม่มีปัญหาและไม่แจ้งให้ฉันทราบ - ทำให้ downvote ลดความท้อใจน้อยลง แต่แนวคิดอื่น: ฉันไม่แน่ใจว่าไฟล์ known_hosts นั้นใช้ชื่อโฮสต์จากนั้นทำ reverse DNS หรือเสนอโดยไคลเอนต์ คุณสามารถลองเปลี่ยนชื่อหนึ่งใน "โฮสต์" ของคุณเพื่อแสดงชื่อโฮสต์อื่น หรือเพื่อเพิ่มคีย์โฮสต์ทั้งสอง: ssh จะบอกคุณว่า "offending line" ในไฟล์ known_hosts ของคุณ (เมื่อ # 1 มี ynd ที่คุณเชื่อมต่อกับ # 2) ดังนั้นคุณสามารถคัดลอกบรรทัดนั้นไปยังไฟล์อื่นลบออกจาก known_hosts ให้ # 2 เชื่อมต่อและเพิ่มบรรทัดและเพิ่มบรรทัดที่ลบออกกลับ ไม่แน่ใจว่าใช้งานได้หรือไม่ แต่คุณสามารถลองใช้ได้
Izzy

2

ฉันไม่พบปัญหาเมื่อเชื่อมต่อกับกล่อง VPS ต่างๆที่ใช้ IP เดียวกันเนื่องจากแต่ละพอร์ตมีพอร์ต SSH ที่แตกต่างกัน (20022,30022 ฯลฯ ) ดังนั้นพวกเขาจึงลงทะเบียนเป็นโฮสต์ที่รู้จักกันพร้อมกับคีย์ที่แตกต่างกัน

นั่นอาจเป็นวิธีแก้ปัญหาสำหรับคุณ


สวัสดี @Pyheme ยินดีต้อนรับสู่ Super User! ขอให้สังเกตว่าคำถามนี้มีอายุเกือบ 4 ปี ไม่มีอะไรผิดปกติในการตอบคำถาม แต่โปรดจำไว้ว่าคุณอาจไม่ได้รับคำตอบ
Hewbot

ฉันไม่มีเครื่อง OS X ใด ๆ อีกแล้ว แต่คำตอบของคุณอาจเป็นประโยชน์กับคนอื่น นั่นคือจุดทั้งหมดของการแลกเปลี่ยนสแต็ค
Frédéric Grosshans

@Hewbot ... ฉันเห็นแล้วตอนนี้ ไม่ทราบว่าทำไมมันปรากฏในรายการคำถามล่าสุด ...
Pyheme

1

บทความอื่นซึ่งอธิบายวิธีการจัดการปัญหาของคุณได้หลายวิธี:

วิธีที่สองใช้สองพารามิเตอร์ OpenSSH: และStrictHostKeyCheckin UserKnownHostsFileเมธอดนี้ใช้เทคนิค SSH ด้วยการกำหนดค่าให้ใช้ไฟล์ known_hosts ที่ว่างเปล่าและไม่ขอให้คุณยืนยันรหัสประจำตัวของโฮสต์ระยะไกล


เอกสารนี้เกี่ยวกับการไม่อนุญาตการตรวจสอบคีย์ ฉันต้องการเก็บการตรวจสอบที่สำคัญและฉันไม่ต้องการhostnameยกเลิกการอนุญาตทุกครั้งที่มีการรีบูทเป็น Linut หรือ OSX
Frédéric Grosshans

1
ยินดีต้อนรับสู่ Super User! ในขณะที่สิ่งนี้อาจตอบคำถามในทางทฤษฎีมันก็ควรที่จะรวมส่วนสำคัญของคำตอบที่นี่และให้ลิงค์สำหรับการอ้างอิง เราได้รวมเป็นส่วนหนึ่งที่สั้น ๆ แต่มันอาจจะไม่เป็นสิ่งที่คุณตั้งใจ ...
Tamara Wijsman

1

เนื่องจากคุณต้องการให้การตรวจสอบคีย์โฮสต์ที่เข้มงวดฉันจะให้พวกเขาใช้known_hostsไฟล์ที่แตกต่างกัน หากต้องการทำสิ่งนี้ให้ตั้งค่า~/.ssh/configไฟล์ของคุณ(หรือ/etc/ssh/ssh_configไฟล์หากคุณต้องการให้สิ่งนี้ทำงานกับบัญชีผู้ใช้ภายในหลายบัญชี) ดังนี้

Host myserver.osx
  UserKnownHostsFile ~/.ssh/known_hosts.dual.osx
  # default is ~/.ssh/known_hosts
  Hostname $REALHOSTNAME

Host myserver.linux
  UserKnownHostsFile ~/.ssh/known_hosts.dual.linux
  Hostname $REALHOSTNAME

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

แล้วssh myserver.linuxและssh myserver.osxทำให้สามารถมีคีย์โฮสต์ที่แตกต่างกัน แต่คุณยังคงได้รับการตรวจสอบ หากเป็น Linux ที่อัพและคุณพิมพ์ OS X (หรือกลับกัน) คุณจะได้รับคำเตือน (ซึ่งฉันเชื่อว่าเป็นผลกระทบที่ต้องการ)

หากฉันมีปัญหานี้ฉันจะตรวจสอบให้แน่ใจว่ามีบางอย่างผิดปกติในknown_hostsไฟล์หลักที่ไม่ตรงกับไฟล์ใดไฟล์หนึ่งดังนั้นถ้าคุณพิมพ์$REALHOSTNAMEแทนที่จะmyserver.osxได้รับคำเตือน :-) ฉันจะทำอย่างนั้นโดยใส่สิ่งที่ชอบ

<ip-address-of-github.com> $REALHOSTNAME

ในของฉัน/etc/hostsจากนั้นทำssh $REALHOSTNAMEและรับคีย์ใหม่จากนั้นนำรายการนั้นออก

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