ระบบสำหรับแจกจ่ายกุญแจสาธารณะ SSH


26

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

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

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


ฉันไม่สามารถตอบคำถามของคุณได้จริงๆ แต่เมื่อฉันอ่านมันฉันได้ยินเสียงกรีดร้องออกมาสำหรับระบบฐานข้อมูลบางประเภท
John Gardeniers

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

คำตอบ:


18

ตามที่กล่าวไว้แล้วโดย pulegium ซอฟต์แวร์การจัดการการกำหนดค่าทั่วไปเช่นPuppet , Chef , Bcfg2หรือcfengineสามารถทำงานให้สำเร็จได้

เนื่องจากไฟล์authorized_keysนั้นไม่ซับซ้อนคุณจึงสามารถใช้rsyncหรือ (D) SCM เช่นgitหรือhgเพื่อจัดการไฟล์นี้ คุณมีไฟล์ "master" บนเซิร์ฟเวอร์ตัวใดตัวหนึ่งของคุณและให้บริการผ่าน rsync / git / hg / … บนเซิร์ฟเวอร์อื่น ๆ ทุกเครื่องคุณเรียกใช้งาน cron ซึ่งจะดึงสำเนาต้นแบบเป็นระยะ (หากมีการเปลี่ยนแปลง) และคัดลอกไปยังตำแหน่งโลคัลที่ถูกต้อง Heck สิ่งนี้จะทำงานกับ HTTP หรือ FTP ที่แท้จริง

บรรทัดล่างคือ: มีสำเนา "master" หนึ่งไฟล์ของ authorized_keys ของคุณและอัปเดต ปล่อยให้ "ไคลเอนต์" (คอมพิวเตอร์ซึ่งควรมีไฟล์ authorized_keys ปัจจุบัน) ดึงข้อมูลจากเซิร์ฟเวอร์หลักของคุณและปรับใช้ในเครื่อง


1
เราใช้หุ่นเชิดเพื่อจัดการเซิร์ฟเวอร์ลินุกซ์ ~ 200 (คีย์ผับเป็นเพียงไฟล์เพื่อบังคับใช้เป็นแอตทริบิวต์ของผู้ใช้)
ForgeMan

1
ฉันจะยอมรับคำตอบนี้ดูเหมือนว่าฉันจะไม่ดีขึ้น ดูเหมือนว่าตัวเลือกสำหรับฉันคือ: 1. รักษาสิ่งต่าง ๆ เช่นตอนนี้ 2. สร้างห่วงโซ่เครื่องมือของตัวเองเพื่อจัดการไฟล์ authorized_keys 3. ใช้เครื่องมือทั่วไปที่มีอยู่สำหรับการจัดการเซิร์ฟเวอร์เช่น Puppet หรือ Chef …แม้ว่าเครื่องมือเหล่านั้นดูเหมือนจะใหญ่เกินไปสำหรับ งานง่าย ๆ นี้ 4. ใช้กลไกการพิสูจน์ตัวตน / การอนุญาตอื่น ๆ (เช่น Kerberos) …แม้ว่านี่จะดูเหมือนว่าเป็นเครื่องมือที่ซับซ้อนเกินไปสำหรับงานง่ายๆขอบคุณ
Jacek Konieczny

ระบบนี้มีความปลอดภัยเท่ากับช่องทางที่จะดึงสำเนาต้นฉบับ
yrk

1
Ansible เป็นระบบ CM ที่มีน้ำหนักเบามากซึ่งมีโมดูลสำหรับโคลนด้วยไฟล์คีย์ที่ได้รับอนุญาตผ่าน ssh ดูansible.cc/docs/modules.html#authorized-key
RS

11

มีโปรแกรมปะแก้สำหรับ OpenSSH ที่อนุญาตให้ใช้พับลิกคีย์จากเซิร์ฟเวอร์ LDAP แต่สิ่งนี้สมเหตุสมผลจริง ๆ ถ้าการตรวจสอบ auth / บัญชีของคุณทำกับเซิร์ฟเวอร์ LDAP นั้นด้วย (ซึ่งเป็นวิธีการตั้งค่าสภาพแวดล้อมของฉัน) นอกจากนี้ยังปลอดภัยพอ ๆ กับการกำหนดค่า LDAP ของคุณ (ดังนั้นคุณต้องการใช้ SSL และการยืนยันคีย์)

ดูhttp://code.google.com/p/openssh-lpk/เพื่อดูแพตช์และรายละเอียดเพิ่มเติม ฉันไม่รู้จักระบบปฏิบัติการใด ๆ ที่มาพร้อมกับโปรแกรมแก้ไขนี้ตามค่าเริ่มต้น แต่ถ้าคุณใช้ FreeBSD จะเป็นตัวเลือกเสริมหากคุณใช้ OpenSSH จากพอร์ต


1
บังเอิญใช้ pam_ldap ยังช่วยให้คุณแก้ปัญหา "คนที่ได้รับอนุญาตให้เข้าถึงเครื่อง A วันนี้อาจไม่ได้รับอนุญาตให้เข้าถึงได้ในวันพรุ่งนี้" ปัญหา - อ่านบน pam_ldap ถ้าคุณสนใจในด้านนั้น ...
voretaq 7

5

ฉันเรียกใช้โซลูชันที่ง่ายมากซึ่งทำเช่นเดียวกันกับกฎไฟร์วอลล์

ตัวอย่างไฟล์ hosts.conf:

192.168.0.1
192.168.2.99
192.168.2.100

distribute.sh:

#!/bin/bash
for d in `cat ./hosts.conf`; do
  echo "copying to $d ...";
  scp /root/.ssh./authorized_keys root@$d:/root/.ssh./authorized_keys
done;

นั่นคือความมหัศจรรย์ทั้งหมด :-)


5

ฉันกำลังตรวจสอบจากSSH KeyDB มันมีจุดมุ่งหมายที่จะทำอย่างนั้นจัดการบทบาทเซิร์ฟเวอร์และผู้ใช้แจกจ่ายรหัสผู้ใช้รวบรวมกุญแจโฮสต์เป็นต้นนอกจากนี้ยังมีบางสิ่งที่เรียกว่า "ตำแหน่งที่ตั้ง"

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


1

ฉันไม่แน่ใจว่าคุณหมายถึงใครหลายคนและไม่รู้ว่าคุณต้องการเปลี่ยนแปลงหรือไม่ แต่ Kerberos เป็นหุ่นยนต์ที่คุณต้องการ ที่จะแก้ปัญหาของคุณอย่างหรูหราและจะตรวจสอบทั้งคนและเครื่องจักร


1

คุณมีปัญหาที่แตกต่างกันสองข้อ (ซึ่งโดยทั่วไปจะกลายเป็น 3) ซึ่งคุณกำลังพยายามแก้ไข:

  • การรับรองความถูกต้อง (คุณคือใคร)
  • การอนุญาต (คุณได้รับอนุญาตให้เข้าถึงเซิร์ฟเวอร์นี้หรือไม่)
  • การตรวจสอบ (คุณทำอะไร)

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

นั่นคือสิ่งที่โซลูชั่นเช่น Kerberos เข้ามาเล่น ในโลกของ Windows Active Directory แก้ปัญหานี้ได้ ในโลกยูนิกซ์มีตัวเลือกมากมายซึ่งเป็นทั้งสิ่งดีและสิ่งเลวร้าย

ฉันจะลองดูโปรเจ็กต์Red Hat FreeIPAซึ่งเป็นชุดซอฟต์แวร์ที่ทำให้การติดตั้งระบบ Kerberos / LDAP / DNS เหมือนโฆษณาได้อย่างง่ายดาย


ฉันเข้าใจความแตกต่างระหว่างการตรวจสอบสิทธิ์และการตรวจสอบ และ SSH ของ 'authorized_keys' ให้ทั้งข้อมูลการตรวจสอบและการอนุญาต มันไกลจากความสมบูรณ์แบบ แต่มันเรียบง่าย และความเรียบง่ายมักเป็นข้อได้เปรียบที่สำคัญเช่นกันในเรื่องความปลอดภัย Kerberos ที่มีโครงสร้างพื้นฐานที่ซับซ้อนอาจมีความปลอดภัยล้มเหลวในรูปแบบที่มากกว่า ssh ด้วยไฟล์ authorized_keys แม้ว่าจะไม่ได้หมายความว่าอย่างใดอย่างหนึ่งจะปลอดภัยมากขึ้น
Jacek Konieczny

การจัดการไฟล์ authorized_keys คือ np สำหรับเซิร์ฟเวอร์จำนวนหนึ่ง แต่คุณเข้าถึงจุดที่เป็นไปไม่ได้ในการจัดการอย่างรวดเร็ว ฉันไม่ได้พยายามบอกว่ามันเป็นทางออกที่ "ไม่ดี" ความซับซ้อนใน Kerberos นั้นไม่เหมาะสมสำหรับเซิร์ฟเวอร์สองเครื่อง ... แต่การลงทุนในการออกแบบ / ติดตั้ง Kerberos นั้นคุ้มค่าในสภาพแวดล้อมขนาดใหญ่
duffbeer703

1

คุณสามารถใช้Bcfg2กับbcfg2 บัญชีauthorized_keysเพื่อแจกจ่าย ในฐานะโบนัสที่เพิ่มเข้ามาคุณจะสามารถควบคุมผู้ใช้และกลุ่มได้

Bcfg2 ช่วยให้การบำรุงรักษาที่ปราศจากความเจ็บปวด /etc/ssh/ssh_known_hostsด้วยSSHbaseเช่นกัน


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