ทำไมการรับรองความถูกต้องของคีย์ SSH ดีกว่าการตรวจสอบรหัสผ่าน


45

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

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

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

ฉันเข้าใจผิดบางอย่างหรือมีความกังวลที่ถูกต้องหรือไม่?


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

2
เรื่องนี้น่าจะถูกย้ายไปที่ความปลอดภัย

10
@DKGasser: ไม่ไม่ควรทำ มันเป็นคำถามที่ถูกต้องสมบูรณ์แบบที่นี่ เพียงเพราะบางสิ่งสามารถย้ายไปยังไซต์ SE อื่นไม่ได้หมายความว่าควรจะเป็น
Wuffers

4
@DKGasser: มันสามารถไปที่เว็บไซต์นั้นมันเป็นคำถามที่ถูกต้องสมบูรณ์มี แต่มันก็เป็นคำถามที่ถูกต้องที่นี่ดังนั้นจึงไม่มีเหตุผลที่จะย้ายข้อมูล หากคำถามนี้ถูกตัดออกจากหัวข้อที่นี่ใช่แล้วสามารถย้ายไปที่นั่นได้ แต่มันเป็นหัวข้อทั้งหมดในเว็บไซต์นี้ดังนั้นจึงไม่ควรย้ายข้อมูล
Wuffers

3
และอย่าลืมรหัส SSH จะไม่ผ่านเครือข่าย รีโมตเซิร์ฟเวอร์ไม่เคยได้รับกุญแจซึ่งตรงข้ามกับรหัสผ่านที่ไม่เพียง แต่ส่งผ่านเครือข่าย แต่ส่งไปยังเซิร์ฟเวอร์ระยะไกล ลองนึกถึงครั้งต่อไปที่คุณไม่แน่ใจว่าจะใช้รหัสผ่านใดและลองใช้ ... ที่อาจใช้กับบัญชีอื่น! คุณส่งรหัสผ่านใดไปยังเซิร์ฟเวอร์นั้น
9mjb

คำตอบ:


40

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

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

ความจริงที่ว่าคีย์ส่วนตัวมักได้รับการปกป้องโดยวลีรหัสผ่านที่ยาวนานนั้นมีความสำคัญรอง

ปรับปรุง:

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

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

นอกจากนี้http://xkcd.com/538/

ความปลอดภัย


7
+1 ยกเว้นว่ารหัสสาธารณะรับรองความถูกต้องจะไม่ทำอะไรเลยสำหรับบันทึกของคุณที่ถูกบล็อกโดยบ็อตที่พยายามเชื่อมต่อ หากต้องการหยุดให้เรียกใช้เซิร์ฟเวอร์ SSH ของคุณบนพอร์ตสูง (เช่น 9876 แทนที่จะเป็น 22) ถ้าพวกเขาต้องการโจมตีคุณพวกเขาจะต้องสแกนพอร์ตให้คุณก่อนและโดยทั่วไปบอทจะไม่เสียเวลามากนัก ... มีเซิร์ฟเวอร์ SSH มากมายในวันที่ 22
Ex Umbris

3
คุณไม่ได้ล้อเล่นกับขนาดบันทึก - / var / log / secure ของฉันเพิ่มขึ้นจากเมกะไบต์ของความพยายามในการเข้าสู่ระบบเป็นกิโลไบต์ (มีเพียงบันทึกการเข้าสู่ระบบของฉัน)
John C

2
+1 น่าสนใจฉันทำงานด้วยรหัสผ่านที่รับรองความถูกต้องสำหรับ .. เช่น 10 ปีแล้ว .. ฮ่า ๆ .. ได้รับแล้วพอร์ต ssh ที่เปิดเผยต่อสาธารณชนของฉันจะไม่พอร์ต 22 คิดว่า botnets จะพอร์ตสแกนฉันและพยายามเข้ามาทุกครั้ง พอร์ตพวกเขาสามารถ? ข้อมูลดีขอบคุณ
James T Snell

2
@ExUmbris แทนที่จะเปลี่ยนพอร์ตที่คุณควรพิจารณาการใช้fwknop: โสด Packet การอนุมัติและท่าเรือเคาะ ประโยชน์ที่ควรจะชัดเจน: เมื่อคุณไม่อนุญาตให้ทุกคนเห็นว่าพอร์ตเปิดอยู่ที่ใดก็ได้เว้นแต่พวกเขาจะได้รับอนุญาตให้เข้าถึงพอร์ตผ่านการเคาะด้วยสปาแล้วพวกเขาก็ไม่สามารถแม้แต่จะหามันด้วย nmap และ ใช้ประโยชน์จากมัน นั้นดีกว่าความปลอดภัยง่าย ๆ ผ่านความสับสน
aculich

@aculich การเปลี่ยนพอร์ตไม่ใช่ "ความปลอดภัยผ่านความสับสน" ทั้งหมดที่ฉันทำคือการป้องกันไม่ให้บันทึกการเตือน อย่างไรก็ตามคุณมีจุดที่ถูกต้องเกี่ยวกับการปรับปรุงความปลอดภัยด้วย SPA
อดีต Umbris

8

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

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

ฉันเชื่อว่าเป็นไปได้ที่จะใช้รหัสผ่านเพื่อป้องกันคีย์ SSH


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


1

รหัสผ่านสามารถถูกบุกรุกโดยคีย์บอร์ดของคุณที่ถูกตรวจสอบ "over-your-shoulder" นอกจากนี้การใช้รหัสผ่านที่คล้ายกันในหลายสถานที่นั้นเป็นจุดอ่อนโดยเฉพาะอย่างยิ่งถ้าบางครั้งรหัสผ่านนั้นถูกใช้ในคอมพิวเตอร์ที่มีความปลอดภัยน้อยกว่าด้วยโปรแกรมล็อกคีย์ที่มีศักยภาพ

คุณถูกต้องว่ารหัสที่ไม่ได้เข้ารหัสสามารถอ่านออกจากฮาร์ดดิสก์ได้หากคอมพิวเตอร์ถูกขโมยดังนั้นให้เข้ารหัสด้วยรหัสผ่าน

หากคอมพิวเตอร์ของคุณถูกมัลแวร์ถูกบุกรุกคุณก็จะถูกยัดไส้โดยไม่คำนึงถึง .. - บางคนสามารถรับรหัสที่เข้ารหัสและรหัสผ่านของคุณ


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