รหัสผ่าน SSH ของคุณถูกเปิดเผยเมื่อคุณพยายามเชื่อมต่อกับเซิร์ฟเวอร์ผิดหรือเปล่า?

192

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

ssh password

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

11

การตรวจสอบรหัสผ่าน SSH ให้รหัสผ่านเซิร์ฟเวอร์หรือไม่

— jamesdlin

41

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

— kubanczyk

6

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

— ฮอบส์

6

@kancanczyk ถ้าคุณต้องการ SSH ไปยัง "internal-www.my-company.com" แต่พิมพ์โดยบังเอิญใน "ssh www.my-company.com" พรอมต์นั้นจะไม่ปกป้องคุณ - เป็นไปได้ว่าเซิร์ฟเวอร์ทั้งสอง ในรายการที่เชื่อถือได้ของคุณเป็นเพียงหนึ่งในนั้นที่ดำเนินการโดยคุณและอีกรายการหนึ่งโดยบุคคลที่สาม

— ทำเครื่องหมาย

@ ฮอบส์ChallengeResponseAuthentication noเหมือนกันฉันคิดว่า

— ilkkachu

215

ใส่ง่าย: ใช่

รายละเอียดเพิ่มเติม...

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

เพิ่มเติมฉันไม่จำเป็นต้องแก้ไขsshdแต่สามารถเขียนโมดูล PAM (เช่นใช้pam_script) ซึ่งจะถูกส่งผ่านรหัสผ่านของคุณ

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

(อันที่จริงนี่ไม่ใช่เรื่องแปลกในโลกของ infosec ตั้งค่าเซิร์ฟเวอร์ honeypot เพื่อบันทึกรหัสผ่านที่พยายาม)

— สตีเฟ่นแฮร์ริส
แหล่งที่มา

13

แก้ไข. มาตรฐานsshdจะไม่บันทึกรหัสผ่าน (หากคุณป้อนรหัสผ่านเป็นชื่อเข้าสู่ระบบจะถูกบันทึกไว้ แต่นั่นเป็นปัญหาอื่น) มาตรฐานsshdเป็นเครื่องมือรักษาความปลอดภัยและอื่น ๆ จะไม่ได้เข้าสู่ระบบข้อมูลประจำตัวเช่น :-) นี้

— สตีเฟ่นแฮร์ริส

116

อีกเหตุผลหนึ่งในการใช้คู่คีย์สาธารณะ / ส่วนตัว ...

— gerrit

3

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

— vfclists

10

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

— hometoast

44

คำแนะนำที่ดีกว่า: อย่าใช้รหัสผ่านรับรองความถูกต้องสำหรับ ssh โปรโตคอลมี pubkey auth ด้วยเหตุผลที่ดีมาก ใช้มัน!

— ..

52

ใช่.

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

หากคุณใส่ใจสิ่งนั้นทางออกที่ดีที่สุดและง่ายที่สุดคือการใช้กุญแจ SSH

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

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

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

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

1

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

— kasperd

8

โดยทั่วไปรหัสผ่านจะถูกส่งใน "ข้อความธรรมดา" (เช่นไม่ใช่ในที่ชัดเจน แต่มีเพียงการป้องกันที่ SSH | TLS | การเชื่อมต่อใดก็ตามที่มีให้) หากระบบเรียกให้ใช้รหัสผ่านเพื่อแฮชฝั่งไคลเอ็นต์และแฮชที่จะส่งเซิร์ฟเวอร์จะไม่มีวิธีรับรหัสผ่านจริงและจะให้สิทธิ์การเข้าถึงแก่ทุกคนที่สามารถให้รหัสแฮชแทนรหัสผ่านได้ .

— แบล็กไลท์ส่องแสง

1

@BlacklightShining มีการพิสูจน์รหัสผ่านศูนย์ความรู้อยู่แล้ว แต่ไม่ได้ใช้ใน SSH เนื่องจากไม่มีวิธีใช้ฐานข้อมูลรหัสผ่านมาตรฐานสำหรับพวกเขาและไม่มีจุดที่แท้จริงในการใช้พวกเขาแทนที่จะใช้การพิสูจน์ตัวตนด้วยคีย์

— Random832

ฉันจะดูรหัสผ่านเหล่านั้นที่ใช้ในการตรวจสอบความถูกต้องได้ที่ไหน พวกเขาไม่ได้อยู่ใน /var/log/auth.log อยู่ที่ไหน

— アレックス

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

— musicinmybrain

10

เพื่อสร้างคำตอบของ Stephen Harris ต่อไปนี้เป็นมุมมองแบบเรียลไทม์ที่ฉันสร้างขึ้นซึ่งแสดงให้เห็นว่าสคริปต์ PAM auth ที่แก้ไขจะสามารถบันทึกได้เมื่อเชื่อมต่อกับกล่องผ่าน ssh (honeypot แปลก ๆ ) ฉันใช้ไลบรารี่ PAM เวอร์ชันที่แก้ไขแล้ว

https://livesshattack.net

https://livesshattack.net/about

— Willie S.
แหล่งที่มา

4

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

— Centimane

มันไม่ทำงานอีกต่อไปฉันส่งสตริงขนาดใหญ่เป็นรหัสผ่านฉันคิดว่ามันอาจจะหักได้ขอโทษ: - /

— scottydelta

@scottydelta แม้ว่าฉันจะไม่ได้ดูมันอาจจะมีข้อ จำกัด ของบัฟเฟอร์ในขนาดรหัสผ่านทั้งโมดูล PAM หรือ SSH daemon เองสามารถยอมรับในความพยายามในการตรวจสอบ ไซต์ยังคงทำงานตามที่ฉันตั้งใจไว้แม้ว่าจะจัดการได้ถึงขีด จำกัด บัฟเฟอร์ที่ยอมรับโดย sshd หรือโมดูล PAM หากเป็นกรณีนี้

— Willie S.

แหล่งที่มาที่น่าสนใจสำหรับ lib-storepw ที่คุณแก้ไขแล้วมีไว้ให้ผู้อื่นใช้หรือไม่?

— ทิมเฟลตเชอร์

2

SSH เป็นโปรโตคอลที่ต้องการความเชื่อถือซึ่งกันและกัน นั่นคือเหตุผลที่ไคลเอนต์ OpenSSH ดูแลรักษาไฟล์ known_hosts เพื่อใช้ความน่าเชื่อถือของมันในรูปแบบการใช้งานครั้งแรก

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

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

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

— markhahn