

เวลาติดตั้ง server ใหม่แล้ว SSH เตือนว่า host key เปลี่ยน เราอาจรู้สึกว่าเป็นเพียงข้อมูลเก่าที่ต้องลบออกเพื่อเชื่อมต่อให้ได้ แต่ข้อความนี้กำลังบอกว่าตัวตนที่ปลายทางแสดงต่างจากสิ่งที่ client เคยเชื่อไว้
ความต่างอาจมีเหตุที่ตั้งใจ เช่น สร้างเครื่องใหม่หรือหมุนกุญแจ และอาจมาจากต่อไปผิดปลายทางหรือมีคนแทรกกลาง การเดาจากว่าเพิ่ง deploy จึงยังไม่ใช่หลักฐานว่ากุญแจที่เห็นตอนนี้เป็นของเครื่องที่ต้องการจริง
ก่อนแก้ข้อมูลที่ client จำไว้ ควรแยกกุญแจยืนยัน host ออกจากกุญแจล็อกอินของผู้ใช้ครับ แล้วตรวจตัวตนใหม่ผ่านทางที่เชื่อถือได้ตามระบบที่ดูแล
Host key ใช้ในหน้าที่ให้ client ตรวจตัวตน server ที่กำลังเชื่อม ส่วนกุญแจของผู้ใช้ใช้ให้ server ตรวจว่าผู้เชื่อมมีข้อมูลรับรองที่ได้รับอนุญาตกับบัญชีนั้น ทั้งสองอยู่ในช่องทาง SSH เดียวกันแต่ตอบคำถามคนละด้าน
การที่ user private key ถูกต้องจึงไม่ได้แก้ความไม่แน่ใจของ host key และการยืนยัน host ได้ก็ไม่ได้ให้สิทธิ์ล็อกอินทุกบัญชี เราต้องผ่านการตรวจที่เกี่ยวข้องตามกลไก ไม่ใช้ความสำเร็จด้านหนึ่งแทนอีกด้าน
ในรูปแบบ public-key authentication ทั่วไป server เก็บ public key ที่อนุญาตใน authorized_keys ตามบัญชี ส่วน client ถือ private key หรือใช้ agent ตามที่ตั้งไว้ ไฟล์นี้จึงต่างจาก known_hosts ที่ client ใช้เก็บความสัมพันธ์ของปลายทางกับ host identity
เมื่อเห็นข้อความผิดพลาด ควรอ่านว่าติดช่วงตรวจ host หรือช่วง user authentication ก่อน ไม่สร้าง user key ใหม่หรือคัด authorized_keys ซ้ำเพื่อแก้ข้อความที่จริงกำลังเตือนตัวตน server เปลี่ยน

Client ใช้ข้อมูลที่รู้จักกับ host เพื่อเทียบสิ่งที่ปลายทางแสดง การเชื่อมผ่านชื่อ IP alias หรือ port ต่างกันจึงต้องดูว่ารายการที่ถูกตรวจอ้างบริบทใด ไม่เห็นชื่อเครื่องคล้ายกันแล้วคิดว่าเป็นการตรวจเดียวกันเสมอ
ตัวอย่างสมมติคือชื่อบริการถูกย้ายไปเครื่องใหม่แต่ client ยังจำกุญแจเดิม หรือ IP เดิมถูกนำไปให้เครื่องอื่น ภายนอกเราอาจพิมพ์คำสั่งเหมือนเดิม แต่ตัวตนที่ความสัมพันธ์นั้นชี้ถึงเปลี่ยนไปแล้ว
ต้องตรวจ DNS เส้นทาง proxy หรือ jump host และ config ที่ใช้ด้วยว่ากำลังไปที่ใด การตรวจ fingerprint ของเครื่องที่ควรไปจะช่วยได้ก็ต่อเมื่อผูกกับปลายทางที่คำสั่งเลือกจริง ไม่เอากุญแจของอีก environment มารับรองเพราะชื่อโปรเจกต์เหมือนกัน
การตั้งชื่อและข้อมูล inventory ที่ชัดจึงมีส่วนช่วยรับมือคำเตือน ไม่ใช่เพียงความเรียบร้อยของเอกสาร เพราะทำให้ตามได้ว่ามีการเปลี่ยนเครื่องครั้งใดและใครเป็นเจ้าของตัวตนที่ต้องตรวจ
Fingerprint เป็นรูปย่อสำหรับตรวจ public key ตามวิธีของเครื่องมือ การคำนวณได้จากกุญแจที่รับมายังไม่รับรองว่าเจ้าของกุญแจคือ host ที่ตั้งใจ ต้องมีค่าที่เชื่อถือได้มาเทียบ
ทางตรวจอาจเป็น console ของเครื่องที่เข้าผ่านช่องทางจัดการที่ยืนยันไว้ หรือ inventory ที่กระบวนการ provision ส่งมอบอย่างมีความเชื่อถือ แล้วเทียบชนิดกุญแจกับ fingerprint ให้ตรงกันตามขอบเขตนั้น
ssh-keygen มีวิธีแสดง fingerprint ของ public key เช่นรูปแบบต่อไปนี้ซึ่งเป็น path สมมติสำหรับไฟล์ที่นำมาจากแหล่งที่ตรวจตัวตนแล้ว ไม่ใช่คำสั่งที่รันอ่านกุญแจของผู้ใช้ในรอบนี้
ssh-keygen -l -f /path/to/verified-host-key.pub
ssh-keyscan มีประโยชน์ในการเก็บ public host key ที่ปลายทางตอบ แต่เอกสารระบุว่าการสร้าง known hosts จากผลนั้นโดยไม่ verify ยังเสี่ยงต่อการแทรกกลาง มันจึงเป็นทางรวบรวมข้อมูล ไม่ใช่หลักฐานอิสระว่าควรเชื่อข้อมูลที่เพิ่งเก็บ

ข้อความยอมรับ host ครั้งแรกอาจดูธรรมดากว่าคำเตือนเปลี่ยนกุญแจ แต่เรายังต้องตัดสินว่าจะตั้งความเชื่อจากอะไร หากไม่มีค่าที่รู้มาก่อน การกดยอมรับก็เป็นการเลือกโมเดลความเชื่อที่ต้องเข้าใจ ไม่ใช่ขั้นที่รับรองปลายทางจากภายนอกให้แล้ว
ในระบบที่จัดการหลายเครื่อง สามารถวางการส่งมอบข้อมูล host identity ไปยัง client ผ่านกระบวนการที่เชื่อถือได้ตามเครื่องมือ หรือใช้กลไก certificate และ CA สำหรับ host ตามสถาปัตยกรรมที่รองรับ แต่ต้องรู้ว่า trust anchor นั้นมาจากไหนและใครเปลี่ยนได้
ไม่ควรนำ private host key เดียวใส่ใน image แล้วกระจายให้เครื่องที่ควรมีตัวตนแยกกันเพียงเพื่อไม่ให้ client ต้องรู้จักหลายกุญแจ ความสะดวกนั้นเปลี่ยนขอบเขตว่าตัวตนหนึ่งแทนเครื่องใดและใครถือความสามารถของมันอยู่บ้าง
ถ้าตรวจผ่านทางที่เชื่อถือได้แล้วว่าปลายทางกับกุญแจใหม่ตรงการเปลี่ยนที่ตั้งใจ ค่อยสำรองและปรับรายการที่เกี่ยวข้องตามเครื่องมือ โดยรักษาหลักฐานว่าอะไรถูกแทนด้วยอะไร ไม่ล้างทั้งไฟล์เพื่อแก้เหตุของ host เดียว
การปิด StrictHostKeyChecking เหมารวมทำให้ข้อความขวางทางหายไป แต่ยังไม่ได้ตอบข้อสงสัยที่ระบบกำลังให้ตรวจ จึงไม่ควรใช้เป็นขั้นแก้ถาวรในคำสั่งของคนหรือ CI โดยไม่มีโมเดลความเชื่ออื่นที่ทดแทนอย่างชัดเจน
หากยังยืนยันไม่ได้ ควรเก็บชนิดกุญแจ fingerprint ชื่อปลายทาง port และเหตุที่คาดว่ามีการเปลี่ยน ส่งต่อให้เจ้าของระบบตรวจตามช่องทางที่มีสิทธิ์ ไม่ใส่ private key หรือข้อมูลล็อกอินในรายงานเพื่อให้คนอื่นช่วยเดา
สำหรับ CI หรืองาน backup ที่เชื่อม SSH ควรตรวจในชุดทดลองว่าปลายทางที่รู้จักใช้ได้ และเมื่อกุญแจไม่ตรงงานหยุดพร้อมหลักฐานที่เหมาะสมจริง ไม่ตั้งให้ยอมรับทุกค่าเพียงเพื่อไม่ให้ deployment รอคำถามใน terminal
การหมุนกุญแจที่วางแผนควรมีลำดับกระจายความเชื่อและตรวจ client ที่เกี่ยวข้อง พร้อมวิธีย้อนตรวจเมื่อบางตัวไม่เปลี่ยน ไม่ปล่อยให้แต่ละคนลบคำเตือนด้วยตนเองโดยไม่มีข้อมูลอ้างอิงร่วม เพราะจะตรวจความครบและการเชื่อผิดปลายทางได้ยาก
SSH host key ใช้ยืนยันเครื่องที่เรากำลังเข้า ส่วน user key ใช้ยืนยันผู้ขอเข้า คำเตือน host เปลี่ยนจึงต้องตรวจตัวตนใหม่ก่อนแก้สิ่งที่ client เชื่อไว้ เมื่อมี fingerprint จากทางที่เชื่อถือได้และปรับเฉพาะรายการตามแผน เราจะรับมือการสร้างเครื่องหรือหมุนกุญแจได้ โดยยังรักษาหน้าที่ตรวจปลายทางที่ทำให้ช่องทาง SSH มีความหมาย