ลด 50% ทุกแพ็กเกจ เวลาจำกัด เริ่มต้นที่ $2.48/mo
10 นาทีที่เหลือ
ความปลอดภัยและเครือข่าย

คำเตือน: Remote Host Identification Has Changed และวิธีแก้ไข

เรกซา ไซรัส By เรกซา ไซรัส อ่าน 10 นาที อัปเดตเมื่อ 71 วันที่แล้ว
หน้าต่าง Terminal แสดงข้อความเตือน SSH เกี่ยวกับการเปลี่ยนแปลง Remote Host Identification พร้อมหัวข้อ Fix Guide และแบรนด์ Cloudzy บนพื้นหลังสีเขียวเทาเข้ม

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 host key เปลี่ยน ได้แก่ การอัปเกรด OS, การสร้างเซิร์ฟเวอร์ใหม่, การกู้คืนจากข้อมูลสำรอง, การย้ายจากเครื่องจริงสู่เครื่องเสมือน และการรีเซ็ตการตั้งค่า SSH
การเปลี่ยนแปลงที่เกี่ยวข้องกับเซิร์ฟเวอร์:

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

การเปลี่ยนแปลงการตั้งค่าเครือข่าย:

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

ไดอะแกรมเครือข่ายแสดงให้เห็น DHCP server ที่กำหนด IP แบบไดนามิกให้กับเครื่องเสมือน โดยการปลดระวางและออก IP ใหม่อาจทำให้เกิดความขัดแย้งของ host key ใน SSH

การจัดการ Key:

  • ผู้ดูแลระบบสร้าง host key ใหม่ด้วยตนเองเพื่อความปลอดภัย
  • ซอฟต์แวร์เซิร์ฟเวอร์ SSH ถูกติดตั้งใหม่
  • นโยบายความปลอดภัยกำหนดให้หมุนเวียน key

สิ่งสำคัญที่ต้องเข้าใจคือการเปลี่ยนรหัสผ่านของผู้ใช้ไม่มีผลต่อ host key เนื่องจากทั้งสองเป็นกลไกการยืนยันตัวตนที่แยกจากกัน host key จะเปลี่ยนเฉพาะเมื่อมีการแก้ไขตัวเซิร์ฟเวอร์เองหรือการตั้งค่า SSH เท่านั้น

เมื่อใดที่ควรให้ความสำคัญกับคำเตือนนี้

การเปลี่ยน host key ส่วนใหญ่มีสาเหตุที่ชัดเจน แต่บางกรณีอาจเป็นสัญญาณของภัยคุกคามจริง ควรตรวจสอบหากพบสิ่งต่อไปนี้:

  • คุณไม่ได้แก้ไขเซิร์ฟเวอร์และไม่ทราบว่ามีการบำรุงรักษาตามกำหนด
  • คุณไม่สามารถยืนยันสาเหตุของการเปลี่ยน key กับผู้ดูแลเซิร์ฟเวอร์ได้
  • มีการเข้าถึงเซิร์ฟเวอร์ผ่านเครือข่ายสาธารณะหรือการเชื่อมต่อที่ไม่น่าเชื่อถือ
  • คุณกำลังเชื่อมต่อกับระบบ production หรือเซิร์ฟเวอร์ที่มีข้อมูลสำคัญ


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

ข้อผิดพลาดของผู้ใช้ และ social engineering คิดเป็น 68% ของการละเมิดความปลอดภัย ซึ่งทำให้การเฝ้าระวังเป็นสิ่งสำคัญ คุณสามารถป้องกันระบบได้มากขึ้นโดยศึกษาเกี่ยวกับ การป้องกันการโจมตีแบบ brute-force

สถิติล่าสุดจาก IBM ระบุว่าต้นทุนเฉลี่ยทั่วโลกของการ การรั่วไหลข้อมูล อยู่ที่ 4.44 ล้านดอลลาร์ในปี 2025 โดยใช้เวลาตรวจพบเฉลี่ยแปดเดือน นี่คือเหตุผลที่กลไกการตรวจสอบ host key ของ SSH มีความสำคัญ และทำไมคุณไม่ควรเพิกเฉยต่อคำเตือนเหล่านี้โดยไม่ตรวจสอบ

วิธีตรวจสอบว่าคำเตือนนี้ปลอดภัยหรือไม่

ก่อนดำเนินการแก้ไข ให้ทำขั้นตอนการตรวจสอบเหล่านี้ก่อน:

ผังงานแสดงวิธีการตรวจสอบห้าวิธีเพื่อยืนยันการเปลี่ยน host key ของ SSH ที่ถูกต้อง ครอบคลุมการปรึกษาทีมงาน การติดต่อผู้ให้บริการ hosting ช่องทางที่ปลอดภัย และการเปรียบเทียบ fingerprint

  1. ตรวจสอบกับทีมของคุณ: หากคุณใช้งานเซิร์ฟเวอร์ร่วมกัน ให้สอบถามเพื่อนร่วมงานว่ามีการเปลี่ยนแปลงใดเกิดขึ้นหรือไม่
  2. ตรวจสอบ log ของเซิร์ฟเวอร์: ตรวจสอบบันทึกการบำรุงรักษาหรือ change log เพื่อดูกิจกรรมล่าสุด
  3. ติดต่อผู้ให้บริการโฮสติ้งของคุณ: หากใช้บริการคลาวด์ ให้ตรวจสอบว่ามีการบำรุงรักษาระบบเกิดขึ้นหรือไม่
  4. ใช้ช่องทางที่ปลอดภัย: หากเป็นไปได้ ให้เชื่อมต่อผ่านเครือข่ายที่เชื่อถือได้เพื่อยืนยัน fingerprint
  5. เปรียบเทียบลายนิ้วมือ: ผู้ให้บริการโฮสติ้งบางรายแสดง 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

  1. เปิด terminal ของคุณ
  2. รันคำสั่งนี้ (แทนที่ 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 เพื่อบันทึก

หน้าต่าง terminal แสดง nano text editor ที่เปิดไฟล์ known_hosts พร้อมไฮไลต์บรรทัดที่ต้องการลบ โดยมีขั้นตอนการดำเนินการและวิธีบันทึกไฟล์แสดงอยู่ด้วย

วิธีแก้ไขสำหรับ 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 ใช้งานได้เช่นกัน

หากต้องการแก้ไขไฟล์ด้วยตนเองแทน:

  1. กด Windows Key + R.
  2. ประเภท %USERPROFILE%\.ssh และกด Enter.
  3. เปิด known_hosts ไฟล์ด้วย Notepad
  4. ลบบรรทัดที่ทำให้เกิด error แล้วบันทึกไฟล์

สำหรับการจัดการ key อย่างถูกต้อง ดูคู่มือของเราเรื่อง การสร้าง SSH keys ใน Windows.

ตัวเลือกที่ 2: ใช้ PuTTY

PuTTY เก็บ key ไว้ใน Windows Registry แทนที่จะเป็นไฟล์

  1. เปิด Registry Editor (กด Windows Key + R, พิมพ์ regeditและกด Enter).
  2. ไปที่: HKEY_CURRENT_USER\Software\SimonTatham\PuTTY\SshHostKeys\
  3. ค้นหา entry ที่ตรงกับ hostname หรือ IP ของเซิร์ฟเวอร์
  4. คลิกขวาแล้วเลือก ลบ.

Windows PowerShell command ที่ลบ SSH host key พร้อม File Explorer แสดงไฟล์ known_hosts ที่อัปเดตแล้ว และ PuTTY Registry Editor แสดง dialog ยืนยันการลบ host key

วิธีแก้ไขสำหรับ Linux

ค่า ssh-keygen คำสั่งที่เราครอบคลุมไปแล้ว วิธีที่ 1 เป็นวิธีมาตรฐานในการแก้ไขปัญหานี้บน Linux รวดเร็วและรองรับได้โดยตรง

แก้ไขด้วยตนเอง

หากต้องการดูเนื้อหาของไฟล์ สามารถเปิดแก้ไขด้วย text editor อย่าง Nano ได้

  1. เปิด terminal ของคุณ
  2. ประเภท nano ~/.ssh/known_hosts และกด Enter.
  3. ค้นหาหมายเลขบรรทัดที่ระบุไว้ใน error message
  4. ลบบรรทัดนั้น จากนั้นกด Ctrl + X และ Y เพื่อบันทึก

คุณยังสามารถใช้ Vim (vim ~/.ssh/known_hosts) หากคุณคุ้นเคยกับมัน

หน้าต่าง terminal แสดงคำสั่ง ssh-keygen สำหรับลบ host key ของ SSH ด้วยชื่อ hostname และ IP address พร้อมข้อความยืนยันและตัวอย่างไฟล์ 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 ให้เป็นค่าที่คาดเดาได้ยากขึ้น

แผนภาพแสดง man-in-the-middle attack บน SSH: ผู้โจมตีคั่นกลางการเชื่อมต่อระหว่าง client กับ server พร้อมเปรียบเทียบ key ของผู้โจมตีและ key ของ server และเน้นความเสียหายจากการขโมยข้อมูลและความสูญเสียทางการเงิน

อย่าใช้วิธีนี้กับ production server หรือบนเครือข่ายที่ไม่น่าเชื่อถือ

วิธีป้องกันข้อความ "Remote Host Identification Has Changed" ในครั้งถัดไป

แม้จะไม่สามารถป้องกัน host key เปลี่ยนแปลงโดยชอบธรรมได้ทุกกรณี แต่คุณลดความวุ่นวายและรักษาแนวปฏิบัติด้านความปลอดภัยที่ดีได้

คู่มืออ้างอิงฉบับย่อ

บทบาทของคุณ กลยุทธ์หลัก
ผู้ดูแลระบบ สำรอง key, บันทึกการเปลี่ยนแปลง, ใช้ certificate และหมุนเวียน key อย่างสม่ำเสมอ
ผู้ใช้ทั่วไป จัดทำ inventory, ยืนยันผ่านช่องทางที่ปลอดภัย และติดตามตรวจสอบ log
สภาพแวดล้อมคลาউด์ 

ผู้ใช้งาน

ใช้ชื่อ DNS, ใช้เครื่องมือของ provider และนำ infrastructure as code มาใช้

อินโฟกราฟิกแสดงแนวปฏิบัติที่ดีในการจัดการ SSH key: ใช้ SSH certificate, ชื่อ DNS, Infrastructure as Code, สำรอง host key, บันทึกการเปลี่ยนแปลง และพิจารณาใช้ bastion host

สำหรับผู้ดูแลระบบ

สำรอง 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.

 

คำถามที่พบบ่อย

ควรให้ความสำคัญกับคำเตือน Remote Host Identification Has Changed หรือไม่?

ควรให้ความสำคัญ เพราะหมายความว่า identity ของเซิร์ฟเวอร์เปลี่ยนไป ซึ่งอาจเป็นสัญญาณของ man-in-the-middle attack หรือเพียงแค่การบำรุงรักษาตามปกติก็ได้ ยืนยันการเปลี่ยนแปลงกับ admin หรือ provider เสมอก่อนยอมรับ key ใหม่

อะไรทำให้เกิดคำเตือน Remote Host Identification Has Changed?

คำเตือนนี้เกิดขึ้นเมื่อ fingerprint ปัจจุบันของเซิร์ฟเวอร์ไม่ตรงกับที่บันทึกไว้ในไฟล์ known_hosts สาเหตุที่พบบ่อย ได้แก่ การติดตั้ง OS ใหม่ การเปลี่ยน IP หรือการรีเซ็ตการตั้งค่า SSH ในบางกรณีที่พบได้น้อย อาจบ่งชี้ว่ามีการโจมตีแบบ man-in-the-middle อยู่จริง

ข้อผิดพลาดนี้เกิดขึ้นบนระบบปฏิบัติการต่างกันได้ไหม?

ได้ คำเตือนนี้ส่งผลต่อทุกระบบปฏิบัติการที่ใช้ SSH รวมถึง Windows, macOS และ Linux ซึ่งเป็นกลไกการตรวจสอบความปลอดภัยของโปรโตคอล SSH วิธีแก้ไขอาจแตกต่างกันตามแต่ละแพลตฟอร์ม แต่สาเหตุที่ทำให้เกิดการแจ้งเตือนนั้นเหมือนกันทุกระบบ

จะรู้ได้อย่างไรว่า Host Key ที่เปลี่ยนไปนั้นถูกต้องหรือเป็นการโจมตี?

ให้ตรวจสอบว่ามีการบำรุงรักษา อัปเดต OS หรือเปลี่ยน IP เกิดขึ้นเร็ว ๆ นี้หรือไม่ จากนั้นต้องยืนยัน fingerprint ใหม่กับแหล่งที่เชื่อถือได้ เช่น คอนโซลของผู้ให้บริการ cloud หรือรับการยืนยันจากผู้ดูแลระบบก่อนเชื่อมต่อ

การปิดการตรวจสอบ Host Key จะทำให้ใช้ SSH สะดวกขึ้นไหม?

สะดวกขึ้นจริง แต่แลกมาด้วยความปลอดภัย การปิดการตรวจสอบทำให้ไม่มีอะไรป้องกันการโจมตีแบบ man-in-the-middle และทำให้การเชื่อมต่อมีความเสี่ยง ควรใช้การตั้งค่านี้เฉพาะในสภาพแวดล้อมทดสอบที่แยกออกจากระบบจริงเท่านั้น ห้ามใช้กับเซิร์ฟเวอร์ production หรือเครือข่ายสาธารณะที่เกี่ยวข้องกับข้อมูลสำคัญ

ควรเปลี่ยน Host Key ของ SSH บ่อยแค่ไหน?

โดยทั่วไปแล้ว Host Key ไม่จำเป็นต้องหมุนเวียนตามรอบเวลา ควรเปลี่ยนเมื่อมีการสร้างเซิร์ฟเวอร์ใหม่ ติดตั้ง OS ใหม่ หรือเกิดปัญหาความปลอดภัยเท่านั้น การเปลี่ยนบ่อยเกินไปจะสร้างความยุ่งยากให้ผู้ใช้ ดังนั้นให้เน้นความเสถียรและสื่อสารให้ชัดเจนเมื่อจำเป็นต้องอัปเดต

แชร์

บทความอื่นจากบล็อก

อ่านต่อ

ภาพประกอบสำหรับ Cloudzy ในคู่มือ MikroTik L2TP VPN แสดงแล็ปท็อปที่เชื่อมต่อกับ Server Rack ผ่านอุโมงค์ดิจิทัลสีฟ้าและทองพร้อมไอคอนโล่ป้องกัน
ความปลอดภัยและเครือข่าย

การตั้งค่า MikroTik L2TP VPN (พร้อม IPsec): คู่มือ RouterOS (2026)

ในการตั้งค่า MikroTik L2TP VPN นี้ L2TP ทำหน้าที่สร้าง Tunnel ส่วน IPsec ดูแลการเข้ารหัสและความสมบูรณ์ของข้อมูล การใช้งานร่วมกันช่วยให้รองรับ Native Client ได้โดยไม่ต้องพึ่งพาซอฟต์แวร์ของบุคคลที่สาม

เรกซา ไซรัสเรกซา ไซรัส อ่าน 9 นาที
ภาพประกอบคู่มือแก้ปัญหา DNS พร้อมสัญลักษณ์เตือนและเซิร์ฟเวอร์สีฟ้าบนพื้นหลังมืด สำหรับข้อผิดพลาด Name Resolution ของ Linux
ความปลอดภัยและเครือข่าย

Temporary Failure in Name Resolution คืออะไร และแก้ไขอย่างไร?

ขณะใช้งาน Linux คุณอาจพบข้อผิดพลาด Temporary Failure in Name Resolution เมื่อพยายามเปิดเว็บไซต์ อัปเดตแพ็กเกจ หรือรันงานที่ต้องใช้การเชื่อมต่ออินเทอร์เน็ต

เรกซา ไซรัสเรกซา ไซรัส อ่าน 12 นาที
วิธีชี้โดเมนไปยัง VPS: คู่มือฉบับย่อ
ความปลอดภัยและเครือข่าย

วิธีชี้โดเมนไปยัง VPS: คู่มือฉบับย่อ

การชี้โดเมนไปยัง Virtual Private Server เป็นสิ่งจำเป็นสำหรับการโฮสต์เว็บไซต์และแอปพลิเคชัน คู่มือนี้ครอบคลุมทุกสิ่งที่คุณต้องรู้เกี่ยวกับการเชื่อมต่อโดเมนของคุณกับ

เรกซา ไซรัสเรกซา ไซรัส อ่าน 16 นาที

พร้อม Deploy แล้วหรือยัง? เริ่มต้นที่ $2.48/เดือน

Cloud อิสระ ให้บริการมาตั้งแต่ปี 2008. AMD EPYC, NVMe, 40 Gbps. คืนเงินภายใน 14 วัน