วิธีตรวจสอบ Post-Quantum SSH บน Ubuntu และการทำงาน

สิ่งที่เปลี่ยนไปใน post-quantum SSH

post-quantum SSH ถูกเปิดใช้งานสำหรับผู้ใช้ส่วนใหญ่แล้วโดยที่ไม่มีใครต้องตั้งค่าใดๆ ไคลเอนต์ OpenSSH รุ่นปัจจุบันที่เชื่อมต่อกับเซิร์ฟเวอร์ OpenSSH รุ่นปัจจุบันจะเลือกใช้ hybrid post-quantum key exchange เป็นค่าเริ่มต้น เพื่อให้ session key สามารถต้านทานผู้โจมตีที่บันทึก traffic ของคุณในวันนี้และพยายามถอดรหัสในอีกหลายปีข้างหน้าได้ การป้องกันนี้เป็นเรื่องจริง แต่มีขอบเขตที่แคบกว่าที่วลี "quantum-safe SSH" สื่อถึง

ขออธิบายสองคำศัพท์ก่อน SSH (secure shell) คือโปรโตคอลที่คุณใช้ล็อกอินเข้าสู่เซิร์ฟเวอร์ ส่วน key exchange ซึ่งมักเขียนย่อว่า "kex" คือขั้นตอนแรกของการเชื่อมต่อ SSH ทุกครั้ง โดยทั้งสองฝั่งจะตกลงใช้ความลับร่วมกัน และความลับนั้นจะถูกนำไปใช้เข้ารหัสข้อมูลทั้งหมดหลังจากนั้น ส่วนที่เปลี่ยนแปลงคือ key exchange เท่านั้น ไม่มีส่วนอื่นที่เปลี่ยนไป

อย่าเชื่อถือหน้านี้ ให้รันคำสั่งด้วยตนเอง

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

เริ่มต้นด้วยสิ่งที่ build ของคุณรองรับ

ssh -V
ssh -Q kex

ssh -V จะแสดงบรรทัดเวอร์ชันที่ขึ้นต้นด้วย OpenSSH_ ตามด้วยส่วนต่อท้ายของแพ็กเกจ Ubuntu และเวอร์ชันของ OpenSSL ส่วน ssh -Q kex จะแสดงอัลกอริทึมการแลกเปลี่ยนคีย์ (key exchange algorithm) ทีละรายการในแต่ละบรรทัด บน build ที่รองรับ post-quantum คุณจะพบชื่ออย่าง mlkem768x25519-sha256 และ sntrup761x25519-sha512@openssh.com อยู่ในรายการนั้น เคียงข้างกับชื่อแบบดั้งเดิมอย่าง curve25519-sha256

สิ่งที่ build ของคุณรองรับ ไม่ใช่สิ่งที่จะนำเสนอจริง

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

ssh -G example.com | grep -i '^kexalgorithms'
sudo sshd -T | grep -i '^kexalgorithms'

ssh -G <host> จะแสดง configuration ที่มีผลจริงของ client สำหรับ host นั้น ๆ หลังจากที่ ~/.ssh/config และ /etc/ssh/ssh_config ถูกนำมาปรับใช้แล้ว ส่วน sshd -T จะแสดงผลในลักษณะเดียวกันสำหรับฝั่ง server แต่ละคำสั่งจะพิมพ์บรรทัด kexalgorithms ออกมาหนึ่งบรรทัดตามลำดับความสำคัญ โดยชื่อแรกในบรรทัดคือตัวเลือกอันดับหนึ่งของฝั่งนั้น ซึ่งบรรทัดดังกล่าวคือสิ่งที่จะถูกส่งผ่านเครือข่ายจริง

ช่องว่างนี้ไม่ใช่แค่ทฤษฎี OpenSSH 8.5 ซึ่งปล่อยออกมาเมื่อ 2021-03-03 ได้เพิ่ม sntrup761x25519-sha512@openssh.com เข้ามา แต่จงใจไม่ใส่ไว้ในรายการเริ่มต้น ในรุ่นดังกล่าว ssh -Q kex จะแสดงอัลกอริทึมนี้ออกมา แต่ ssh -G กลับไม่แสดง ซึ่งหมายความว่า binary นี้สามารถทำ post-quantum key exchange ได้ แต่จะไม่มีการเชื่อมต่อใดร้องขอให้ใช้งานเลย

อ่านอัลกอริทึมที่การเชื่อมต่อของคุณตกลงใช้งาน

ssh -v example.com 2>&1 | grep 'kex: algorithm'

ระหว่างไคลเอนต์ปัจจุบันและเซิร์ฟเวอร์ปัจจุบัน ระบบจะแสดงผลดังนี้:

debug1: kex: algorithm: mlkem768x25519-sha256

mlkem768x25519-sha256 เป็นแบบไฮบริด โดยทำงานร่วมกับ ML-KEM (กลไกการห่อหุ้มคีย์แบบ module-lattice ซึ่งถูกกำหนดมาตรฐานเป็น FIPS 203) ที่ชุดพารามิเตอร์ 768 ควบคู่ไปกับ X25519 elliptic curve Diffie-Hellman และผสมผลลัพธ์จากทั้งสองส่วนเข้าเป็นคีย์เซสชัน

หากเชื่อมต่อกับเซิร์ฟเวอร์รุ่นเก่า คุณอาจเห็นผลลัพธ์นี้แทน:

debug1: kex: algorithm: curve25519-sha256

ชื่อดังกล่าวไม่มีส่วนประกอบที่ทนทานต่อควอนตัม curve25519-sha256 เป็นเพียง elliptic curve Diffie-Hellman เพียงอย่างเดียว ซึ่งคอมพิวเตอร์ควอนตัมขนาดใหญ่สามารถถอดรหัสได้ นี่คือเหตุผลทั้งหมดที่ค่าเริ่มต้นถูกเปลี่ยน

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

ssh -v มีความสำคัญมากกว่าแค่บรรทัดนี้ เพราะผลลัพธ์เดียวกันนี้คือจุดที่คุณสามารถ ติดตามสาเหตุของความล้มเหลว Permission denied (publickey) เมื่อการเข้าสู่ระบบถูกปฏิเสธโดยตรง

หากละเว้น grep แล้วใช้ ssh -v จะแสดงรายละเอียดการเจรจาส่วนที่เหลือ รวมถึงบรรทัดที่ส่วนถัดไปจะกล่าวถึง:

debug1: kex: host key algorithm: ssh-ed25519

OpenSSH รุ่นใดที่กำหนดให้การแลกเปลี่ยนแบบไฮบริดเป็นค่าเริ่มต้น

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

• 8.5 ซึ่งปล่อยออกมาเมื่อ 2021-03-03 ได้เพิ่ม sntrup761x25519-sha512@openssh.com เข้ามาแต่ยังคงปิดใช้งานเป็นค่าเริ่มต้น
• 9.0 ซึ่งปล่อยออกมาเมื่อ 2022-04-08 ได้เปิดใช้งานฟีเจอร์นี้ โดยบันทึกระบุว่า OpenSSH จะ "ใช้การแลกเปลี่ยนกุญแจแบบไฮบริด Streamlined NTRU Prime + x25519 เป็นค่าเริ่มต้น" นี่คือรุ่นที่การแลกเปลี่ยนกุญแจแบบต้านทานควอนตัม (post-quantum) กลายเป็นมาตรฐานทั่วไป
• 9.9 ซึ่งปล่อยออกมาเมื่อ 2024-09-19 ได้เพิ่ม mlkem768x25519-sha256 เป็นทางเลือกที่สอง รุ่นเดียวกันนี้ยังกำหนดชื่อที่ลงทะเบียนกับ IANA ให้กับวิธีเดิมว่า sntrup761x25519-sha512 ดังนั้น build ใหม่ๆ จึงแสดงรายการภายใต้ชื่อเรียกทั้งสองแบบ
• 10.0 ซึ่งปล่อยออกมาเมื่อ 2025-04-09 ได้กำหนดให้ mlkem768x25519-sha256 เป็นค่าเริ่มต้นสำหรับการตกลงกุญแจ (key agreement)
• 10.1 ซึ่งปล่อยออกมาเมื่อ 2025-10-06 ได้เพิ่มการแจ้งเตือนฝั่งไคลเอนต์เมื่อการเชื่อมต่อเจรจาการแลกเปลี่ยนกุญแจโดยไม่มีส่วนประกอบแบบต้านทานควอนตัม ฟีเจอร์นี้ถูกควบคุมโดยตัวเลือก WarnWeakCrypto ใน ssh_config และเปิดใช้งานเป็นค่าเริ่มต้น

เดือนเมษายน 2022 คือวันที่ควรจดจำ เครื่องคอมพิวเตอร์คู่ใดก็ตามที่รัน OpenSSH 9.0 หรือใหม่กว่า ได้ทำการแลกเปลี่ยนกุญแจแบบต้านทานควอนตัมมาตั้งแต่นั้น โดยไม่ต้องตั้งค่าใดๆ และไม่มีการประกาศให้ผู้ที่พิมพ์คำสั่ง ssh ทราบ

Ubuntu รุ่นใดที่มาพร้อมกับซอฟต์แวร์นี้

Ubuntu จะคงเวอร์ชันของ OpenSSH ไว้ตามรุ่นที่ปล่อยออกมา แล้วใช้วิธี backport แพตช์ความปลอดภัยเข้าไปโดยไม่เปลี่ยนเลขเวอร์ชัน ดังนั้นรุ่นของ Ubuntu ที่คุณใช้งานจะเป็นตัวกำหนดอัลกอริทึมเริ่มต้นของคุณ ให้ตรวจสอบเครื่องที่ใช้งานจริงด้วย ssh -V แทนการเชื่อรายการอ้างอิง ณ เดือนสิงหาคม 2026 คลังซอฟต์แวร์มีเวอร์ชันดังนี้:

• 22.04 LTS มาพร้อมกับ 1:8.9p1 ซึ่งเก่ากว่าค่าเริ่มต้นของเวอร์ชัน 9.0 ดังนั้นการติดตั้งแบบมาตรฐานจะเจรจาการเชื่อมต่อด้วย curve25519-sha256
• 24.04 LTS มาพร้อมกับ 1:9.6p1 ซึ่งอยู่ระหว่างเวอร์ชัน 9.0 ถึง 9.9 ค่าเริ่มต้นจึงเป็น sntrup761x25519-sha512@openssh.com และยังไม่มี ML-KEM
• 25.10 มาพร้อมกับ 1:10.0p1 ซึ่งมีค่าเริ่มต้นเป็น mlkem768x25519-sha256
• 26.04 LTS มาพร้อมกับ 1:10.2p1 ซึ่งมีค่าเริ่มต้นเป็น mlkem768x25519-sha256 และจะแจ้งเตือนเมื่อมีการเชื่อมต่อที่ไม่ใช่แบบ post-quantum

ลองทดสอบกับเครื่องสองเครื่องจริง โดยให้แล็ปท็อป 26.04 เชื่อมต่อไปยังเซิร์ฟเวอร์ 24.04 ตัวเลือกแรกของไคลเอนต์คือ mlkem768x25519-sha256 ซึ่งไม่มีอยู่ในรายการของเซิร์ฟเวอร์เวอร์ชัน 9.6 ตัวเลือกแบบ post-quantum ถัดไปของไคลเอนต์ที่เซิร์ฟเวอร์รองรับคือ sntrup761x25519-sha512@openssh.com และนั่นคือชื่อที่ ssh -v รายงานออกมา เซสชันนี้จึงเป็นแบบ post-quantum ในส่วนของการแลกเปลี่ยนกุญแจ (key exchange) กับเซิร์ฟเวอร์ที่สร้างขึ้นในปี 2024 โดยที่ไม่มีใครต้องตั้งค่าใดๆ เพิ่มเติม

กรณีของ 22.04 จะเป็นไปในทางตรงกันข้าม และแสดงให้เห็นว่าเหตุใด ssh -Q kex เพียงอย่างเดียวจึงทำให้เข้าใจผิด OpenSSH 8.9 รู้จักชื่อ sntrup761x25519-sha512@openssh.com ดังนั้น ssh -Q kex บนเครื่องนั้นจึงแสดงรายการดังกล่าวออกมา แต่ค่าเริ่มต้นที่เสนอไปไม่ได้รวมรายการนี้ไว้ การเจรจาจึงไปจบที่ curve25519-sha256 หากเชื่อมต่อจากไคลเอนต์ OpenSSH 10.1 หรือใหม่กว่า การเชื่อมต่อจะแจ้งเตือนดังนี้:

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

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

เหตุผลที่ต้องใช้ระบบไฮบริดและความหมายของแนวคิด harvest now, decrypt later

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

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

ระบบไฮบริดหมายถึงการรันอัลกอริทึมทั้งสองแบบพร้อมกันและนำผลลัพธ์ทั้งสองมาสร้างเป็น session key เพื่อกู้คืนความลับเบื้องหลัง mlkem768x25519-sha256 ผู้โจมตีจะต้องเจาะทั้ง ML-KEM 768 และ X25519 ให้สำเร็จ การจับคู่เช่นนี้เป็นความตั้งใจ เนื่องจาก ML-KEM เป็นอัลกอริทึมที่ใหม่กว่า X25519 มากและผ่านการตรวจสอบจากนักวิเคราะห์รหัสลับมาน้อยกว่า ดังนั้นหากพบช่องโหว่ในอัลกอริทึมใหม่ ก็จะไม่ส่งผลกระทบต่อการป้องกันที่คุณมีอยู่เดิม

สิ่งที่ได้รับการป้องกันและสิ่งที่ไม่ได้รับการป้องกัน

การแลกเปลี่ยนกุญแจ (key exchange) ได้รับการป้องกัน ความลับร่วม (shared secret) ที่ใช้เข้ารหัสเซสชันของคุณได้มาจากการแลกเปลี่ยนแบบไฮบริด ดังนั้นการบันทึกเซสชันในวันนี้จะไม่สามารถถูกถอดรหัสได้เมื่อคอมพิวเตอร์ควอนตัมถูกพัฒนาขึ้นในอนาคต

กุญแจโฮสต์ (host key) ไม่ได้รับการป้องกัน บรรทัด debug1: kex: host key algorithm: ssh-ed25519 ระบุถึงลายเซ็นแบบคลาสสิก เช่นเดียวกับ rsa-sha2-512 และประเภท ECDSA (elliptic curve digital signature algorithm) ผู้โจมตีที่มีคอมพิวเตอร์ควอนตัมที่ใช้งานได้จริงอาจปลอมแปลงลายเซ็นนั้นเพื่อสวมรอยเป็นเซิร์ฟเวอร์ของคุณได้ แต่จะทำได้เฉพาะในระหว่างการเชื่อมต่อแบบสดในอนาคตเท่านั้น และไม่สามารถทำกับทราฟฟิกที่บันทึกไว้ในปัจจุบันได้

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

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

TLS บนเซิร์ฟเวอร์เดียวกันเป็นคนละประเด็นและมีคำตอบที่แยกต่างหาก TLS (transport layer security) คือสิ่งที่เว็บเซิร์ฟเวอร์ของคุณใช้สื่อสารผ่านพอร์ต 443 ซึ่งเป็นฐานโค้ดที่แตกต่างและมีกำหนดการพัฒนาแยกกัน การอัปเกรด OpenSSH ไม่ส่งผลกระทบใดๆ ต่อส่วนนั้น หากคุณกำลังใช้งาน ใบรับรองแบบ self-signed สำหรับบริการส่วนตัวบน VPS เดียวกัน ลายเซ็นและการแลกเปลี่ยนกุญแจของใบรับรองนั้นจะถูกกำหนดโดย OpenSSL และเว็บเซิร์ฟเวอร์ของคุณ ดังนั้นคุณควรศึกษาข้อมูลเกี่ยวกับ stack นั้นแยกต่างหากตามเงื่อนไขของมันเอง

สิ่งที่ผู้ดูแลระบบที่รอบคอบควรทำในตอนนี้

ให้หมั่นอัปเดต OpenSSH ให้เป็นเวอร์ชันล่าสุดอยู่เสมอ และหยุดเพียงแค่นั้น นี่คือกลยุทธ์ทั้งหมดสำหรับปัญหานี้ sudo apt update && sudo apt upgrade จะช่วยให้คุณใช้เวอร์ชันที่มาพร้อมกับ Ubuntu release ของคุณ และการอัปเกรด Ubuntu ไปยังเวอร์ชันใหม่กว่าคือวิธีที่จะทำให้คุณได้ใช้ OpenSSH เวอร์ชันใหม่กว่า การเปิดใช้งาน การอัปเดตความปลอดภัยอัตโนมัติ จะช่วยให้คุณได้รับแพตช์เหล่านั้นโดยไม่ต้องคอยจำ การคอมไพล์ OpenSSH จาก source code เพียงเพื่อไล่ตามชื่ออัลกอริทึมถือเป็นการแลกเปลี่ยนที่ไม่คุ้มค่า เพราะคุณจะสูญเสียการอัปเดตความปลอดภัยจาก distribution สำหรับบริการที่เสี่ยงต่อการถูกโจมตีมากที่สุดบนเครื่อง หากคุณยังคงต้องการดึง source code มาใช้ ให้ตรวจสอบ checksum ของไฟล์ที่ดาวน์โหลดมา ก่อนที่จะเริ่ม build

ห้ามเขียนบรรทัด KexAlgorithms ด้วยตนเอง นี่คือการกระทำเพียงอย่างเดียวที่มักจะทำให้สถานการณ์แย่ลง คู่มือการปรับแต่งความปลอดภัย (hardening) จากปี 2018 จะให้รายการที่ถูกต้องสำหรับปี 2018 มากับคุณ และการคัดลอกรายการนั้นไปวางใน sshd_config จะเป็นการแทนที่รายการเริ่มต้นแทนที่จะเป็นการเพิ่มเข้าไป อัลกอริทึมทุกตัวที่ถูกคิดค้นขึ้นหลังจากนั้นจะถูกตัดออกไป ส่งผลให้เซิร์ฟเวอร์ที่ควรจะเจรจาต่อรองด้วย mlkem768x25519-sha256 ได้ด้วยตัวเอง กลับต้องลดระดับลงไปใช้สิ่งที่เหลืออยู่ในรายการที่ถูกกำหนดไว้ตายตัว ให้รันคำสั่ง sudo sshd -T | grep -i '^kexalgorithms' บนเซิร์ฟเวอร์ทุกเครื่องที่คุณได้รับช่วงดูแลต่อ หากบรรทัดนั้นสั้นกว่าบรรทัดที่อยู่ในเครื่องที่เพิ่งติดตั้งใหม่ใน release เดียวกัน แสดงว่ามีคนไปกำหนดค่าตายตัวไว้

หากคุณมีเหตุผลที่จำเป็นต้องเปลี่ยนรายการอัลกอริทึม ให้ใช้วิธีเพิ่มเข้าไปแทนการแทนที่ OpenSSH จะอ่านเครื่องหมาย + นำหน้าเป็นการเพิ่มต่อท้าย, - นำหน้าเป็นการลบออก และ ^ นำหน้าเป็นการย้ายไปไว้ข้างหน้าสุด

KexAlgorithms ^mlkem768x25519-sha256

ทดสอบไฟล์ก่อนที่คุณจะใช้งานจริง sudo sshd -t จะตรวจสอบไวยากรณ์ของไฟล์คอนฟิกและจะไม่แสดงผลใดๆ หากไฟล์นั้นถูกต้อง บรรทัด KexAlgorithms ที่ระบุชื่ออัลกอริทึมที่ build นั้นไม่มีอยู่จะทำให้ sshd ไม่สามารถเริ่มทำงานได้ และหากเป็นเซิร์ฟเวอร์ระยะไกล นั่นหมายความว่าคุณจะไม่สามารถเข้าใช้งานได้อีก ดังนั้นควรเปิด session สำรองไว้อีกหนึ่งช่องทางในขณะที่คุณทำงาน เมื่อรายการของทั้งสองฝั่งไม่ตรงกัน ไคลเอนต์จะแจ้งเตือนอย่างชัดเจน:

Unable to negotiate with 203.0.113.10 port 22: no matching key exchange method found. Their offer: curve25519-sha256,ecdh-sha2-nistp256

ให้มองคำโฆษณาว่า "quantum-safe" ว่าเป็นเพียงการกล่าวอ้างถึงชั้นใดชั้นหนึ่งเท่านั้น ผู้จำหน่ายที่เรียกผลิตภัณฑ์ของตนว่า quantum-safe กำลังอธิบายถึงชั้นที่พวกเขาอ้างถึง ซึ่งโดยปกติแล้วจะเป็นการแลกเปลี่ยนกุญแจ (key exchange) ในจุดใดจุดหนึ่ง ให้สอบถามชื่ออัลกอริทึมและโปรโตคอลที่เกี่ยวข้อง สำหรับ OpenSSH ในเดือนสิงหาคม 2026 คำกล่าวอ้างที่ตรงไปตรงมาคือการแลกเปลี่ยนกุญแจเป็นแบบ hybrid post-quantum ในขณะที่ลายเซ็นดิจิทัล (signatures) ยังคงเป็นแบบดั้งเดิม สิ่งใดที่กว้างกว่านั้นควรมาพร้อมกับชื่อที่คุณสามารถค้นหาได้ในผลลัพธ์ของ ssh -Q kex

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

FAQ

การเชื่อมต่อ SSH ของฉันเป็นแบบ post-quantum แล้วหรือยัง?

ให้รันคำสั่ง ssh -v yourserver 2>&1 | grep 'kex: algorithm' แล้วอ่านชื่อที่แสดงผลออกมา mlkem768x25519-sha256 และ sntrup761x25519-sha512@openssh.com เป็นการแลกเปลี่ยนกุญแจแบบ hybrid post-quantum ส่วน curve25519-sha256, ecdh-sha2-nistp256 และชื่อใดๆ ที่ขึ้นต้นด้วย diffie-hellman-group เป็นแบบดั้งเดิม (classical) ทั้งสองฝั่งจำเป็นต้องใช้เวอร์ชันที่รองรับชื่อแบบ post-quantum เนื่องจากกระบวนการเจรจาจะเลือกตัวเลือกแรกของไคลเอนต์ที่เซิร์ฟเวอร์รองรับด้วย ดังนั้นเครื่องที่เก่ากว่าจะเป็นตัวกำหนดขีดจำกัดสูงสุด

OpenSSH เวอร์ชันใดที่เปลี่ยนมาใช้ post-quantum key exchange เป็นค่าเริ่มต้น?

OpenSSH 9.0 ซึ่งปล่อยออกมาเมื่อ 2022-04-08 ได้กำหนดให้ sntrup761x25519-sha512@openssh.com เป็นการแลกเปลี่ยนกุญแจค่าเริ่มต้น ต่อมา OpenSSH 9.9 ซึ่งปล่อยเมื่อ 2024-09-19 ได้เพิ่ม mlkem768x25519-sha256 เข้ามา และ OpenSSH 10.0 ซึ่งปล่อยเมื่อ 2025-04-09 ได้เปลี่ยนมาใช้ตัวหลังเป็นค่าเริ่มต้นแทน OpenSSH 10.1 ซึ่งปล่อยเมื่อ 2025-10-06 เริ่มแสดงคำเตือนเมื่อการเชื่อมต่อไม่มีการเจรจาแบบ post-quantum ให้ตรวจสอบว่าบิลด์ของคุณทำงานอย่างไรด้วย ssh -Q kex และ ssh -G <host> เนื่องจากเวอร์ชันของ Ubuntu ที่คุณใช้จะเป็นตัวกำหนดว่าคุณมีเวอร์ชันใด

ฉันควรสร้างกุญแจ SSH แบบ post-quantum หรือไม่?

ไม่จำเป็น เพราะ OpenSSH ยังไม่มีกุญแจประเภทดังกล่าว งานด้าน post-quantum ในปัจจุบันครอบคลุมเฉพาะการแลกเปลี่ยนกุญแจ (key exchange) ซึ่งไม่จำเป็นต้องใช้ไฟล์กุญแจจากคุณและไม่ต้องตั้งค่าใดๆ ทั้งสิ้น กุญแจโฮสต์ (host keys) และกุญแจสำหรับล็อกอินยังคงเป็นลายเซ็นแบบดั้งเดิม เช่น Ed25519 และ RSA โดยทางผู้พัฒนาต้นน้ำระบุว่าจะมีการรองรับลายเซ็นแบบ post-quantum ในเวอร์ชันอนาคต ให้ใช้กุญแจ Ed25519 ต่อไปและดูแลรักษาที่จัดเก็บกุญแจให้ปลอดภัย

ทำไม ssh ถึงเตือนว่าการเชื่อมต่อของฉันไม่ใช่ post-quantum?

OpenSSH 10.1 และเวอร์ชันที่ใหม่กว่าจะแสดงข้อความ ** WARNING: connection is not using a post-quantum key exchange algorithm. เมื่อการแลกเปลี่ยนที่เจรจาได้ไม่มีส่วนประกอบแบบ post-quantum คำเตือนนี้เกี่ยวกับฝั่งเซิร์ฟเวอร์ ไม่ใช่ฝั่งไคลเอนต์ของคุณ เนื่องจากไคลเอนต์ของคุณได้เสนอชื่อแบบ post-quantum ไปแล้วแต่เซิร์ฟเวอร์ไม่ยอมรับตัวเลือกใดเลย ให้ทำการอัปเกรด OpenSSH ของเซิร์ฟเวอร์ หรือตรวจสอบว่าไม่มีการล็อกบรรทัด KexAlgorithms ไว้ในไฟล์ sshd_config ซึ่งเป็นการตัดชื่อแบบสมัยใหม่ออกไป การตั้งค่า WarnWeakCrypto no จะช่วยซ่อนข้อความดังกล่าว แต่จะทำให้การเชื่อมต่อยังคงมีความปลอดภัยในระดับเดิมเท่ากับก่อนหน้านี้