เวิร์กโฟลว์ที่ราบรื่นที่สุดในการจัดการข้อผิดพลาดการตรวจสอบโฮสต์ SSH?

นี่เป็นปัญหาง่ายๆที่เราทุกคนเผชิญและอาจแก้ไขด้วยตนเองโดยไม่ต้องคิดมาก

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

รับข้อความต่อไปนี้ฉันมักจะvi /root/.ssh/known_hosts +434และลบ ( dd) บรรทัดที่ละเมิด

ฉันเคยเห็นนักพัฒนา / ผู้ใช้ในองค์กรอื่นลบไฟล์ทั้งหมด ของพวกเขาknown_hostsออกจากความยุ่งยากในการเห็นข้อความนี้ ในขณะที่ฉันไม่ได้ไปไกลขนาดนั้นฉันรู้ว่ามีวิธีการจัดการกับสิ่งนี้ที่งดงาม

เคล็ดลับ?

[root@xt ~]# ssh las-db1

@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@
@    WARNING: REMOTE HOST IDENTIFICATION HAS CHANGED!     @
@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@
IT IS POSSIBLE THAT SOMEONE IS DOING SOMETHING NASTY!
Someone could be eavesdropping on you right now (man-in-the-middle attack)!
It is also possible that the RSA host key has just been changed.
The fingerprint for the RSA key sent by the remote host is
ed:86:a2:c4:cd:9b:c5:7a:b1:2b:cc:42:15:76:8c:56.
Please contact your system administrator.
Add correct host key in /root/.ssh/known_hosts to get rid of this message.
Offending key in /root/.ssh/known_hosts:434
RSA host key for las-db1 has changed and you have requested strict checking.
Host key verification failed.

คุณสามารถใช้ssh-keygenคำสั่งเพื่อลบรายการเฉพาะโดยโฮสต์:

ssh-keygen -R las-db1

หากคุณไม่มีคำสั่งนั้นคุณสามารถใช้ sed:

sed -i '/las-db1/d' /root/.ssh/known_hosts

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

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

class ssh::hostkeys {

  @@sshkey { "${::clientcert}_rsa":
    type => rsa,
    key => $sshrsakey,
    tag => 'rsa_key',
  }

  if 'true' == $common::params::sshclient {
    Sshkey <<| tag == 'rsa_key' |>> {
      ensure => present
    }
  }

  file {'/etc/ssh/ssh_known_hosts':
    ensure => present,
    owner => 'root',
    group => 'root',
    mode => 0644,
  }

}

ฉันต้องการเพิ่มข้อเสนอแนะที่สามารถช่วยคุณในกรณีที่เฉพาะเจาะจงซึ่งความปลอดภัยมีความกังวลน้อยกว่า

ฉันมีสภาพแวดล้อมแบบแล็บพร้อมกับเครื่องที่ติดตั้งใหม่บ่อยๆ ทุกครั้งที่เกิดขึ้นจะมีการสร้างรหัสโฮสต์ใหม่ (ฉันอาจบันทึกรหัสโฮสต์ไว้ที่ใดที่หนึ่งและตั้งค่าไว้ในสคริปต์หลังการติดตั้ง)

เนื่องจากความปลอดภัยไม่ใช่ปัญหาสำหรับฉันในสภาพแวดล้อมของแล็บนี้และปุ่มเปลี่ยนบ่อยฉันจึงมีสิ่งต่อไปนี้ในไฟล์. ssh / config ของฉัน:

Host lab-*
  User kenny
  IdentityFile ~/.ssh/lab_id_rsa
  StrictHostKeyChecking no
  UserKnownHostsFile=/dev/null

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

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

ตามบันทึกประจำรุ่น openssh 5.6คุณไม่จำเป็นต้องใช้คีย์โฮสต์อีกต่อไป:

การรับรองความถูกต้องของโฮสต์อาจใช้คีย์โฮสต์ใบรับรอง ต้องระบุคีย์ CA ในไฟล์ known_hosts โดยใช้เครื่องหมาย @ cert-Authority ตามที่อธิบายไว้ใน sshd (8)

คำเตือน : ฉันไม่เคยได้ยินใครใช้คุณสมบัตินี้ในการผลิตจนถึงตอนนี้ ใช้ความเสี่ยงของคุณเอง (แต่ฉันเชื่อว่า openssh developpers เป็นคนหวาดระแวงมากพอที่จะไม่ปล่อยคุณสมบัตินักฆ่าที่ไม่มีการทดสอบและการตรวจสอบรหัสจำนวนมาก)

SSHFP DNS ResourceRecord อาจช่วยได้ขึ้นอยู่กับว่าลูกค้าของคุณใช้ประโยชน์จาก ssh มากแค่ไหน จัดเก็บลายนิ้วมือกุญแจสาธารณะของคุณทั้งหมดที่มีชื่อโฮสต์

ติดตั้ง DNSSEC หรือ DNS ผ่าน SSL ล่วงหน้า
http://www.ietf.org/rfc/rfc4255.txt

FreeIPA.org จัดการโฮสต์และการจัดการคีย์ผู้ใช้รวมถึงใบรับรอง PKI นอกจากนี้ยังอัปโหลดเรคคอร์ด SSHFP DNS โดยอัตโนมัติเมื่อสร้างคีย์ใหม่

System Security Services Daemon (SSSD) สามารถกำหนดค่าให้แคชและดึงข้อมูลคีย์ SSH โฮสต์เพื่อให้แอปพลิเคชันและบริการต้องดูที่เดียวสำหรับคีย์โฮสต์ เนื่องจาก SSSD สามารถใช้ FreeIPA เป็นหนึ่งในผู้ให้บริการข้อมูลประจำตัวของตนได้ FreeIPA จึงมีที่เก็บคีย์ส่วนกลางและส่วนกลาง ผู้ดูแลระบบไม่จำเป็นต้องกังวลเกี่ยวกับการกระจายอัปเดตหรือตรวจสอบคีย์ SSH ของโฮสต์

http://docs.fedoraproject.org/en-US/Fedora/17/html/FreeIPA_Guide/host-keys.html