Post-quantum SSH บน Ubuntu เปลี่ยนแปลงไปอย่างไรบ้าง

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

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

ขออธิบายสองคำศัพท์ก่อน SSH (secure shell) คือโปรโตคอลที่คุณใช้ล็อกอินเข้าสู่เซิร์ฟเวอร์ ส่วน key exchange ซึ่งมักเขียนย่อว่า "kex" คือขั้นตอนแรกของการเชื่อมต่อ SSH ทุกครั้ง โดยทั้งสองฝั่งจะตกลงใช้ความลับร่วมกัน (shared secret) และความลับนั้นจะถูกนำไปใช้เข้ารหัสข้อมูลทั้งหมดหลังจากนั้น ส่วนที่เปลี่ยนแปลงคือขั้นตอน 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 เข้ามา แต่จงใจไม่ใส่ไว้ในรายการเริ่มต้น ใน release นั้น 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 key encapsulation mechanism ซึ่งเป็นมาตรฐาน FIPS 203) ที่พารามิเตอร์ชุด 768 ร่วมกับ X25519 elliptic curve Diffie-Hellman และผสมผลลัพธ์จากทั้งสองส่วนเข้าเป็น session key

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

debug1: kex: algorithm: curve25519-sha256

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

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

เมื่อละเว้น 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 ทำให้บิลด์รุ่นใหม่แสดงรายการภายใต้ชื่อเรียกทั้งสองแบบ
• 10.0 ซึ่งปล่อยเมื่อ 2025-04-09 ได้กำหนดให้ mlkem768x25519-sha256 เป็นค่าเริ่มต้นสำหรับการตกลงคีย์
• 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 จะเป็นการลบข้อความแจ้งเตือนออกไปโดยไม่ได้เปลี่ยนแปลงสิ่งใดเกี่ยวกับการเชื่อมต่อ

เหตุผลที่ต้องใช้ระบบไฮบริดและความหมายของแนวคิดเก็บข้อมูลไว้ก่อนแล้วค่อยถอดรหัสภายหลัง

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

การเข้ารหัสลับประสบปัญหานี้ในขณะที่ลายเซ็นดิจิทัลไม่ได้รับผลกระทบ ความไม่สมมาตรนี้เป็นปัจจัยขับเคลื่อนทุกอย่าง ข้อมูลที่เข้ารหัส (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 ซึ่งเป็น codebase ที่แตกต่างกันและมีกำหนดการพัฒนาที่ต่างกัน การอัปเกรด OpenSSH ไม่ส่งผลกระทบใดๆ ในส่วนนั้น หากคุณกำลังใช้งาน ใบรับรองแบบ self-signed สำหรับบริการส่วนตัวบน VPS เดียวกัน ลายเซ็นและกุญแจแลกเปลี่ยนของใบรับรองนั้นจะถูกกำหนดโดย OpenSSL และเว็บเซิร์ฟเวอร์ของคุณ ดังนั้นคุณควรตรวจสอบ stack นั้นตามเงื่อนไขของมันเอง

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

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

ห้ามเขียนบรรทัด KexAlgorithms ด้วยตนเอง นี่คือการกระทำเพียงอย่างเดียวที่ทำให้สถานการณ์แย่ลงอย่างแน่นอน คู่มือการปรับแต่งความปลอดภัยจากปี 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 ในขณะที่ลายเซ็นดิจิทัลยังคงเป็นแบบดั้งเดิม (classical) สิ่งใดที่กว้างกว่านั้นควรมาพร้อมกับชื่อที่คุณสามารถค้นหาได้ในผลลัพธ์ของ 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 เป็นค่าเริ่มต้น?

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 เริ่มแสดงคำเตือนเมื่อการเชื่อมต่อไม่มีการเจรจาแบบดังกล่าว ให้ตรวจสอบว่า build ของคุณทำงานอย่างไรด้วย 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 จะเป็นการซ่อนข้อความดังกล่าวและทำให้การเชื่อมต่อยังคงมีความปลอดภัยในระดับเดิมเท่ากับก่อนหน้านี้