คำเตือน: Remote Host Identification เปลี่ยนแปลง และวิธีแก้ไข

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 ที่ใช้งาน

Infographic showing server changes that modify SSH host keys, including OS upgrades, server rebuilds, backup restoration, physical to virtual migration, and SSH configuration resets.
การเปลี่ยนแปลงที่เกี่ยวข้องกับเซิร์ฟเวอร์:

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

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

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

Network diagram showing a DHCP server assigning dynamic IP addresses to virtual machines, with server decommissioning and reissuing causing SSH host key conflicts.

การจัดการ Key:

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

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

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

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

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

Split screen comparing legitimate SSH changes shown in green with security threat scenarios in red, featuring a hooded figure representing man-in-the-middle attacks.
การโจมตีแบบ man-in-the-middle แม้จะพบไม่บ่อย แต่ก็เกิดขึ้นได้จริง ในการโจมตีประเภทนี้ ผู้โจมตีจะแทรกตัวอยู่ระหว่างคอมพิวเตอร์ของคุณกับเซิร์ฟเวอร์จริง เพื่อดักจับการรับส่งข้อมูลทั้งหมด

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

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

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

ก่อนดำเนินการแก้ปัญหา ทำตามขั้นตอนการตรวจสอบเหล่านี้

Flowchart showing five verification methods for confirming legitimate SSH host key changes, including team consultation, hosting provider contact, secure channels, and fingerprint comparison.

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

หากคุณมั่นใจว่าการเปลี่ยนแปลง key นั้นถูกต้อง ก็สามารถลบ key เก่าและยอมรับ key ใหม่ได้อย่างปลอดภัย

ถ้าต้องการหลีกเลี่ยงปัญหา IP เปลี่ยนแบบไม่คาดฝัน หรือ host key ขัดแย้งกัน การเลือก infrastructure ที่เหมาะสมถือเป็นเรื่องสำคัญ

Cloudzy มอบให้ การโฮสติง SSH VPS พร้อม static IP เฉพาะ คุณรันบนโปรเซสเซอร์ AMD Ryzen 9 พร้อมพื้นที่จัดเก็บ NVMe เพื่อการรันคำสั่งทันที เครือข่ายของเราเข้าถึง 40 Gbps ทั่วทั้ง 13 รีเจียน นอกจากนี้เรารวมการป้องกัน DDoS ฟรีเพื่อรักษาความปลอดภัยการเชื่อมต่อของคุณ

วิธีแก้ปัญหา “Remote Host Identification Has Changed” Error

วิธีแก้ไขนั้นง่ายมาก: ลบ 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 เพื่อบันทึก

macOS terminal window showing nano text editor open with known_hosts file, highlighting line to delete with numbered steps and save instructions displayed.

ทางแก้สำหรับ 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 จัดเก็บกุญแจใน Windows Registry แทนที่จะเป็นไฟล์

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

Windows PowerShell command removing SSH host key with File Explorer showing updated known_hosts file, and PuTTY Registry Editor displaying delete confirmation dialog for host key.

ทางแก้สำหรับ Linux

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

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

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

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

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

Linux terminal showing ssh-keygen commands to remove SSH host keys by hostname and IP address, with success confirmation and known_hosts file examples.
คำเตือนก่อนปิดการตรวจสอบ

คุณสามารถบังคับให้ 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]

อย่ารัน overrides เหล่านี้บนการเชื่อมต่อสาธารณะหรือเซิร์ฟเวอร์ live

การแก้ปัญหา key ไม่ตรงกันเป็นงานดูแลระบบปกติ แต่คุณทำได้มากกว่านั้นเพื่อเพิ่มความปลอดภัยให้การเชื่อมต่อ บอทมักโจมตี port 22 ซึ่งเป็นค่าเริ่มต้นด้วย brute-force attack คุณหลีกเลี่ยงสัญญาณรบกวนพื้นหลังส่วนใหญ่นี้ได้ด้วยการ เปลี่ยน port ของ SSH ใน Linux ให้เป็นค่าที่คาดเดาได้ยากขึ้น

Diagram of a man-in-the-middle attack on SSH: attacker intercepting client-server connection, attacker key vs server key, data theft and financial loss highlighted.

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

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

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

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

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

Infographic showing SSH key management best practices: use SSH certificates, DNS names, Infrastructure as Code, back up host keys, document changes, and consider bastion hosts.

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

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