ความเสี่ยงของการใช้กุญแจสาธารณะของ ssh

ฉันมีเซิร์ฟเวอร์ Aและเซิร์ฟเวอร์ B (สำรองข้อมูล) และฉันสงสัยว่าถ้ามีคนบุกเข้าไปในเซิร์ฟเวอร์ A นี่อาจเป็นอันตรายได้หากเข้าสู่เซิร์ฟเวอร์ B หากฉันกำหนดค่าการเข้าสู่ระบบแบบไม่ใช้รหัสผ่านโดยใช้คีย์สาธารณะ ssh

ฉันพยายามตั้งค่า rsnapshot

ขอบคุณ

ใช่นี่เป็นปัญหาอย่างหนึ่งของคีย์ SSH ที่ไม่มีรหัสผ่าน หากคุณเก็บคีย์ส่วนตัวบนเซิร์ฟเวอร์ A ที่อนุญาตให้คุณเชื่อมต่อกับเซิร์ฟเวอร์ B การเข้าถึงเซิร์ฟเวอร์ A นั้นเป็นการเข้าถึงเซิร์ฟเวอร์ B. ได้อย่างมีประสิทธิภาพ (ไม่ใช่การย้อนกลับไม่เป็นความจริง - การเข้าถึงเซิร์ฟเวอร์ B จะไม่ส่งผลให้ การประนีประนอมโดยทันทีของเซิร์ฟเวอร์ A สมมติว่าคุณไม่ได้ตั้งค่าคีย์ SSH เพื่ออนุญาตการลงชื่อเข้าใช้แบบไม่ใช้รหัสผ่านในทิศทางนั้น

มีบางสิ่งที่คุณสามารถทำได้เพื่อลดสิ่งนี้:

• หากกระบวนการไม่จำเป็นต้องเป็นแบบอัตโนมัติอย่างสมบูรณ์ให้เพิ่มรหัสผ่านลงในคีย์ SSH ของคุณ (สิ่งนี้อาจไม่ทำงานสำหรับคุณเนื่องจากคุณทราบว่าเป็นข้อมูลสำรอง)
• สำหรับการเข้าสู่ระบบแบบไม่ใช้รหัสผ่านภายใต้บัญชีของคุณไปยังหลายเครื่องฉันแนะนำให้สร้างรหัสผ่านสำหรับแต่ละเครื่องที่คุณพิมพ์ทางกายภาพและใช้ตัวแทน SSH เพื่อจัดเก็บคีย์ในหน่วยความจำในขณะที่คุณใช้งาน ตัวแทนการส่งต่อควรอนุญาตให้คุณ "กระโดด" จากโฮสต์ไปยังโฮสต์โดยไม่ต้องสร้างคีย์ในแต่ละโฮสต์ระยะไกล
• สำหรับคีย์ SSH แบบอัตโนมัติและไม่มีรหัสผ่านฉันขอแนะนำให้ จำกัด คำสั่งที่สามารถเรียกใช้คีย์ได้ ในauthorized_keysไฟล์ของคุณให้นำหน้าแต่ละคีย์ด้วย:
  command="<allowed command line here>",no-port-forwarding,no-X11-forwarding,no-agent-forwarding,no-pty

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

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

• สร้างบัญชีบทบาทวัตถุประสงค์เดียวสำหรับงาน: เช่นผู้ใช้dnssyncในแต่ละเครื่อง
• หากเป็นไปได้ให้ทำให้ผู้ใช้นั้นเขียนไฟล์ได้แทนการใช้รูท
• สำหรับบิตที่ต้องการการเข้าถึงที่มีสิทธิพิเศษจริงๆให้สร้างสคริปต์เพื่อใช้งานและใช้ sudo
• ใช้command=และfrom=ตัวเลือกต่าง ๆ ในauthorized_keysไฟล์เพื่อ จำกัด คีย์ passphrase-less
• สำหรับการถ่ายโอนไฟล์เขียนสคริปต์เพื่อทำโดยใช้ rsync บนเครื่องรับเพื่อให้การเข้าถึงระยะไกลสามารถอ่านได้อย่างเดียว
• หากนี่หมายความว่าจำเป็นต้องมีการเข้าถึงกลับไปยังเครื่องเริ่มต้นจากเครื่องระยะไกลให้ใช้ssh-agentแทนที่จะสร้างคีย์รหัสผ่านที่สองน้อยกว่า

มีปัญหาสองสามอย่างเกี่ยวกับคีย์ ssh:

ไม่มีวิธีการยกเลิกคีย์จากส่วนกลาง

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

นี่คือปัญหาของ Kerberos ที่แก้ไขได้ มันแนะนำคนอื่น ๆ กล่าวคือมันมีความซับซ้อนมากขึ้นในการใช้และต้องการโครงสร้างพื้นฐานการจัดการผู้ใช้จริงในการปรับใช้และจัดการ

ไม่ว่าในกรณีใดแม้ว่า ssh authorized_keys จะอนุญาตให้มีการโจมตีประเภทมอร์ริสเวิร์มแต่ก็ยังดีกว่าบริการ. r และ telnet หลายไมล์ (ปีแสง)

ในทุกสภาพแวดล้อมที่ฉันสามารถควบคุมได้ฉันมักจะเป็น stickler ตัวจริง ๆ สำหรับสิทธิพิเศษขั้นต่ำสุดสำหรับบัญชีบริการ

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

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