มีวิธีที่ปลอดภัยในการจัดเก็บรหัสผ่านที่ใช้สำหรับ ssh โดยสคริปต์หรือไม่


16

ดังนั้นก่อนอื่นฉันรู้ว่าฉันควรใช้การตรวจสอบคีย์ด้วย SSH ไม่จำเป็นต้องอธิบายให้ฉันฟัง

ปัญหาที่นี่คือฉันมีเครือข่ายเซิร์ฟเวอร์ (ใหญ่) และฉันต้องมีสคริปต์สามารถเชื่อมต่อแต่ละเหล่านี้

ฉันใช้การตรวจสอบสิทธิ์ที่สำคัญทุกครั้งที่ทำได้ แต่ไม่สามารถทำได้ในทุกเซิร์ฟเวอร์ (ฉันไม่สามารถควบคุมสิ่งนี้ได้) ดังนั้น SSH ด้วยการเข้าสู่ระบบหรือบางครั้ง telnet

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

ชอบวิธีเก็บเฉพาะหรือไม่?


1
ตัวแปร Env ทำซ้ำจาก SO: stackoverflow.com/a/4410137/2579527
Travis Stoll

4
@TravisStoll Environment ไม่ปลอดภัย
Jenny D

ฉันกลัวว่าการตั้งค่าการจัดเก็บรหัสผ่านในฐานข้อมูลของคุณจะปลอดภัยเท่าที่ได้รับ คุณสามารถทำให้มันเป็น db ที่เข้ารหัสเช่นไฟล์ keepass (ฉันคิดว่ามีอย่างน้อยโมดูล perl ในการเข้าถึง keepass dbs) แต่ก็ยังคุณจะต้องเก็บรหัสผ่านไปยังฐานข้อมูลที่อื่นถ้าคุณไม่ต้องการใส่ ทุกครั้งที่คุณเรียกใช้สคริปต์ บางที IFF ที่ดีกว่านี้เล็กน้อยที่คุณป้อนรหัสผ่านหลักทุกครั้งที่คุณเรียกใช้สคริปต์ของคุณ
Isaac

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

1
"telnet บางครั้ง" ดูเหมือนจะบอกเป็นนัยว่ารหัสผ่านบางครั้งจะถูกถ่ายโอนไปยังสายชัดเจน ...
Hagen von Eitzen

คำตอบ:


24

หากสคริปต์ของคุณสามารถเชื่อมต่อกับเซิร์ฟเวอร์ใด ๆ เหล่านั้นทุกคนที่มีสิทธิ์เข้าถึงสคริปต์ (หรือสิทธิ์การเข้าถึงเครื่องที่สคริปต์ทำงานอยู่) สามารถเชื่อมต่อกับเซิร์ฟเวอร์ใด ๆ เหล่านั้นได้

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

แทนการพยายามที่จะหลีกเลี่ยงหลีกเลี่ยงไม่ได้คุณควรมุ่งเน้นไปที่การป้องกันในเชิงลึก

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

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


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

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

สิ่งที่คุณอาจต้องการที่จะต้องพิจารณาคือการย้ายตรรกะสคริปต์ลงในเซิร์ฟเวอร์ ด้วยวิธีนี้คุณจะได้รับส่วนต่อประสานที่เล็กลงซึ่งควบคุมได้ง่ายขึ้นและโดยเฉพาะ ...

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


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


14

คำตอบสั้น ๆ คือ: ไม่

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

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


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

ถ้าเขาทำท่อผ่าน stdin แสดงว่ามีช่องโหว่ ด้วยคำแนะนำของคุณจะปลอดภัยมากขึ้น แต่จะไม่สมบูรณ์อย่างนั้น โดยเฉพาะอย่างยิ่งที่บางส่วนของการประชุมมากกว่า telnet
Jenny D

0

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

แน่นอนว่านี่ไม่ใช่การเพิ่มความปลอดภัยเพิ่มเติมใด ๆ ผู้โจมตีที่มีสิทธิ์เพียงพอก็สามารถขอรหัสผ่านจากเครื่องที่ 3 ได้

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

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

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