ทำไมการตรวจสอบรหัสผ่าน SSH จึงมีความเสี่ยงด้านความปลอดภัย?

68

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

— Septagram
แหล่งที่มา

2

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

— Alex Holst

25

มีโปรและคอนสำหรับการรับรองความถูกต้องทั้ง pw หรือคีย์

ในบางกรณีตัวอย่างเช่นการตรวจสอบความถูกต้องด้วยคีย์จะปลอดภัยน้อยกว่าการตรวจสอบรหัสผ่าน ในอีกกรณีหนึ่ง pw-based ที่มีความปลอดภัยน้อยกว่า ในบางกรณีหนึ่งจะสะดวกกว่าในบางกรณีน้อยกว่า

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

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

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

— โรมัน
แหล่งที่มา

การเปลี่ยนพอร์ต SSH จาก 22 อาจไม่ใช่ความคิดที่ดีเลยในหลายกรณี adayinthelifeof.nl/2012/03/12/…

— Tymek

75

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

ตัวอย่างเช่น,

command="/usr/local/bin/your_backup_script.sh", ssh-rsa auiosfSAFfAFDFJL1234214DFAfDFa...

จะอนุญาตเฉพาะคำสั่ง `/usr/local/bin/your_backup_script.sh" ด้วยคีย์เฉพาะนั้น

คุณยังสามารถระบุโฮสต์ที่อนุญาตสำหรับคีย์ได้:

from="yourclient,yourotherclient", ssh-rsa auiosfSAFfAFDFJL1234214DFAfDFa...

หรือรวมสอง:

from="yourbackupserver", command="/usr/local/bin/your_backup_script.sh", ssh-rsa auiosfSAFfAFDFJL1234214DFAfDFa...

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

— Janne Pikkarainen
แหล่งที่มา

เคล็ดลับที่มีประโยชน์มากมาก

— Sachin Divekar

3

นอกจากนั้นการใช้ Keys นั้นเหมือนกับการใช้รหัสผ่านยาว 2,000 ตัวอักษร (ในทางเทคนิคแล้วมันมีความแข็งแรงมากกว่า) เมื่อเทียบกับสิ่งที่คุณสามารถป้อนด้วยตนเองในเทอร์มินัล: D

— Abhishek Dujari

3

สองเคล็ดลับที่เป็นประโยชน์อย่างมากเกี่ยวกับการตรวจสอบ SSH แต่จริงๆไม่ได้ตอบคำถามสำหรับฉัน ...

— MikeMurko

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

— b0fh

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

— Riking

48

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

PasswordAuthentication no
Match Address 10.0.0.0/8,172.16.0.0/12,192.168.0.0/16
    PasswordAuthentication yes

— MikeyB
แหล่งที่มา

7

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

เปรียบเทียบความยาวของรหัสผ่านของคุณด้วยขนาดของคีย์ (โดยทั่วไปคือหลายพันบิต)

— มาร์ตินเวจเมลกา
แหล่งที่มา

4

เอนโทรปี 96 บิตหมายถึงรหัสผ่าน 80 ตัวอักษรหากเขียนเป็นภาษาอังกฤษ 15 ตัวอักษรถ้ามันพูดไม่ชัดแบบสุ่มจากชุดตัวอักษรที่พิมพ์ได้ คุณแน่ใจหรือไม่ว่ารหัสผ่าน ssh ของคุณนั้นยาว / แข็งแรง?

— MadHatter

3

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

— Nick Downton

5

@SachinDivekar นั่นคือ 96 บิตของเอนโทรปีเฉพาะเมื่อใช้รหัสผ่านแบบสุ่มจากชุด [a-zA-Z] ไม่ใช่ถ้าเป็นคำภาษาอังกฤษ

— Jaap Eldering

16

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

— Mark Henderson

7

ขออภัยทำเครื่องหมายว่าผิด วลีรหัสผ่านที่คุณให้มี 37 ตัวอักษรดังนั้นเอนโทรปีของบิตประมาณ 44 บิตซึ่งน้อยกว่าตัวอักษรที่พิมพ์ได้ 7 ตัวและสามารถโจมตีได้อย่างเด่นชัด อ่านบทความของ Wikipedia เกี่ยวกับงานของ Claude Shannon เพื่อดูรายละเอียด แต่ผลที่สุดคือการเขียนภาษาอังกฤษสามารถคาดเดาได้สูงเช่นหลังจาก "mywifesname" คำว่า "คือ" เกือบจะรับประกัน สำหรับรหัสผ่านที่รัดกุมซึ่งเกี่ยวข้องกับคำคำสุ่มสี่คำที่พันกันจากพจนานุกรมจะทำให้คุณมีความเป็นไปได้ 10 ** 23 ซึ่งมีความเกี่ยวกับ 77 บิตของเอนโทรปี ยังไม่ดี แต่ก็ไม่เลว

— MadHatter

7

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

— รามอน
แหล่งที่มา

2

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

— b0fh

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

— เตาแก๊ส

6

ปุ่ม ssh ป้องกันคนในการโจมตีตามรหัสผ่านกลางของคุณ

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

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

ด้วยรหัสผ่านพวกเขาจะมีข้อมูลประจำตัวของคุณ

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

แม้ว่าการติดตั้งซอฟต์แวร์เมาท์จะเป็นความเจ็บปวด (truecrypt)

— Tacticus
แหล่งที่มา

1

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

— โทมัส

3

โทมัสในความเป็นจริงหลายคนไม่สนใจคำเตือนเกี่ยวกับการเปลี่ยนลายนิ้วมือ Pubkey auth รับประกันการป้องกัน MITM แม้ว่าคีย์ส่วนตัวของเซิร์ฟเวอร์จะถูกบุกรุกหรือมนุษย์ประเภท "ใช่" หายไป: ผู้โจมตีต้องเลือกระหว่างที่ไม่สามารถมองเห็นทราฟฟิกและการส่งคีย์สาธารณะที่จะไม่เข้าสู่ระบบซึ่งเป็น ชนะ.

— คะแนน _ ต่ำกว่า

5

และสำหรับผู้ตอบคำถาม: คุณไม่จำเป็นต้องใช้ truecrypt คีย์ส่วนตัวของ openssh จะมาพร้อมกับการเข้ารหัสโดยใช้รหัสผ่านเป็นของตัวเอง

— คะแนน _ ต่ำกว่า

5

มันเป็นการแลกเปลี่ยนที่ @MartinVejmelka พูดว่า

เหตุผลที่คุณใช้การรับรองความถูกต้องของคีย์คือกุญแจนั้นอยู่เหนือกว่าปัจจุบันหรืออนาคตอันใกล้ที่จะบังคับให้คุณต้องมาจากพีซีของคุณเองหรือมีกุญแจอยู่บนแท่ง USB หรือที่คล้ายกัน

รหัสผ่านมีปัญหาดังต่อไปนี้:

ถ้ามันสั้นมันก็สามารถบังคับสัตว์เดรัจฉานได้
ถ้ามันยาวมันก็จะลืมง่าย
มันอาจจะท่องไหล่

คีย์คือออเดอร์ที่มีขนาดยาวกว่าและจะไม่ปรากฏ ณ จุดใด ๆ ดังนั้นมันจึงหลีกเลี่ยงปัญหาทั้งสามนี้

— Rory Alsop
แหล่งที่มา

แต่การใช้ไฟล์คีย์เพิ่มปัญหาการสูญเสียไดรฟ์ปากกาหรือที่เก็บข้อมูลใด ๆ ที่คุณใช้

— João Portela

1

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

— SplinterReality

หนึ่ง (ที่เพิ่งเกษียณอายุ) 08Forging2?seminal*^Rajas-(Posed/|รหัสผ่านของฉัน: มันสร้างแบบสุ่ม แต่ฉันไม่มีปัญหาในการจดจำ และขอให้โชคดีเล่นกระดานโต้คลื่นหรือเดียรัจฉานบังคับ

— finnw

1

@finnw แก้ไข Horse Staple Battery :-) security.stackexchange.com/q/6095/485

— Rory Alsop

2

จุดที่ดีกล่าวถึงที่นี่แล้ว

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

ฉันเพิ่งได้รับการเตือนจาก Norton เกี่ยวกับการดาวน์โหลดตัวติดตั้ง Zombee Mod (ไม่ใช่ jar, ตัวติดตั้ง) สำหรับเพิ่มการบินไปยัง jar ของ Minecraft ฉันดูรายละเอียดและนอร์ตันมีรายการสาธารณูปโภคมากมายในไซต์นี้ซึ่งถูกทำเครื่องหมายว่ามีโทรจันอยู่ ฉันไม่รู้ว่ามันถูกต้องหรือไม่ แต่มันค่อนข้างเฉพาะเจาะจงกับชื่อไฟล์ มันเป็นความจริงที่ทราบกันดีว่าโทรจันถูกใส่ลงใน (บางส่วน) warez ก่อนที่จะเผยแพร่

— Tedd Hansen
แหล่งที่มา

2

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

ฉันค้นหาคำตอบที่ดีที่สุดสำหรับเหตุผลที่คู่มือผู้ใช้มักแนะนำ SSH ผ่านการตรวจสอบรหัสผ่านมาจากคู่มือ Ubuntu สำหรับ SSHOpenSSHKeys ฉันพูด

หากคุณคิดว่าไม่สำคัญลองบันทึกการเข้าสู่ระบบที่เป็นอันตรายทั้งหมดที่คุณพยายามรับในสัปดาห์หน้า คอมพิวเตอร์ของฉัน - เป็นพีซีเดสก์ท็อปธรรมดาที่สมบูรณ์แบบ - มีความพยายามมากกว่า 4,000 ครั้งในการเดารหัสผ่านของฉันและเกือบ 2,500 ครั้งในช่วงสัปดาห์ที่แล้ว คุณคิดว่าจะมีการสุ่มสุ่มกี่พันครั้งก่อนที่ผู้โจมตีจะสะดุดรหัสผ่านของคุณ?

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

— MikeMurko
แหล่งที่มา

1

Passwd auth method ไม่ปลอดภัยจริงๆ (imho) ด้วยกลไกนี้รหัสผ่านจะถูกส่งไปยังเซิร์ฟเวอร์ sshd (เช่น @ramon ได้กล่าวไปแล้ว) ซึ่งหมายความว่าบุคคลบางคนสามารถแก้ไขเซิร์ฟเวอร์ sshd เพื่อดึงรหัสผ่าน ด้วยการโจมตี Man-In-The-Middle นี่เป็นเรื่องง่ายมากที่จะประสบความสำเร็จในเครือข่ายท้องถิ่น

คุณสามารถแก้ไขเซิร์ฟเวอร์ sshd ได้โดยติดตั้งโปรแกรมแก้ไขนี้ ( https://github.com/jtesta/ssh-mitm ) ใช้arpspoofและiptablesวางเซิร์ฟเวอร์ที่แพตช์ระหว่างไคลเอนต์และเซิร์ฟเวอร์ sshd แท้

โปรดปิดใช้งานการตรวจสอบสิทธิ์รหัสผ่าน: เปิดไฟล์ config และเพิ่มบรรทัด/etc/ssh/ssh_configPasswordAuthentication no

— Pioz
แหล่งที่มา

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

— Septagram

1

ใช่. คำเตือนจะปรากฏขึ้น แต่เนื่องจาก 99% ของเวลานี้เกิดจากการติดตั้งระบบปฏิบัติการใหม่, เปลี่ยนการกำหนดค่า ecc ผู้ใช้ส่วนใหญ่จะไม่สนใจคำเตือนและดำเนินการต่อ

— Pioz

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

— เดเมียน Yerrick

-2

คุณสามารถข้ามด้วย-o StrictHostKeyChecking=noตัวเลือก สิ่งนี้มีประโยชน์มากเมื่อใช้ ssh ในเชลล์สคริปต์

ssh -o StrictHostKeyChecking=no -o ConnectTimeout=10 -o PasswordAuthentication=no -o ConnectionAttempts=5 xxUser@xxxHost

— arganzheng
แหล่งที่มา