ประวัติ SSH จาก telnet และ rlogin สู่ OpenSSH

จุดเริ่มต้นของประวัติ SSH

ประวัติ SSH เริ่มต้นจากรหัสผ่านที่ถูกขโมย ก่อนปี 1995 การเข้าสู่ระบบเครื่อง Unix ระยะไกลต้องใช้ telnet หรือ rlogin และทั้งสองโปรแกรมส่งรหัสผ่านผ่านเครือข่ายเป็นข้อความที่อ่านได้ ผู้ที่สามารถตรวจดูข้อมูลบนเครือข่ายจึงอ่านข้อความนั้นได้ และในช่วงต้นทศวรรษ 1990 ก็มีผู้ดำเนินการเช่นนั้นในวงกว้าง

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

สิ่งที่ telnet และ rlogin ส่งจริง

Telnet กำหนดไว้ใน RFC 854 ซึ่ง Jon Postel และ Joyce Reynolds เผยแพร่ในเดือนพฤษภาคม 1983 เอกสารนี้อธิบายเซสชันเทอร์มินัลที่ส่งผ่าน TCP และไม่มีการเข้ารหัสใด ๆ ข้อมูลทุกไบต์ที่คุณพิมพ์ รวมถึงรหัสผ่าน จะถูกส่งเป็นไบต์แบบ plain text ซึ่งอุปกรณ์ใด ๆ บนเส้นทางเครือข่ายสามารถอ่านได้

rlogin เกิดขึ้นจาก Berkeley Unix และมีการจัดทำเอกสารในภายหลังใน RFC 1282 (BSD Rlogin, B. Kantor, ธันวาคม 1991) โดยเพิ่มสิ่งที่แย่กว่าการส่งรหัสผ่านแบบอ่านได้ นั่นคือการเชื่อถือโดยอ้างอิงโฮสต์ เซิร์ฟเวอร์สามารถกำหนดให้ยอมรับการเข้าสู่ระบบจากโฮสต์ที่ระบุชื่อได้โดยไม่ต้องใช้รหัสผ่านเลย RFC ฉบับนี้มีหัวข้อชื่อ "A Cautionary Tale" ซึ่งระบุว่า "Bypassing password authentication from trusted hosts opens ALL the systems so configured when just one is compromised." นอกจากนี้ยังระบุด้วยว่าความเชื่อนี้อ้างอิงชื่อโฮสต์ ดังนั้นการโจมตี DNS (domain name system) หรือการปลอมแปลง address สามารถทำลายกลไกดังกล่าวได้

การออกแบบทั้งสองแบบเหมาะกับเครือข่ายในยุคนั้น Ethernet ในยุคแรกเป็นสื่อกลางร่วมกัน เครื่องทุกเครื่องใน segment ได้รับ frame ทุกชุด และต้องเพิกเฉยต่อ frame ที่ไม่ได้ส่งมาถึงตนเอง เครื่องที่หยุดเพิกเฉยต่อ frame เหล่านั้น ซึ่งเป็นความหมายของ promiscuous mode จะมองเห็น network traffic ของเครื่องอื่นทั้งหมด เมื่อมหาวิทยาลัยเปิด shell account ให้นักศึกษาหลายพันคน บัญชีที่ถูกเจาะเพียงบัญชีเดียวจึงกลายเป็นเครื่องเก็บรหัสผ่านของทั้งภาควิชาได้

คำแนะนำด้านความปลอดภัยปี 1994 ที่ไม่มีวิธีแก้ไข

เมื่อวันที่ 3 February 1994 CERT เผยแพร่คำแนะนำ CA-94:01 เรื่อง "Ongoing Network Monitoring Attacks" โดยรายงานว่าผู้บุกรุกสามารถดักจับข้อมูลสำหรับเข้าถึงระบบหลายหมื่นระบบทั่วอินเทอร์เน็ตได้ เครื่องมือที่ใช้จะตั้ง network interface เป็น promiscuous mode และบันทึกช่วงเริ่มต้นของทุก session ใหม่ของ telnet, rlogin และ FTP ซึ่งเป็นส่วนที่มี username และ password

CERT แนะนำให้แต่ละไซต์เปลี่ยน password ของ account ทุกบัญชีที่เข้าถึงผ่าน network เมื่อนำคำแนะนำนี้ไปพิจารณาร่วมกับ protocol จะเห็นปัญหาได้ชัดเจนว่า password ใหม่จะถูกส่งผ่านสายเดียวกันในรูปแบบ clear text เมื่อมีการใช้งานครั้งแรก ไม่มีวิธีแก้ไขที่อยู่ภายใน telnet หรือ rlogin เพราะ protocol ทั้งสองไม่มีตำแหน่งสำหรับรองรับวิธีดังกล่าว

เหตุใดการดักจับข้อมูลใน Helsinki จึงนำไปสู่ SSH

ในปี 1995 เครือข่ายของ Helsinki University of Technology ถูกโจมตีด้วยการดักจับรหัสผ่านในรูปแบบที่ CERT เคยอธิบายไว้ Tatu Ylönen ซึ่งเป็นนักวิจัยที่นั่นจึงเขียนซอฟต์แวร์ทดแทนและเผยแพร่เป็น freeware ในเดือนกรกฎาคม 1995 เขาเรียกซอฟต์แวร์นี้ว่า Secure Shell

การออกแบบมีองค์ประกอบสำคัญ 2 ประการ ประการแรก session ถูกเข้ารหัส ผู้ที่ดักฟังบน segment จึงไม่สามารถเรียนรู้ข้อมูลที่เป็นประโยชน์ได้ ประการที่สอง server ยืนยันตัวตนด้วย key ทำให้ client ตรวจสอบได้ว่าติดต่อถึงเครื่องที่ถูกต้องหรือไม่ ซึ่งเป็นช่องโหว่ที่การเชื่อถือ hostname ของ rlogin เปิดทิ้งไว้

ซอฟต์แวร์นี้แพร่หลายด้วยเช่นกัน เพราะคำสั่งตรงกับคำสั่งที่ผู้ใช้พิมพ์อยู่แล้ว ssh ใช้แทน rsh และ rlogin ส่วน scp ใช้แทน rcp การเปลี่ยนมาใช้ซอฟต์แวร์นี้ต้องปรับเปลี่ยนเพียงความเคยชิน ไม่ใช่ workflow ภายในสิ้นปี 1995 ฐานผู้ใช้เพิ่มขึ้นเป็นประมาณ 20,000 users ใน 50 ประเทศ ในเดือนธันวาคมปีนั้น Ylönen ก่อตั้ง SSH Communications Security เพื่อพัฒนาและจำหน่ายซอฟต์แวร์นี้

จากซอฟต์แวร์ที่เผยแพร่โดยเสรีสู่ผลิตภัณฑ์เชิงพาณิชย์

เมื่อ SSH กลายเป็นธุรกิจ เงื่อนไขใบอนุญาตของ source code ก็เปลี่ยนไป รุ่นที่ออกภายหลังมีข้อกำหนดจำกัดสิ่งที่ผู้อื่นสามารถทำกับ code ได้ และรุ่นสุดท้ายที่ทุกคนสามารถนำกลับมาใช้ได้อย่างเสรีคือ ssh 1.2.12 เรื่องนี้ไม่ใช่สิ่งที่ไม่เหมาะสม แต่หมายความเพียงว่า SSH รุ่นที่ผู้ใช้ทั่วโลกสามารถนำไปพัฒนาต่อยอดได้หยุดการพัฒนา ขณะที่การพัฒนายังคงดำเนินต่อไปในพื้นที่ที่ผู้ใช้เหล่านั้นไม่สามารถติดตามได้ ใบอนุญาตเป็นตัวกำหนดว่า code ใดจะคงอยู่ รูปแบบนี้ควรอ่านเพิ่มเติมใน ประวัติที่ใบอนุญาต open source มีต่อโครงสร้างพื้นฐานสมัยใหม่

เหตุใด OpenBSD จึง fork OpenSSH ในปี 1999

ในช่วงต้นปี 1999 Björn Grönvall นำ release ฟรีครั้งสุดท้ายนั้นกลับมาและเริ่มแก้ไข bug ในโค้ดดังกล่าว เวอร์ชันของเขาใช้ชื่อว่า OSSH และรองรับเฉพาะ protocol SSH 1.3

โครงการ OpenBSD นำ OSSH มาพัฒนาและเขียนโค้ดใหม่ โดย ข้อมูลจากโครงการเอง ระบุว่า Theo de Raadt, Niels Provos, Markus Friedl, Bob Beck, Aaron Campbell และ Dug Song เป็นผู้ทำงานด้านการปรับปรุงความสะอาดของโค้ด การ audit และการเพิ่มความสามารถ ผลลัพธ์คือ OpenSSH 1.2.2 ซึ่ง release พร้อมกับ OpenBSD 2.6 เมื่อวันที่ 1 December 1999

เหตุใด fork จากโครงการ operating system ขนาดเล็กโครงการหนึ่งจึงถูกใช้บนเครื่องเกือบทุกเครื่อง คำตอบอยู่ที่สิ่งที่ OpenBSD ต้องการจากมัน OpenBSD release ระบบพื้นฐานที่ผ่านการ audit และออกแบบให้ปลอดภัยใน configuration เริ่มต้น ดังนั้นการ login ระยะไกลแบบเข้ารหัสจึงต้องอยู่ในระบบพื้นฐานนั้น และต้องอยู่ภายใต้ licence ที่ไม่มีข้อจำกัด แนวคิดเรื่องโค้ดที่ผ่านการ audit และอยู่ภายใต้ licence แบบไม่จำกัดสิทธิ์ตรงกับสิ่งที่ vendor ของ operating system รายอื่นต้องการเช่นกัน Damien Miller, Philip Hands และคนอื่น ๆ เริ่มพัฒนา branch แบบ portable แทบจะทันที ซึ่งเป็นที่มาของ p ใน version เช่น 10.5p1 OpenBSD พัฒนาโค้ดเวอร์ชันที่สะอาด ส่วน branch แบบ portable จะเพิ่มโค้ดเชื่อมต่อสำหรับระบบอื่นทั้งหมด วิธีที่ Unix แยกออกเป็นระบบต่าง ๆ ที่เราใช้อยู่ในปัจจุบัน คือเหตุผลที่ต้องมีโค้ดเชื่อมต่อนี้

การรองรับ protocol version ที่ 2 ตามมาในภายหลัง OpenSSH 2.0 release พร้อมกับ OpenBSD 2.7 เมื่อวันที่ 15 June 2000

เหตุใด SSH-2 จึงเป็นโปรโตคอลใหม่ ไม่ใช่เพียงการเพิ่มหมายเลขเวอร์ชัน

SSH-1 ปกป้องความถูกต้องของกระแสข้อมูลที่เข้ารหัสด้วย CRC-32 ซึ่งเป็น checksum ที่ออกแบบมาเพื่อตรวจจับข้อผิดพลาดในการส่งข้อมูล ไม่ใช่เพื่อรับมือกับผู้โจมตี ในปี 1998 Ariel Futoransky และ Emiliano Kargieman จาก CORE SDI แสดงให้เห็นผลกระทบของข้อบกพร่องนี้ เมื่อใช้โหมด cipher แบบ CBC หรือ CFB ร่วมกับการตรวจสอบ CRC-32 ผู้โจมตีที่รู้ plaintext เพียง 16 ไบต์ก็สามารถแทรก ciphertext ที่เลือกเองเข้าไปได้ และ receiver จะยอมรับว่าเป็นข้อมูลจริง ซึ่งทำให้ผู้โจมตีสามารถรันคำสั่งบนเซิร์ฟเวอร์ได้

ข้อบกพร่องนี้อยู่ในโปรโตคอล จึงไม่สามารถแก้ไขได้โดยไม่ทำลาย compatibility ผู้พัฒนาเปลี่ยนมาเพิ่ม detector แทน โดยเป็นโค้ดในไฟล์ชื่อ deattack.c ที่พยายามตรวจจับการโจมตีขณะเกิดขึ้น ในเดือนกุมภาพันธ์ 2001 พบว่า detector เองมี integer overflow ซึ่งมีหมายเลข CVE-2001-0144 ทำให้สามารถรันโค้ดจากระยะไกลกับเซิร์ฟเวอร์และไคลเอนต์ที่ติดตั้ง patch ดังกล่าวได้ การออกแบบที่ไม่สามารถแก้ไขได้จะสะสม patch และ patch เหล่านั้นก็นำบั๊กของตัวเองเข้ามาด้วย

SSH-2 ได้รับการพัฒนาใน IETF working group ชื่อ secsh และเผยแพร่เป็น RFC ในเดือนมกราคม 2006 โดยสถาปัตยกรรมอยู่ใน RFC 4251, transport layer อยู่ใน RFC 4253, user authentication อยู่ใน RFC 4252 และ connection layer อยู่ใน RFC 4254 การแบ่งเป็น layer คือส่วนสำคัญ เพราะทำให้สามารถเปลี่ยนแต่ละ layer แยกจากกันได้ ประวัติส่วนใหญ่หลังจากนั้นคือการเปลี่ยน layer เหล่านี้

มีการเปลี่ยนแปลงที่สำคัญ 2 รายการ Integrity เปลี่ยนจาก CRC-32 เป็น HMAC (hash-based message authentication code) ที่ใช้ shared secret เป็น key ดังนั้นผู้โจมตีที่ไม่สามารถคำนวณ MAC ได้จะปลอมแปลง packet ไม่ได้ ส่วน key agreement เปลี่ยนมาใช้ Diffie-Hellman ใน SSH-1 client เป็นผู้เลือก session key แล้วส่งโดยเข้ารหัสด้วย RSA key ของเซิร์ฟเวอร์ ดังนั้นผู้ใดก็ตามที่ได้ private key เหล่านั้นในภายหลังจะสามารถถอดรหัส session ที่บันทึกไว้ได้ Diffie-Hellman จะสร้าง secret ใหม่สำหรับแต่ละ session และไม่มีการส่ง secret นี้ผ่านเครือข่าย ดังนั้นการบันทึก traffic ในปัจจุบันแล้วขโมย host key ในภายหลังจะไม่เปิดเผยข้อมูลใดๆ คุณสมบัตินี้เรียกว่า forward secrecy

SSH-2 ไม่มี wire compatibility ร่วมกับ SSH-1 นี่คือเหตุผลที่มีการเปลี่ยนหมายเลขโปรโตคอล แทนที่จะเพิ่มเลขทศนิยมของเวอร์ชัน

เหตุใดจึงนำ SSH-1 ออกแทนการแก้ไข

การนำออกใช้ OpenSSH สามรุ่น (https://www.openssh.org/releasenotes.html) รุ่น 7.0 เมื่อ 11 August 2015 ปิดใช้งาน protocol 1 เป็นค่าเริ่มต้นขณะ compile รุ่น 7.4 เมื่อ 19 December 2016 นำการรองรับ protocol นี้ฝั่ง server ออก และรุ่น 7.6 เมื่อ 3 October 2017 นำส่วนฝั่ง client ออกเช่นกัน รวมถึงตัวเลือกการตั้งค่าและเอกสารที่เกี่ยวข้อง

การเก็บ protocol นี้ไว้เป็นตัวเลือกสำหรับอุปกรณ์รุ่นเก่าน่าจะเป็นทางเลือกที่กระทบผู้ใช้น้อยกว่า แต่ตัวตรวจจับ CRC-32 อธิบายได้ว่าเหตุใดจึงปฏิเสธทางเลือกนั้น ช่องโหว่ integer overflow จะเข้าถึงได้ก็ต่อเมื่อมีการ compile code ของ protocol 1 ไว้ และ code ดังกล่าวอยู่ในเส้นทางการทำงานที่ผู้ดูแลระบบส่วนใหญ่เชื่อว่าไม่ได้ใช้งานบนระบบของตน code ที่ยังอยู่ในซอฟต์แวร์สามารถถูกเรียกใช้งานได้ ส่วน code ที่ลบออกแล้วไม่สามารถถูกเรียกใช้งานได้

เหตุใดการเชื่อมต่อ SSH ครั้งแรกจึงแจ้งเตือนเกี่ยวกับ host key

การเข้ารหัสทำให้ network traffic เป็นส่วนตัว แต่ไม่ได้ยืนยันว่าอีกฝั่งคือใคร หากผู้โจมตีแทรกอยู่ในเส้นทางและตอบแทนเซิร์ฟเวอร์ของคุณ คุณจะได้ session ที่เข้ารหัสอย่างสมบูรณ์กับผู้โจมตี ซึ่งเรียกว่า machine-in-the-middle attack SSH ป้องกันกรณีนี้ด้วย host key: เซิร์ฟเวอร์พิสูจน์ว่ามี private half ของ key pair และ client ตรวจสอบ key นั้นกับค่าที่บันทึกไว้ครั้งล่าสุด หากต้องการดูรายละเอียดการทำงานของการเชื่อมต่อ โปรดดู สิ่งที่เกิดขึ้นเมื่อคุณเปิดการเชื่อมต่อ SSH

การเชื่อมต่อครั้งแรกยังไม่มีครั้งก่อนหน้า ดังนั้น client จึงไม่มีค่าให้เปรียบเทียบและต้องถามคุณว่า:

The authenticity of host 'vps.example.com (203.0.113.10)' can't be established.
ED25519 key fingerprint is SHA256:BQ0Qs2jVXhH2lPZ2rM0aQ0mQ8f9pQ0m3nH0oQ1bYqkE.
This key is not known by any other names.
Are you sure you want to continue connecting (yes/no/[fingerprint])?

การตอบ yes จะบันทึก key นั้นไว้ใน ~/.ssh/known_hosts การเชื่อมต่อครั้งต่อมาจะเปรียบเทียบกับค่าที่บันทึกไว้ทุกครั้ง หากค่าไม่ตรงกัน โปรแกรมจะแสดงข้อความเตือนที่รุนแรงที่สุด:

@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@
@    WARNING: REMOTE HOST IDENTIFICATION HAS CHANGED!     @
@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@
IT IS POSSIBLE THAT SOMEONE IS DOING SOMETHING NASTY!

ความหมายที่ตรงไปตรงมาของข้อความแจ้งเตือนครั้งแรกคือ protocol กำลังยอมรับว่ามีช่วงเวลาหนึ่งที่ระบบอ่อนแอที่สุด Trust on first use หมายความว่าการเชื่อมต่อครั้งแรกปลอดภัยได้เท่ากับ network ที่ใช้เชื่อมต่อเท่านั้น คุณสามารถลดช่องว่างนี้ได้ อ่าน fingerprint จาก console ของ provider หรือ build log ของเซิร์ฟเวอร์ก่อนเชื่อมต่อ เผยแพร่ fingerprint ใน DNS เป็นระเบียน SSHFP (RFC 4255) แต่วิธีนี้ควรใช้เมื่อมี DNSSEC เท่านั้น หรือเซ็น host key ด้วย certificate authority (CA) ของคุณเอง เพื่อให้ client เชื่อถือ CA แทนการเชื่อถือ key แต่ละรายการ ในทางปฏิบัติ คนส่วนใหญ่ยอมรับข้อความแจ้งเตือนโดยไม่ตรวจสอบ ซึ่งควรยอมรับตามตรงว่าเป็นเช่นนั้น

กุญแจสาธารณะเข้ามาแทนที่รหัสผ่านได้อย่างไร

การยืนยันตัวตนด้วยกุญแจสาธารณะมีมาตั้งแต่ SSH รุ่นแรก ๆ แต่ยังต้องใช้เวลาหลายปีกว่าจะกลายเป็นแนวทางปกติ กลไกนี้ใช้กุญแจแบบไม่สมมาตร โดย client พิสูจน์ว่ามี private key ด้วยการเซ็น challenge และ private key จะไม่ออกจาก client ต่างจากรหัสผ่าน แม้ SSH จะส่งรหัสผ่านภายใน encrypted channel แต่ server จะได้รับ secret จริง ดังนั้นหาก server ถูกเจาะหรือเป็นอันตราย server นั้นก็จะถือข้อมูลที่นำไปใช้โจมตีคุณกับบริการอื่นได้

เหตุผลที่สองคือเรื่องการคำนวณ server ทุกเครื่องที่เปิด port 22 บน public address จะได้รับความพยายาม login แบบอัตโนมัติตลอดเวลา และรหัสผ่านเป็นสตริงที่คาดเดาได้ ส่วน key ไม่สามารถคาดเดาได้ในทางปฏิบัติ การตั้งค่า PasswordAuthentication no จะยุติการโจมตีประเภทนี้ทั้งหมด จึงปรากฏอยู่ใน checklist สำหรับ hardening ทุกฉบับ ดูวิธีสร้างและหมุนเวียน key ได้ที่ พื้นฐานการจัดการ SSH key และดูการตั้งค่าฝั่ง server ได้ที่ การ hardening SSH บน VPS

รายการอัลกอริทึมของ SSH เปลี่ยนแปลงอยู่เสมอเพราะเหตุใด

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

Ed25519 เปิดตัวใน OpenSSH 6.5 เมื่อ 30 January 2014 พร้อม cipher chacha20-poly1305 และรูปแบบ private key ที่ป้องกันด้วย bcrypt ลายเซ็น Ed25519 สร้าง nonce สำหรับแต่ละลายเซ็นแบบกำหนดแน่นอน ดังนั้น random number generator ที่อ่อนแอในขณะสร้างลายเซ็นจึงไม่สามารถทำให้ private key รั่วไหลได้ เหตุการณ์จริงที่สามารถกู้คืน private key ของ DSA และ ECDSA ได้ก็เกิดจากปัญหานี้โดยตรง

DSA มีทิศทางตรงกันข้าม OpenSSH 7.0 ปิดการใช้งาน ssh-dss host key และ user key ขณะทำงานในปี 2015 เนื่องจากอัลกอริทึมนี้จำกัด private key ไว้ที่ 160-bit และใช้ SHA-1 รุ่น 9.8 เมื่อ 1 July 2024 ปิดการใช้งาน DSA ในขั้นตอน compile รุ่น 10.0 เมื่อ 9 April 2025 ลบ DSA ออก ตามคำของโครงการคือ "completing the deprecation process that began in 2015" ใช้เวลา 10 ปีนับจากการปิดการใช้งานจนถึงการลบออก

RSA ไม่ได้หายไป แต่รูปแบบลายเซ็นแบบเก่าถูกยกเลิก OpenSSH 8.8 เมื่อ 26 September 2021 หยุดยอมรับลายเซ็น RSA ที่สร้างด้วย SHA-1 เป็นค่าเริ่มต้น release notes ระบุเหตุผลไว้อย่างชัดเจนว่า SHA-1 เสียหายในเชิงการเข้ารหัส และสามารถสร้าง chosen-prefix collision ได้ด้วยค่าใช้จ่ายต่ำกว่า USD 50,000 หากคุณเคยพบ sign_and_send_pubkey: no mutual signature supported ขณะเชื่อมต่อไปยังเซิร์ฟเวอร์รุ่นเก่า นั่นคือการเปลี่ยนแปลงนี้ key ของคุณยังใช้งานได้ ปัญหาอยู่ที่อัลกอริทึมลายเซ็นที่ปลายทางร้องขอ

กระบวนการเดียวกันกำลังเกิดขึ้นกับ key exchange โดยครั้งนี้เป็นการเปลี่ยนแปลงที่เกิดขึ้นก่อนภัยคุกคามจะเกิดขึ้นจริง Traffic ที่บันทึกไว้ในวันนี้อาจถูกเก็บและถอดรหัสในอีกหลายปีข้างหน้าโดยผู้ที่ครอบครอง quantum computer ที่มีความสามารถเป็นรายแรก ดังนั้น key agreement จึงต้องเปลี่ยนก่อนที่จะมีเครื่องดังกล่าว OpenSSH 9.0 เมื่อ 8 April 2022 กำหนดให้ hybrid key exchange เป็นค่าเริ่มต้น: sntrup761x25519-sha512@openssh.com จับคู่ post-quantum algorithm กับ X25519 exchange ดังนั้นผลลัพธ์จะไม่อ่อนแอกว่า classical part แม้ algorithm ใหม่จะไม่เป็นไปตามที่คาด OpenSSH 9.9 เมื่อ 19 September 2024 เพิ่ม mlkem768x25519-sha256 ซึ่งสร้างบน ML-KEM (module lattice key encapsulation mechanism) ที่ NIST กำหนดมาตรฐานในปี 2024 OpenSSH 10.0 กำหนดให้เป็นค่าเริ่มต้นสำหรับ key agreement และ หน้า post-quantum ของโครงการ อธิบายเหตุผลไว้ OpenSSH 10.1 เมื่อ 6 October 2025 เริ่มแสดงคำเตือนเมื่อปลายทางไม่รองรับ:

** WARNING: connection is not using a post-quantum key exchange algorithm.
** This session may be vulnerable to "store now, decrypt later" attacks.
** The server may need to be upgraded.

คำเตือนนี้เปิดใช้งานเป็นค่าเริ่มต้นและควบคุมด้วย option WarnWeakCrypto ใน ssh_config ความหมายในทางปฏิบัติและแนวทางจัดการเซิร์ฟเวอร์ที่ทำให้เกิดคำเตือนนี้อธิบายไว้ใน ค่าเริ่มต้นของ post-quantum SSH key exchange

ประวัตินี้มีความหมายอย่างไรต่อเซิร์ฟเวอร์ที่อยู่ตรงหน้าคุณ

คำสั่งที่คุณพิมพ์แทบไม่เปลี่ยนแปลงเลยนับตั้งแต่ 1995 แต่ส่วนประกอบเกือบทั้งหมดที่อยู่เบื้องหลังถูกเปลี่ยนใหม่แล้ว ทั้งการตรวจสอบความถูกต้องของข้อมูล การแลกเปลี่ยน cryptographic key อัลกอริทึมลายเซ็น และ code base เอง การเปลี่ยนแปลงเหล่านี้เกิดขึ้นได้เพราะแต่ละการแทนที่จบลงด้วยการลบของเดิมอย่างตั้งใจ และการลบแต่ละครั้งทำให้บางระบบใช้งานบางอย่างไม่ได้

ดังนั้นความปลอดภัยของ SSH จึงขึ้นอยู่กับ version ของคุณเป็นหลัก ค่าเริ่มต้นจะกำหนดว่าอัลกอริทึมใดถูกเสนอ อัลกอริทึมใดถูกปฏิเสธ และคุณจะเห็นคำเตือนใด เซิร์ฟเวอร์รุ่นเก่ายังคงเสนอสิ่งที่ release นั้นยังอนุญาต และจะยังลดระดับการเจรจาเพื่อให้ใช้งานร่วมกับ client รุ่นเก่าได้ ณ August 2026 release ปัจจุบันคือ OpenSSH 10.5 ซึ่งเผยแพร่เมื่อ 11 August 2026 ระยะห่างระหว่าง version นี้กับ version บนเครื่องที่ไม่มีใครดูแลมา 3 ปี คือขนาดของปัญหา การตรวจสอบเรื่องนี้ควรอยู่ใน 10 นาทีแรกบน VPS ใหม่

FAQ

ใครเป็นผู้สร้าง SSH และสร้างขึ้นเพื่ออะไร

Tatu Ylönen นักวิจัยจาก Helsinki University of Technology เขียน SSH ในปี 1995 หลังเกิดการดักจับรหัสผ่านบนเครือข่ายของมหาวิทยาลัย เครื่องมือ remote login ในเวลานั้น ได้แก่ telnet และ rlogin ส่งรหัสผ่านผ่านเครือข่ายเป็นข้อความที่อ่านได้ ผู้ที่ monitor shared segment จึงเก็บ credential ได้ระหว่างที่ข้อมูลถูกส่งผ่าน เขาเผยแพร่โปรแกรมเป็น freeware ในเดือนกรกฎาคม 1995 ภายในสิ้นปีนั้น โปรแกรมมีผู้ใช้ประมาณ 20,000 รายใน 50 ประเทศ และในเดือนธันวาคม 1995 เขาก่อตั้ง SSH Communications Security

SSH-1 และ SSH-2 แตกต่างกันอย่างไร

ทั้งสองเป็น protocol คนละแบบและไม่สามารถใช้งานร่วมกันในระดับ wire protocol ได้ SSH-1 เป็น protocol แบบ monolithic เดียวที่ใช้ CRC-32 เพื่อตรวจสอบความถูกต้องของข้อมูล และให้ client ส่ง session key ที่เข้ารหัสด้วย RSA key ของ server SSH-2 แบ่งการทำงานเป็น transport layer, authentication layer และ connection layer (RFCs 4251 ถึง 4254, มกราคม 2006) ใช้ HMAC เพื่อตรวจสอบความถูกต้องของข้อมูล และสร้าง session key ด้วย Diffie-Hellman ดังนั้น traffic ที่ถูกบันทึกไว้ยังคงเป็นความลับ แม้ host key จะถูกขโมยในภายหลัง SSH-1 ถูกนำออกจาก OpenSSH เป็นลำดับ จนสิ้นสุดที่ version 7.6 ในเดือนตุลาคม 2017

เหตุใด OpenSSH จึงมาแทนที่ SSH implementation เดิม

การพัฒนา implementation เดิมเปลี่ยนไปเป็น commercial product ที่มี licence แบบจำกัด และ release ล่าสุดที่นำกลับมาใช้ได้อย่างเสรีคือ ssh 1.2.12 ในช่วงต้นปี 1999 Björn Grönvall นำ release ดังกล่าวกลับมาพัฒนาเป็น OSSH และทีม OpenBSD fork OSSH เป็น OpenSSH ซึ่ง ship มากับ OpenBSD 2.6 เมื่อวันที่ 1 ธันวาคม 1999 OpenBSD ต้องการ code ที่ผ่านการตรวจสอบภายใต้ licence แบบไม่จำกัดสำหรับ base system และคุณสมบัติทั้งสองนี้ทำให้ operating system อื่นสามารถ ship implementation เดียวกันผ่าน portable branch ได้

เหตุใด SSH จึงถามเกี่ยวกับ host key เมื่อเชื่อมต่อครั้งแรก

เพราะ client ยังไม่เคยพบ server นี้มาก่อน และไม่มีข้อมูลสำหรับเปรียบเทียบ key ของ server การเข้ารหัสเพียงอย่างเดียวไม่สามารถแยก server ที่ถูกต้องออกจากเครื่องที่แทรกอยู่กลางเส้นทางได้ ดังนั้น SSH จึงระบุ server ด้วย key และบันทึกสิ่งที่พบไว้ใน ~/.ssh/known_hosts การเชื่อมต่อครั้งแรกเป็นช่วงเดียวที่ยังไม่มีค่าที่บันทึกไว้ให้ตรวจสอบ จึงเป็นเหตุผลที่ client ถามคุณ ให้เปรียบเทียบ fingerprint กับค่าที่ได้รับจาก provider console หรือจาก server โดยตรง และให้ถือว่า message REMOTE HOST IDENTIFICATION HAS CHANGED ที่ปรากฏในภายหลังเป็นเหตุการณ์จริง จนกว่าจะอธิบายสาเหตุได้

เหตุใด SSH key รุ่นเก่าจึงหยุดทำงานหลัง upgrade

เพราะ OpenSSH ยกเลิก algorithm ตามกำหนดการที่ประกาศไว้ล่วงหน้า DSA (ssh-dss) key ถูกปิดใช้งานโดยค่าเริ่มต้นใน OpenSSH 7.0 เมื่อปี 2015 และถูกนำออกทั้งหมดใน OpenSSH 10.0 เมื่อวันที่ 9 เมษายน 2025 RSA key ยังใช้งานได้ แต่ signature ที่สร้างด้วย SHA-1 ถูกปิดใช้งานโดยค่าเริ่มต้นใน OpenSSH 8.8 เมื่อเดือนกันยายน 2021 ซึ่งจะแสดงเป็น sign_and_send_pubkey: no mutual signature supported เมื่อคุณเชื่อมต่อไปยัง server รุ่นเก่า Ed25519 key ซึ่งรองรับมาตั้งแต่ OpenSSH 6.5 ในเดือนมกราคม 2014 ช่วยหลีกเลี่ยงปัญหาทั้งสองนี้ได้