คำแนะนำสำหรับการจัดการคีย์ SSH


13

อะไรคือวิธีปฏิบัติที่ดีที่สุดที่คุณพบในการจัดการคู่กุญแจ SSH จำนวนมาก?

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

เครือข่ายในบ้านของฉันประกอบด้วยแล็ปท็อปของฉัน (อูบุนตู), เดสก์ท็อปสองเครื่อง (ubuntu / fedora dual boot, fedora / windows dual boot) และระบบสื่อ (Ubuntu) ที่ทำงานฉันมีแล็ปท็อปส่วนตัว (ที่ฉันใช้สำหรับทำงานจากที่บ้าน), เดสก์ท็อปของฉัน (fedora), ระบบการผลิต (RHEL) และแล็ปท็อปที่มี windows (ถอนหายใจ) และ VM (fedora) ดีมากจนถึงตอนนี้

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

แต่ตอนนี้มา Hadoop ซึ่งเป็นคลัสเตอร์ขนาดใหญ่ของระบบมากกว่า 100+ ระบบและด้วยความซับซ้อนที่เพิ่มขึ้นผู้ใช้มากขึ้นและคู่กุญแจมากขึ้น ตอนนี้ฉันต้องจัดการกุญแจ

(ฉันต้องการคำชี้แจงฉันเป็นนักพัฒนาซอฟต์แวร์ให้คำปรึกษากับลูกค้าที่ใช้งานคลัสเตอร์ Hadoop พวกเขาจำเป็นต้องจัดการคีย์จะมีหลายคนที่เข้าถึงคลัสเตอร์ต้องวางกุญแจสาธารณะของพวกเขาลงในระบบ Linux savant พวกเขาถามฉันเพื่อขอความช่วยเหลือฉันแนะนำให้จ้างผู้ดูแลระบบ แต่จนกว่าพวกเขาจะทำฉันก็กำลังช่วย)

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

อะไรคือวิธีปฏิบัติที่ดีที่สุดที่คุณพบในการจัดการกับกุญแจจำนวนมาก?

ขอขอบคุณ!


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


คุณกำลังพูดถึงผู้ใช้หรือคู่กุญแจโฮสต์? sshfpแก้ปัญหา hostkey โดยการใส่ลายเซ็นของกุญแจสาธารณะใน DNS สำหรับข้อมูลรับรองผู้ใช้คุณอาจต้องการดูใบรับรอง OpenSSHหรือใช้บางอย่างเช่น Spacewalk หรือหุ่นเชิดเพื่อบันทึกคู่คีย์ทั้งหมดในตำแหน่งศูนย์กลางและปรับใช้ตามความจำเป็น ดูเหมือนว่าคุณอาจต้องการเวอร์ชั่นหลังเพราะคุณเพิ่งจะตั้งเซิร์ฟเวอร์ใหม่เป็นไคลเอนต์จากนั้นปรับใช้ไฟล์เวอร์ชันล่าสุด
Bratchley

ฉันมีแล็ปท็อปเครื่องอื่น (fedora) ไปยังดิสก์เครือข่าย MyBook Live (ใช้งาน linux), เดสก์ท็อปที่สร้างขึ้นสองตัวกำลังรอฮาร์ดไดรฟ์และวางแผนอีกสองตัวเพื่อสร้างคลัสเตอร์ hadoop ที่บ้าน ใช่ฉันต้องเข้าใจการจัดการที่สำคัญ
ChuckCottrill

คำตอบ:


12

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

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

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


ทีนี้ถ้าคุณถามว่าคุณจะดึงกุญแจสาธารณะออกสู่ระบบหลายร้อยระบบได้อย่างไร

วิธีที่พบมากที่สุดคือการใช้ไดเรกทอรีบ้านที่ใช้ร่วมกัน ติดตั้ง NFS (หรือระบบไฟล์เครือข่ายอื่น) (หรือติดตั้งอัตโนมัติ) ทุกระบบ

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

แน่นอนคุณสามารถทำสิ่งอื่น ๆ เช่น cron job rsync บน/homeจากเซิร์ฟเวอร์กลาง แต่นั่นไม่ใช่วิธีปฏิบัติทั่วไป


ฉันมี 8 เครื่องที่บ้านและมีจำนวนตัวแปร "เซิร์ฟเวอร์" ในระบบคลาวด์ (ปรับขนาดตามต้องการ) เป็นเรื่องโง่หากมี 300 รหัสลูกค้าเมื่อปรับขนาดอินสแตนซ์ของเซิร์ฟเวอร์สูงสุด 300 รายการ ดังนั้นฉันมีกุญแจสาธารณะ 16 อัน (ผู้ใช้ 2 คนต่อโฮสต์ 8 ตัว) สำหรับเครื่องหนักฉันกดปุ่มทุก 3 เดือน สำหรับอินสแตนซ์ของคลาวด์จะรวมอยู่ในรูปภาพที่กำหนดเอง
Skaperen

2

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

ฉันไม่เห็นข้อได้เปรียบใด ๆ ในการจัดเก็บกุญแจสาธารณะทั้งใน.ssh/authorized_keysและในไฟล์แยกต่างหาก

หากคุณดูที่คีย์จริงที่เก็บอยู่ในไฟล์ * authorized_keys * คุณจะเห็นว่าพวกเขามีเมตาดาต้าที่มนุษย์อ่านได้เกี่ยวกับต้นกำเนิดของคีย์อยู่แล้ว เช่นรหัสสาธารณะuser@fooมักจะมีรายการเช่น:

ssh-rsa AAAAB3Nza...LiPk== user@example.net

จึงทำให้ง่ายต่อการตรวจสอบ / แยก / ลบคีย์บางอย่าง (แนบกับผู้ใช้บางราย) จากไฟล์ * authorized_keys *

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

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


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

มันขึ้นอยู่กับว่าพวกเขาสร้างกุญแจอย่างไร เช่นssh-keygenจะเพิ่มความคิดเห็นของรูปแบบ th user@host; keygenerators อื่น ๆ (เช่นที่มาพร้อมกับผงสำหรับอุดรู) อาจไม่ทำเช่นนั้น แต่ใช่มันควรจะเป็นเรื่องเล็กน้อยที่จะทำให้สคริปต์เล็ก ๆ น้อย ๆ ที่ทำให้แน่ใจว่าแต่ละคีย์มีความคิดเห็นฟิลด์ที่ระบุผู้ใช้ / โฮสต์รวมกัน
umläute

1

OpenSSH ล่าสุดอนุญาตให้รับคีย์ ssh จาก LDAP ดู 'AuthorizedKeysCommand' ในหน้าsshd_config ส่วนตัวผมต้องการใบรับรอง OpenSSH ไม่คีย์ดูhttp://blog.habets.pp.se/2011/07/OpenSSH-certificates คุณสามารถจัดการคีย์ด้วยเครื่องมือจัดการการกำหนดค่าเช่น cfengine, หุ่นเชิด, เชฟ, เกลือ ...


0

อีกวิธีหนึ่งที่ง่ายต่อการติดตั้งและให้ความยืดหยุ่นในการเพิ่มผู้ใช้หลายคน https://userify.com/

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

การติดตั้งและการจัดการที่ง่ายสุด ๆ

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