ประวัติความเป็นมาของ SSH ตั้งแต่ยุค Telnet ถึง OpenSSH

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

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

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

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

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

rlogin มีต้นกำเนิดมาจาก Berkeley Unix และถูกบันทึกไว้ในภายหลังใน RFC 1282 (BSD Rlogin, B. Kantor, ธันวาคม 1991) โปรโตคอลนี้เพิ่มสิ่งที่แย่ยิ่งกว่ารหัสผ่านที่อ่านได้ นั่นคือความเชื่อใจระดับโฮสต์ (host-based trust) เซิร์ฟเวอร์สามารถถูกตั้งค่าให้ยอมรับการล็อกอินจากโฮสต์ที่ระบุโดยไม่ต้องใช้รหัสผ่านเลย เอกสาร RFC ฉบับนี้มีส่วนที่เรียกว่า "เรื่องราวเตือนใจ" (A Cautionary Tale) ซึ่งระบุว่า "การข้ามการตรวจสอบสิทธิ์ด้วยรหัสผ่านจากโฮสต์ที่เชื่อถือได้จะเปิดช่องให้ระบบทั้งหมดที่ตั้งค่าในลักษณะนี้ถูกบุกรุกได้ทันทีหากมีเพียงระบบเดียวที่ถูกเจาะ" นอกจากนี้ยังระบุด้วยว่าความเชื่อใจนี้อ้างอิงจากชื่อโฮสต์ ดังนั้นหาก DNS (domain name system) ถูกโจมตีหรือมีการปลอมแปลงที่อยู่ IP ก็จะทำให้มาตรการนี้ไร้ผล

การออกแบบทั้งสองแบบนี้เหมาะสมกับเครือข่ายในยุคที่พวกมันถือกำเนิดขึ้น Ethernet ในยุคแรกเป็นสื่อกลางแบบใช้ร่วมกัน (shared medium) โดยเครื่องทุกเครื่องบนเซกเมนต์จะได้รับทุกเฟรมและถูกคาดหวังให้เพิกเฉยต่อเฟรมที่ไม่ได้ส่งถึงตนเอง เครื่องที่หยุดเพิกเฉยต่อเฟรมเหล่านั้น ซึ่งเป็นความหมายของ promiscuous mode จะสามารถมองเห็นทราฟฟิกของผู้อื่นทั้งหมดได้ เมื่อรวมกับสภาพแวดล้อมของมหาวิทยาลัยที่แจกบัญชี shell ให้กับนักศึกษานับพันคน บัญชีที่ถูกเจาะเพียงบัญชีเดียวจึงกลายเป็นเครื่องมือเก็บรหัสผ่านสำหรับทั้งภาควิชา

คำแนะนำในปี 1994 ที่ไม่มีการแก้ไขให้

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

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

เหตุใดการโจมตีแบบ sniffing ใน Helsinki จึงทำให้เกิด SSH

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

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

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

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

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

เหตุใด OpenBSD จึงแยก OpenSSH ออกมาในปี 1999

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

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

เหตุใดการแยกโครงการ (fork) โดยโครงการระบบปฏิบัติการขนาดเล็กแห่งหนึ่งจึงไปปรากฏอยู่บนเครื่องคอมพิวเตอร์เกือบทุกเครื่องได้? คำตอบคือเพราะสิ่งที่ OpenBSD ต้องการจากซอฟต์แวร์นี้ OpenBSD จัดส่งระบบพื้นฐานที่ผ่านการตรวจสอบแล้ว ซึ่งมุ่งเน้นให้มีความปลอดภัยในการตั้งค่าเริ่มต้น ดังนั้นการเข้าสู่ระบบระยะไกลแบบเข้ารหัสจึงจำเป็นต้องอยู่ในระบบพื้นฐานนั้น ภายใต้สัญญาอนุญาตที่ไม่มีข้อจำกัดใด ๆ โค้ดที่ผ่านการตรวจสอบภายใต้สัญญาอนุญาตที่ไม่มีข้อจำกัดคือสิ่งที่ผู้จำหน่ายระบบปฏิบัติการรายอื่น ๆ ต้องการเช่นกัน Damien Miller, Philip Hands และคนอื่น ๆ ได้เริ่มสร้างสาขาแบบพกพา (portable branch) ขึ้นมาเกือบจะทันที ซึ่งเป็นที่มาของ p ในเวอร์ชันอย่าง 10.5p1 โดย OpenBSD จะพัฒนาเวอร์ชันที่สะอาดไว้ และสาขาแบบพกพาจะทำหน้าที่เพิ่มส่วนเชื่อมต่อสำหรับระบบอื่น ๆ วิธีที่ Unix แยกตัวออกเป็นระบบที่เราใช้งานในปัจจุบัน คือเหตุผลว่าทำไมจึงจำเป็นต้องมีส่วนเชื่อมต่อดังกล่าว

การรองรับโปรโตคอลเวอร์ชันที่สองตามมาในภายหลัง โดย OpenSSH 2.0 ถูกรวมมาพร้อมกับ OpenBSD 2.7 เมื่อวันที่ 15 มิถุนายน 2000

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

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

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

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

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

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

เหตุผลที่ SSH-1 ถูกถอดออกแทนที่จะแก้ไข

การถอดถอนนี้ใช้เวลาถึงสาม https://www.openssh.org/releasenotes.html OpenSSH releases โดยเวอร์ชัน 7.0 เมื่อวันที่ 11 สิงหาคม 2015 ได้ปิดการใช้งาน protocol 1 เป็นค่าเริ่มต้นในขั้นตอน compile เวอร์ชัน 7.4 เมื่อวันที่ 19 ธันวาคม 2016 ได้ถอดการรองรับฝั่งเซิร์ฟเวอร์ออก และเวอร์ชัน 7.6 เมื่อวันที่ 3 ตุลาคม 2017 ได้ลบฝั่งไคลเอนต์ออกไปพร้อมกับตัวเลือกการตั้งค่าและเอกสารประกอบทั้งหมด

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

ทำไมการเชื่อมต่อ SSH ครั้งแรกถึงแจ้งเตือนเรื่อง host key

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

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

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 จะเป็นการจัดเก็บกุญแจนั้นไว้ใน ~/.ssh/known_hosts การเชื่อมต่อในครั้งถัดไปทั้งหมดจะถูกนำไปเปรียบเทียบกับค่าที่จัดเก็บไว้ และหากไม่ตรงกัน โปรแกรมจะแสดงข้อความแจ้งเตือนที่รุนแรงที่สุดเท่าที่จะทำได้:

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

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

เหตุผลที่ public key เข้ามาแทนที่รหัสผ่าน

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

เหตุผลประการที่สองคือเรื่องทางสถิติ เซิร์ฟเวอร์ทุกเครื่องที่เปิดพอร์ต 22 บน public address จะได้รับความพยายามเข้าสู่ระบบโดยอัตโนมัติตลอดเวลา และ password เป็นสตริงที่เดาได้ ส่วน key นั้นไม่สามารถเดาได้ในทางปฏิบัติ การตั้งค่า PasswordAuthentication no จะหยุดการโจมตีประเภทนี้ทั้งหมด จึงปรากฏอยู่ใน checklist สำหรับ hardening ทุกชุด อย่างไรก็ตาม การตั้งค่านี้ยังลบช่องทางสำรองที่เคยช่วยให้คุณเข้าสู่ระบบได้เมื่อ key มีปัญหา ดังนั้นควรเรียนรู้ วิธีแยกแยะสาเหตุหลายแบบที่ล้วนรายงานว่า Permission denied (publickey) ก่อนที่คุณจะเป็นฝ่ายถูกล็อกไม่ให้เข้าใช้งาน

การใช้งานโดยไม่ใช้ password ยังหมายถึงการมี key เพิ่มขึ้นเรื่อย ๆ และ agent ที่ถือ key อยู่เป็นจำนวนมากจะลองใช้แต่ละ key ตามลำดับ จนกว่าเซิร์ฟเวอร์จะถึงขีดจำกัดจำนวนครั้งที่อนุญาตและตัดการเชื่อมต่อ ซึ่งเป็น สาเหตุที่การเข้าสู่ระบบอาจล้มเหลวด้วย Too many authentication failures แม้จะโหลด key ที่ถูกต้องแล้ว การสร้างและหมุนเวียน key อธิบายไว้ใน พื้นฐานการจัดการ SSH key ส่วนการตั้งค่าฝั่งเซิร์ฟเวอร์อยู่ใน การ hardening SSH บน VPS

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

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

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

ในทางกลับกัน DSA มีทิศทางที่ต่างออกไป OpenSSH 7.0 ได้ปิดการใช้งาน host key และ user key แบบ ssh-dss ในขณะรันไทม์เมื่อปี 2015 เนื่องจากอัลกอริทึมนี้จำกัดอยู่ที่ private key ขนาด 160-bit และ SHA-1 ส่วนเวอร์ชัน 9.8 เมื่อวันที่ 1 กรกฎาคม 2024 ได้ปิดการใช้งาน DSA ในระดับ compile time และเวอร์ชัน 10.0 เมื่อวันที่ 9 เมษายน 2025 ได้ถอดถอนอัลกอริทึมนี้ออก โดยทางโครงการระบุว่าเป็นการ "เสร็จสิ้นกระบวนการเลิกใช้งานที่เริ่มมาตั้งแต่ปี 2015" รวมระยะเวลา 10 ปีตั้งแต่เริ่มปิดการใช้งานจนถึงการลบออก

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

กระบวนการเดียวกันนี้กำลังเกิดขึ้นกับการแลกเปลี่ยนกุญแจ (key exchange) ซึ่งครั้งนี้เป็นการดำเนินการก่อนที่จะเกิดภัยคุกคามจริง ทราฟฟิกที่ถูกดักจับในวันนี้อาจถูกจัดเก็บและถอดรหัสได้ในอีกหลายปีข้างหน้าโดยผู้ที่ครอบครองคอมพิวเตอร์ควอนตัมที่มีประสิทธิภาพ ดังนั้นการตกลงกุญแจจึงต้องเปลี่ยนก่อนที่เครื่องดังกล่าวจะมีอยู่จริง OpenSSH 9.0 เมื่อวันที่ 8 เมษายน 2022 ได้กำหนดให้การแลกเปลี่ยนกุญแจแบบไฮบริดเป็นค่าเริ่มต้น โดย sntrup761x25519-sha512@openssh.com จะจับคู่อัลกอริทึมแบบ post-quantum เข้ากับ X25519 ดังนั้นผลลัพธ์ที่ได้จะไม่มีความปลอดภัยน้อยไปกว่าส่วนที่เป็นแบบดั้งเดิมแม้ว่าอัลกอริทึมใหม่จะทำงานได้ไม่ดีตามคาด OpenSSH 9.9 เมื่อวันที่ 19 กันยายน 2024 ได้เพิ่ม mlkem768x25519-sha256 ซึ่งสร้างขึ้นบน ML-KEM (module lattice key encapsulation mechanism) ที่ NIST ได้กำหนดมาตรฐานไว้ในปี 2024 และ OpenSSH 10.0 ได้กำหนดให้สิ่งนี้เป็นค่าเริ่มต้นสำหรับการตกลงกุญแจ โดย หน้าเว็บเกี่ยวกับ post-quantum ของโครงการ ได้อธิบายเหตุผลไว้ OpenSSH 10.1 เมื่อวันที่ 6 ตุลาคม 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.

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

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

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

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

FAQ

ใครเป็นผู้สร้าง SSH และสร้างขึ้นมาทำไม?

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

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

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

ทำไม OpenSSH ถึงเข้ามาแทนที่การใช้งาน SSH แบบดั้งเดิม?

การพัฒนา SSH แบบดั้งเดิมได้เปลี่ยนไปเป็นผลิตภัณฑ์เชิงพาณิชย์ที่มีใบอนุญาตแบบจำกัด และรุ่นสุดท้ายที่สามารถนำกลับมาใช้ใหม่ได้อย่างอิสระคือ ssh 1.2.12 ในช่วงต้นปี 1999 Björn Grönvall ได้นำรุ่นนั้นมาพัฒนาต่อในชื่อ OSSH และทีมงาน OpenBSD ได้ fork OSSH ออกมาเป็น OpenSSH ซึ่งมาพร้อมกับ OpenBSD 2.6 เมื่อวันที่ 1 ธันวาคม 1999 OpenBSD ต้องการโค้ดที่ผ่านการตรวจสอบภายใต้ใบอนุญาตที่ไม่จำกัดสำหรับระบบพื้นฐาน ซึ่งคุณสมบัติทั้งสองประการนี้เองที่ทำให้ระบบปฏิบัติการอื่นๆ สามารถนำ implementation เดียวกันนี้ไปใช้งานผ่านสาขา portable ได้

ทำไม SSH ถึงถามเกี่ยวกับ host key ในการเชื่อมต่อครั้งแรก?

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

ทำไม SSH key รุ่นเก่าถึงใช้งานไม่ได้หลังจากการอัปเกรด?

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