การจับมือ SSH และการยืนยันตัวตนด้วยกุญแจโฮสต์

SSH เริ่มต้นด้วยการเชื่อมต่อ TCP ไปยังพอร์ต 22 เมื่อสร้างการเชื่อมต่อแล้ว ไคลเอนต์และเซิร์ฟเวอร์จะแลกเปลี่ยนสตริงเวอร์ชัน เช่น SSH-2.0-OpenSSH_9.3 ซึ่งระบุเวอร์ชันของโพรโทคอลและการนำไปใช้งาน การแลกเปลี่ยนเวอร์ชันนี้ช่วยให้ทั้งสองฝ่ายยืนยันความเข้ากันได้ก่อนดำเนินการต่อ

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

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

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

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

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

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

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

เมื่อสร้างกุญแจเซสชันแล้ว การสื่อสาร SSH ที่เกิดขึ้นต่อจากนั้นทั้งหมดจะถูกเข้ารหัสและยืนยันความถูกต้อง โพรโทคอลเข้ารหัสที่เจรจาได้ เช่น AES-256-GCM หรือ ChaCha20-Poly1305 จะปกป้องความลับของข้อมูล ขณะที่ MAC ช่วยรับรองความถูกต้องครบถ้วน แม้แต่ชื่อผู้ใช้และข้อมูลรับรองการยืนยันตัวตนก็ถูกส่งอยู่ภายในช่องสัญญาณที่เข้ารหัสนี้

กุญแจโฮสต์ RSA ขนาด 2048 หรือ 4096 บิตรองรับระบบต่าง ๆ อย่างแพร่หลาย แต่ทำงานช้ากว่า กุญแจ ECDSA ที่อาศัยเส้นโค้งของ NIST ทำงานได้เร็วกว่า แต่บางฝ่ายไม่ไว้วางใจพารามิเตอร์เส้นโค้งของ NIST กุญแจ Ed25519 ที่อาศัย Curve25519 เป็นคำแนะนำสมัยใหม่ เพราะมีขนาดเล็ก ทำงานเร็ว มีความปลอดภัยสูง และไม่พึ่งพาพารามิเตอร์เส้นโค้งของ NIST เซิร์ฟเวอร์ SSH สมัยใหม่ส่วนใหญ่เปิดให้ใช้ Ed25519 เป็นค่าเริ่มต้น

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

หลังจากการเชื่อมต่อครั้งแรก ไคลเอนต์จะตรวจสอบกุญแจโฮสต์ของเซิร์ฟเวอร์ SSH ในการเชื่อมต่อครั้งต่อไปได้อย่างไร

ในบทเรียนนี้: TCP เชื่อมต่อที่พอร์ต 22 มีการแลกเปลี่ยนสตริงเวอร์ชัน การเจรจาอัลกอริทึมเลือกโพรโทคอลเข้ารหัสและวิธีแลกเปลี่ยนกุญแจ ECDH หรือ DH สร้างข้อมูลลับร่วม มีการสร้างกุญแจเซสชันแยกกันสำหรับแต่ละทิศทาง เซิร์ฟเวอร์ยืนยันตัวตนด้วยลายเซ็นจากกุญแจโฮสต์ และไคลเอนต์ตรวจสอบกับ known_hosts โดยใช้ TOFU ในการเชื่อมต่อครั้งแรก