SSH เป็นโปรโตคอลเครือข่ายที่ปลอดภัย ทำงานโดยสร้างอุโมงค์เข้ารหัสระหว่างระบบต่างๆ ยังคงได้รับความนิยมในหมู่นักพัฒนาที่ต้องการเข้าถึงเซิร์ฟเวอร์จากระยะไกลโดยไม่ต้องใช้อินเทอร์เฟซแบบกราฟิก แม้ SSH จะมีมาหลายสิบปีและให้บริการผู้ใช้มาอย่างยาวนาน แต่ก็ยังอาจพบข้อผิดพลาดบางอย่างได้
ข้อผิดพลาดหลายรายการเป็นที่รู้จักกันดีในชุมชน SSH และมีวิธีแก้ไขที่บันทึกไว้อย่างแพร่หลาย ซึ่งรวมถึง ความเข้ากันไม่ได้ของไฟร์วอลล์, ปัญหาการ inject public key ของ SSH, ปัญหาโหมด file key ของ SSHและข้อผิดพลาด "Warning: Remote Host Identification Has Changed"
ข้อผิดพลาดนี้เกิดขึ้นได้กับระบบปฏิบัติการหลักทุกระบบ ไม่ว่าจะเป็น Windows, Linux และ macOS สาเหตุของปัญหาอาจไม่ใช่แค่ข้อผิดพลาดทางเทคนิคทั่วไป แต่อาจเป็นสัญญาณเตือนด้านความปลอดภัยที่ต้องให้ความสนใจ บทความนี้จะอธิบายว่าเหตุใดจึงเกิดขึ้น หมายความว่าอย่างไรต่อความปลอดภัยของการเชื่อมต่อ SSH ของคุณ และวิธีแก้ไขบนแต่ละแพลตฟอร์ม
อะไรทำให้เกิดคำเตือน Warning: Remote Host Identification Has Changed และควรกังวลไหม?
คำเตือน "Warning: Remote Host Identification Has Changed" จะปรากฏขึ้นเมื่อ public key ของ SSH ที่เก็บอยู่ในไฟล์ known_hosts ไม่ตรงกับ key ที่เซิร์ฟเวอร์กำลังแสดงอยู่ในขณะนั้น ความไม่ตรงกันนี้จะกระตุ้นกลไกความปลอดภัยในตัวของ SSH เพื่อปกป้องคุณจากภัยคุกคามที่อาจเกิดขึ้น
สาเหตุที่ไม่เป็นอันตรายของการเปลี่ยนแปลง host key
มีสาเหตุหลายประการที่ไม่เป็นอันตรายซึ่งอธิบายได้ว่าทำไม host key ของเซิร์ฟเวอร์อาจเปลี่ยนแปลง บางครั้งคุณอาจเห็นข้อความต่างออกไป เช่น "RSA host key has changed" ขึ้นอยู่กับประเภท key ที่ใช้งาน

การเปลี่ยนแปลงที่เกี่ยวข้องกับเซิร์ฟเวอร์:
- ระบบปฏิบัติการของเซิร์ฟเวอร์ถูกติดตั้งใหม่หรืออัปเกรด
- เซิร์ฟเวอร์ถูกสร้างใหม่หรือกู้คืนจากข้อมูลสำรอง
- การตั้งค่า SSH ของเซิร์ฟเวอร์ถูกรีเซ็ต
- เครื่องจริงหรือเครื่องเสมือนถูกเปลี่ยนใหม่
- ย้ายเซิร์ฟเวอร์ไปยังฮาร์ดแวร์ชุดใหม่
การเปลี่ยนแปลงการตั้งค่าเครือข่าย:
- ผู้ให้บริการ cloud นำ IP address กลับมาใช้ใหม่เมื่อเวลาผ่านไป หรือการเชื่อมต่อของคุณถูกส่งผ่าน load balancer
- DHCP กำหนด IP address เดิมให้กับเครื่องอื่น
- IP ของเซิร์ฟเวอร์ที่ปลดระวางแล้วถูกนำไปกำหนดให้กับระบบใหม่
- เร็กคอร์ด DNS ถูกอัปเดตให้ชี้ไปยังเซิร์ฟเวอร์อื่น

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

การโจมตีแบบ man-in-the-middle แม้จะพบไม่บ่อย แต่ก็เกิดขึ้นได้จริง ในการโจมตีประเภทนี้ ผู้โจมตีจะแทรกตัวอยู่ระหว่างคอมพิวเตอร์ของคุณกับเซิร์ฟเวอร์จริง เพื่อดักจับการรับส่งข้อมูลทั้งหมด
ข้อผิดพลาดของผู้ใช้ และ social engineering คิดเป็น 68% ของการละเมิดความปลอดภัย ซึ่งทำให้การเฝ้าระวังเป็นสิ่งสำคัญ คุณสามารถป้องกันระบบได้มากขึ้นโดยศึกษาเกี่ยวกับ การป้องกันการโจมตีแบบ brute-force
สถิติล่าสุดจาก IBM ระบุว่าต้นทุนเฉลี่ยทั่วโลกของการ การรั่วไหลข้อมูล อยู่ที่ 4.44 ล้านดอลลาร์ในปี 2025 โดยใช้เวลาตรวจพบเฉลี่ยแปดเดือน นี่คือเหตุผลที่กลไกการตรวจสอบ host key ของ SSH มีความสำคัญ และทำไมคุณไม่ควรเพิกเฉยต่อคำเตือนเหล่านี้โดยไม่ตรวจสอบ
วิธีตรวจสอบว่าคำเตือนนี้ปลอดภัยหรือไม่
ก่อนดำเนินการแก้ไข ให้ทำขั้นตอนการตรวจสอบเหล่านี้ก่อน:

- ตรวจสอบกับทีมของคุณ: หากคุณใช้งานเซิร์ฟเวอร์ร่วมกัน ให้สอบถามเพื่อนร่วมงานว่ามีการเปลี่ยนแปลงใดเกิดขึ้นหรือไม่
- ตรวจสอบ log ของเซิร์ฟเวอร์: ตรวจสอบบันทึกการบำรุงรักษาหรือ change log เพื่อดูกิจกรรมล่าสุด
- ติดต่อผู้ให้บริการโฮสติ้งของคุณ: หากใช้บริการคลาวด์ ให้ตรวจสอบว่ามีการบำรุงรักษาระบบเกิดขึ้นหรือไม่
- ใช้ช่องทางที่ปลอดภัย: หากเป็นไปได้ ให้เชื่อมต่อผ่านเครือข่ายที่เชื่อถือได้เพื่อยืนยัน fingerprint
- เปรียบเทียบลายนิ้วมือ: ผู้ให้บริการโฮสติ้งบางรายแสดง fingerprints SSH ปัจจุบันไว้ในแผงควบคุม
หากคุณมั่นใจว่าการเปลี่ยนแปลง key นั้นถูกต้อง ก็สามารถลบ key เก่าและยอมรับ key ใหม่ได้อย่างปลอดภัย
ถ้าต้องการหลีกเลี่ยงปัญหา IP เปลี่ยนแบบไม่คาดฝัน หรือ host key ขัดแย้งกัน การเลือก infrastructure ที่เหมาะสมถือเป็นเรื่องสำคัญ
Cloudzy มอบให้ การโฮสติง SSH VPS พร้อม IP แบบ static ที่ใช้งานได้เฉพาะคุณ รันบน Ryzen 9 processors และ storage แบบ NVMe เพื่อให้คำสั่งทำงานได้ทันที เครือข่ายของเรารองรับได้ถึง 40 Gbps ใน 12 ที่ตั้งทั่วโลก และยังได้รับการป้องกัน VPN ฟรีเพื่อความปลอดภัยของการเชื่อมต่อคุณ
วิธีแก้ไขข้อผิดพลาด "Remote Host Identification Has Changed"
วิธีแก้ไขนั้นง่ายมาก: ลบ key record เก่าออกจากระบบของคุณ การทำเช่นนี้จะล้างความขัดแย้งของ key และให้คุณบันทึก key ใหม่ได้ในครั้งถัดไปที่เชื่อมต่อ ดูคู่มือของเราเกี่ยวกับ ไคลเอนต์ SSH สำหรับเครื่องมืออื่น ๆ เพิ่มเติม
นอกจากนี้ คุณยังทำสิ่งนี้ได้ด้วยคำสั่งเดียว หรือจะแก้ไขไฟล์ด้วยตัวเองก็ได้เช่นกัน
วิธีที่ 1: ใช้ Command Line (เร็วที่สุด)
วิธีนี้ใช้ได้กับ macOS, Linux และ Windows 10 ขึ้นไป (ใช้ OpenSSH) และเป็นวิธีที่เร็วที่สุดในการแก้ไขข้อผิดพลาด หากต้องการข้อมูลเพิ่มเติม อ่านได้ที่ หน้าคู่มือ ssh-keygen.
- เปิด terminal ของคุณ
- รันคำสั่งนี้ (แทนที่ hostname พร้อม IP หรือโดเมนของเซิร์ฟเวอร์คุณ):
ssh-keygen -R hostname
This command automatically finds the old key in your known_hosts file and deletes it. Method 2: Manual File Editing (macOS)
หากคุณถนัดใช้งานผ่าน visual editor ก็ลบ key นั้นออกได้เองเลย โดยทั่วไปข้อความแจ้งข้อผิดพลาดจะบอกชัดเจนว่าต้องลบที่บรรทัดไหน
เปิด terminal แล้วแก้ไขไฟล์ด้วย Nano:
nano ~/.ssh/known_hosts
ค้นหาบรรทัดที่ตรงกับข้อความแสดงข้อผิดพลาด ลบบรรทัดนั้น แล้วกด Ctrl + X และ Y เพื่อบันทึก

วิธีแก้ไขสำหรับ Windows
ผู้ใช้ Windows มักใช้ OpenSSH client ที่มีในตัวระบบ หรือไม่ก็ PuTTY
ตัวเลือกที่ 1: Windows OpenSSH (Windows 10/11)
บน Windows 10 และ 11 OpenSSH เป็น optional feature ที่ต้องติดตั้งเพิ่มเติมผ่าน Settings > Apps > Optional features ส่วน Server 2025 มี client มาให้แล้ว แต่ต้องเปิดใช้งานก่อน
หากใช้ PowerShell หรือ Command Prompt คำสั่ง ssh-keygen จาก Method 1 ใช้งานได้เช่นกัน
หากต้องการแก้ไขไฟล์ด้วยตนเองแทน:
- กด Windows Key + R.
- ประเภท %USERPROFILE%\.ssh และกด Enter.
- เปิด known_hosts ไฟล์ด้วย Notepad
- ลบบรรทัดที่ทำให้เกิด error แล้วบันทึกไฟล์
สำหรับการจัดการ key อย่างถูกต้อง ดูคู่มือของเราเรื่อง การสร้าง SSH keys ใน Windows.
ตัวเลือกที่ 2: ใช้ PuTTY
PuTTY เก็บ key ไว้ใน Windows Registry แทนที่จะเป็นไฟล์
- เปิด Registry Editor (กด Windows Key + R, พิมพ์ regeditและกด Enter).
- ไปที่: HKEY_CURRENT_USER\Software\SimonTatham\PuTTY\SshHostKeys\
- ค้นหา entry ที่ตรงกับ hostname หรือ IP ของเซิร์ฟเวอร์
- คลิกขวาแล้วเลือก ลบ.

วิธีแก้ไขสำหรับ Linux
ค่า ssh-keygen คำสั่งที่เราครอบคลุมไปแล้ว วิธีที่ 1 เป็นวิธีมาตรฐานในการแก้ไขปัญหานี้บน Linux รวดเร็วและรองรับได้โดยตรง
แก้ไขด้วยตนเอง
หากต้องการดูเนื้อหาของไฟล์ สามารถเปิดแก้ไขด้วย text editor อย่าง Nano ได้
- เปิด terminal ของคุณ
- ประเภท nano ~/.ssh/known_hosts และกด Enter.
- ค้นหาหมายเลขบรรทัดที่ระบุไว้ใน error message
- ลบบรรทัดนั้น จากนั้นกด Ctrl + X และ Y เพื่อบันทึก
คุณยังสามารถใช้ Vim (vim ~/.ssh/known_hosts) หากคุณคุ้นเคยกับมัน

คำเตือนก่อนปิดการตรวจสอบ
คุณสามารถบังคับให้ SSH เชื่อมต่อโดยข้ามการตรวจสอบได้ แต่วิธีนี้มีความเสี่ยง เพราะจะปิดการป้องกัน man-in-the-middle attack
ใช้วิธีนี้เฉพาะการทดสอบในเครื่องบนเครือข่ายที่เชื่อถือได้เท่านั้น สำหรับ macOS และ Linux ให้พิมพ์คำสั่งนี้:
ssh -o StrictHostKeyChecking=no -o UserKnownHostsFile=/dev/null [email protected]
ถ้าคุณใช้ Windows Unix path จะใช้ไม่ได้ คุณต้องใช้ NUL เพื่อให้การข้ามการตรวจสอบทำงานได้:
ssh -o StrictHostKeyChecking=no -o UserKnownHostsFile=NUL [email protected]
อย่าใช้คำสั่งเหล่านี้บนการเชื่อมต่อสาธารณะหรือ server จริง
การแก้ปัญหา key ไม่ตรงกันเป็นงานดูแลระบบปกติ แต่คุณทำได้มากกว่านั้นเพื่อเพิ่มความปลอดภัยให้การเชื่อมต่อ บอทมักโจมตี port 22 ซึ่งเป็นค่าเริ่มต้นด้วย brute-force attack คุณหลีกเลี่ยงสัญญาณรบกวนพื้นหลังส่วนใหญ่นี้ได้ด้วยการ เปลี่ยน port ของ SSH ใน Linux ให้เป็นค่าที่คาดเดาได้ยากขึ้น

อย่าใช้วิธีนี้กับ production server หรือบนเครือข่ายที่ไม่น่าเชื่อถือ
วิธีป้องกันข้อความ "Remote Host Identification Has Changed" ในครั้งถัดไป
แม้จะไม่สามารถป้องกัน host key เปลี่ยนแปลงโดยชอบธรรมได้ทุกกรณี แต่คุณลดความวุ่นวายและรักษาแนวปฏิบัติด้านความปลอดภัยที่ดีได้
คู่มืออ้างอิงฉบับย่อ
| บทบาทของคุณ | กลยุทธ์หลัก |
| ผู้ดูแลระบบ | สำรอง key, บันทึกการเปลี่ยนแปลง, ใช้ certificate และหมุนเวียน key อย่างสม่ำเสมอ |
| ผู้ใช้ทั่วไป | จัดทำ inventory, ยืนยันผ่านช่องทางที่ปลอดภัย และติดตามตรวจสอบ log |
| สภาพแวดล้อมคลาউด์
ผู้ใช้งาน |
ใช้ชื่อ DNS, ใช้เครื่องมือของ provider และนำ infrastructure as code มาใช้ |

สำหรับผู้ดูแลระบบ
สำรอง Host Key: บันทึก key จาก /etc/ssh/ ก่อนติดตั้ง OS ใหม่ จากนั้นกู้คืน key เดิมเพื่อไม่ให้ผู้ใช้ได้รับคำเตือน
บันทึกการเปลี่ยนแปลงที่วางแผนไว้: แจ้งผู้ใช้ก่อนเปลี่ยน key และแชร์ fingerprint ใหม่ผ่านช่องทางที่ปลอดภัย เพื่อให้พวกเขายืนยันการเชื่อมต่อได้
ใช้ใบรับรอง SSH: ทีมขนาดใหญ่ควรใช้ Certificate Authority กลาง วิธีนี้จะเซ็นรับรอง host key และไม่ต้องยืนยันตัวตนเองทีละเครื่องอีกต่อไป
ตั้งรอบการหมุนเวียน Key: วางแผนการเปลี่ยน host key ล่วงหน้า การอัปเดตที่มีกำหนดชัดเจนจัดการได้ง่ายกว่าการเปลี่ยนแปลงที่เกิดขึ้นโดยไม่แจ้งเตือน
สำหรับผู้ใช้ทั่วไป
บำรุงรักษาสินค้าคงคลัง: เก็บบันทึก fingerprint ของเซิร์ฟเวอร์ไว้เอง หรือใช้เอกสารของทีมที่จัดเก็บอย่างปลอดภัย
ยืนยันผ่านช่องทางอื่น: ตรวจสอบ key กับแหล่งที่เชื่อถือได้ เช่น cloud console ไม่ใช่ผ่านข้อความทั่วไป
ตรวจสอบบันทึก: ตรวจสอบ log ของ SSH ในเครื่องเป็นประจำ เพื่อหารูปแบบการเชื่อมต่อที่ผิดปกติหรือข้อผิดพลาดที่เกิดซ้ำ
ใช้ Config Management: ใช้ไฟล์ config ของ SSH เพื่อรองรับ dev environment ที่เปลี่ยนแปลงบ่อย โดยไม่ต้องลดระดับความปลอดภัย
สำหรับ Cloud Environment แบบ Dynamic
ใช้ชื่อ DNS: เชื่อมต่อด้วย hostname แทน IP เพื่อให้การตั้งค่ายังคงสม่ำเสมอเมื่อ IP เปลี่ยน
ใช้เครื่องมือของ Cloud Provider: ดึง fingerprint ปัจจุบันจาก console ของ provider และยืนยัน key กับเครื่องมือเหล่านี้ก่อนยอมรับการเปลี่ยนแปลง
Infrastructure as Code ในรูปแบบของ Code Or more naturally in Thai context: โครงสร้างพื้นฐานเป็น Code Or keeping the English term as it's a technical concept: Infrastructure as Code ตรวจสอบ key อัตโนมัติด้วยเครื่องมืออย่าง Terraform สำหรับการตั้งค่าขั้นสูง คุณยังสามารถ ใช้ SSH SOCKS5 proxies.
โฮสต์ป้องกัน: ตั้งค่า jump server ที่มี key คงที่ เพื่อใช้เป็นจุดเข้าถึงที่ปลอดภัยสำหรับโครงสร้างพื้นฐาน dynamic ของคุณ
สรุป
คำเตือน "Warning: Remote Host Identification Has Changed" เป็นฟีเจอร์ด้านความปลอดภัยที่สำคัญของ SSH ไม่ใช่ข้อบกพร่องที่ควรมองข้าม แม้คำเตือนนี้มักเกิดจากสาเหตุปกติ เช่น การบำรุงรักษาเซิร์ฟเวอร์หรือการเปลี่ยนการตั้งค่า แต่มีบทบาทสำคัญในการป้องกันคุณจาก man-in-the-middle attack และการเข้าถึงโดยไม่ได้รับอนุญาต
เมื่อพบคำเตือนนี้ ให้ตรวจสอบสาเหตุก่อนดำเนินการต่อ ในกรณีส่วนใหญ่วิธีแก้ไขไม่ซับซ้อน: ลบ host key เดิมตามวิธีที่เหมาะกับระบบปฏิบัติการของคุณ แล้วยอมรับ key ใหม่เมื่อเชื่อมต่อครั้งถัดไป
การเข้าใจการทำงานของ SSH host key และปฏิบัติตามแนวทางที่ดี จะช่วยให้คุณรักษาทั้งความปลอดภัยและความสะดวกในการทำงาน remote access ได้พร้อมกัน สำหรับข้อมูลเพิ่มเติมเกี่ยวกับการถ่ายโอนไฟล์อย่างปลอดภัย ดูได้ที่ การคัดลอกไฟล์ผ่าน SSH.