SSH: “REMOTE HOST IDENTIFICATION HAS CHANGED” — Giải thích & hướng dẫn chi tiết (trong trường hợp bạn đổi VPS/datacenter nhưng vẫn giữ IP)

Thông báo bạn gặp là SSH client cảnh báo host key (fingerprint) của server thay đổi so với lần trước. Trong trường hợp bạn chuyển VPS sang datacenter khác nhưng vẫn giữ IP, đây thường là kết quả bình thường (server mới có SSH host key mới). Nếu bạn chắc đó là server của mình → chỉ cần xóa entry cũ trong known_hosts và kết nối lại (hoặc copy host key cũ sang server mới để giữ fingerprint). Nếu bạn không chắc → dừng lại và xác minh, vì đó cũng có thể là dấu hiệu MITM.


1. Lỗi này nghĩa là gì?

Khi SSH client kết nối lần đầu với một host, nó lưu host key (public key của SSH daemon) vào ~/.ssh/known_hosts. Lần sau khi bạn kết nối, client kiểm tra key này. Nếu key trên server thay đổi, SSH đưa ra cảnh báo:

@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@
@    WARNING: REMOTE HOST IDENTIFICATION HAS CHANGED!     @
@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@
...
Offending RSA key in /Users/vnengineer/.ssh/known_hosts:79
Host key for [103.162.31.231]:26266 has changed and you have requested strict checking.
Host key verification failed.

Nó có 2 ý chính:

  • An toàn: Có thể có tấn công “man-in-the-middle”.
  • Hoặc bình thường: Server đã được rebuild / đổi host key / chuyển máy mới (như bạn đã làm).

2. Tại sao lỗi này xuất hiện khi bạn đổi VPS/datacenter nhưng giữ IP?

Khi chuyển VPS, server mới thường tạo host key mới (SSH daemon tạo key khi chưa có). Vì client vẫn lưu fingerprint cũ cho IP đó, nên khi gặp fingerprint mới, client nghĩ có sự thay đổi đáng ngờ → báo lỗi.

Kết luận: Nếu bạn chắc chắn mình đã di chuyển và IP vẫn là của bạn → không phải bị hack, chỉ cần cập nhật known_hosts.


3. Cách xử lý an toàn (step-by-step)

A — Xác minh trước khi làm gì

  1. Xác nhận với nhà cung cấp / control panel rằng bạn thực sự đã chuyển VPS và IP đó bây giờ trỏ đến server mới.
  2. Nếu có SSH console (web console) hoặc access qua control panel mới — đăng nhập và kiểm tra /etc/ssh/ host keys.

Nếu xác nhận là đúng, tiếp tục các bước dưới.

B — Xóa entry cũ (an toàn, đơn giản)

Dùng lệnh (phù hợp với port 26266 như log của bạn):

ssh-keygen -R '[103.162.31.231]:26266'

Sau đó kết nối lại:

ssh -p 26266 [email protected]

Khi thấy:

The authenticity of host '[103.162.31.231]:26266' can't be established.
ED25519 key fingerprint is SHA256:...
Are you sure you want to continue connecting (yes/no)?

yes để chấp nhận và SSH sẽ ghi host key mới vào ~/.ssh/known_hosts.

Lưu ý: dấu ngoặc vuông và port là cần thiết khi host dùng port khác 22.

C — Xóa bằng cách thủ công (nếu bạn muốn)

Mở file known_hosts và xóa dòng 79 (theo thông báo):

nl -ba ~/.ssh/known_hosts | sed -n '70,85p'   # xem vùng gần dòng 79
sed -i '79d' ~/.ssh/known_hosts                 # xóa dòng 79

Hoặc tìm theo host:

ssh-keygen -F '[103.162.31.231]:26266'   # tìm entry hiện tại

4. Kiểm tra fingerprint trước khi chấp nhận (khuyến nghị)

Bạn nên so sánh fingerprint do server báo với fingerprint thực tế trên server (hoặc do provider cung cấp) trước khi chấp nhận.

Từ server (nếu có console hoặc access):

# ví dụ kiểm tra ED25519 pubkey fingerprint (hiển thị SHA256)
sudo ssh-keygen -lf /etc/ssh/ssh_host_ed25519_key.pub -E sha256
# hoặc RSA
sudo ssh-keygen -lf /etc/ssh/ssh_host_rsa_key.pub -E sha256

Từ client (lấy key “tạm” từ host rồi kiểm tra):

ssh-keyscan -p 26266 -t ed25519 103.162.31.231 > /tmp/remote_key.pub
ssh-keygen -lf /tmp/remote_key.pub -E sha256
# so sánh output với fingerprint server cung cấp

Nếu fingerprints khớp → an toàn để chấp nhận.


5. Giữ fingerprint cũ khi di chuyển server (nếu muốn tránh cảnh báo)

Nếu bạn muốn IP giữ nguyên và fingerprint không đổi, cách làm là copy host key (khóa host, bao gồm private key) từ server cũ sang server mới trước khi chuyển IP.

Cảnh báo bảo mật: host private key là dữ liệu nhạy cảm — chỉ làm điều này nếu bạn hoàn toàn tin tưởng kênh truyền và biết mình làm gì.

Ví dụ quy trình (đã có quyền root trên cả hai server)

Trên server cũ:

sudo tar -czf /root/ssh-host-keys.tgz -C /etc/ssh ssh_host_*
# copy sang server mới (ví dụ qua scp)
scp /root/ssh-host-keys.tgz root@NEW-IP:/root/

Trên server mới:

# dừng sshd trước khi thay key
sudo systemctl stop sshd || sudo service ssh stop

sudo tar -xzf /root/ssh-host-keys.tgz -C /etc/ssh

# đặt quyền chính xác
sudo chown root:root /etc/ssh/ssh_host_*
sudo chmod 600 /etc/ssh/ssh_host_*_key
sudo chmod 644 /etc/ssh/ssh_host_*.pub

# khởi động lại sshd
sudo systemctl start sshd || sudo service ssh start

Sau khi copy, host key trên server mới sẽ giống server cũ → client không thấy thay đổi.


6. Các tùy chọn khác (và cảnh báo)

  • ssh-keyscan >> known_hosts: bạn có thể lấy key mới và append vào ~/.ssh/known_hosts bằng ssh-keyscan, nhưng chỉ append sau khi đã verify fingerprint. ssh-keyscan -p 26266 103.162.31.231 >> ~/.ssh/known_hosts
  • Tắt kiểm tra chặt chẽ (không khuyến nghị): ssh -o StrictHostKeyChecking=no -o UserKnownHostsFile=/dev/null -p 26266 [email protected] Đây bất an — chỉ dùng tạm cho script trong mạng tin cậy, không dùng cho truy cập remote bình thường.
  • Sử dụng SSHFP (DNS) records: nếu bạn quản lý DNS, có thể publish SSHFP records cho host key — khi DNSSEC bật thì client có thể kiểm tra an toàn hơn. (Thiết lập DNS và SSHFP cần cấu hình DNS đúng — bài này tạm không đi sâu kỹ.)

7. Khi có nhiều client cần cập nhật (scale)

Nếu nhiều máy client (hoặc người dùng) sẽ kết nối sau chuyển đổi:

  • Thông báo cho họ trước.
  • Gửi fingerprint mới để họ tự verify trước khi chấp nhận.
  • Hoặc dùng Ansible / config management để cập nhật known_hosts trên các client.
    Ví dụ Ansible module known_hosts có thể set key chính xác trên nhiều máy.

8. Checklist nhanh — Tôi nên làm gì ngay bây giờ?

  1. Xác nhận việc di chuyển VPS và IP vẫn thuộc quản lý bạn.
  2. Nếu có console của host mới: kiểm tra /etc/ssh/ssh_host_* fingerprint và so sánh.
  3. Trên máy local, chạy: ssh-keygen -R '[103.162.31.231]:26266' ssh -p 26266 [email protected] (nhập yes khi được hỏi sau khi bạn đã verify).
  4. Nếu muốn tránh cảnh báo cho tương lai: sao chép host keys từ server cũ sang server mới (bảo mật khi truyền file).
  5. Đừng sử dụng StrictHostKeyChecking=no làm mặc định.

9. Ví dụ thực tế (dùng IP/port từ log của bạn)

Xóa entry cũ:

ssh-keygen -R '[103.162.31.231]:26266'

Lấy fingerprint tạm từ host để so sánh:

ssh-keyscan -p 26266 -t ed25519 103.162.31.231 > /tmp/remote_key.pub
ssh-keygen -lf /tmp/remote_key.pub -E sha256

(so sánh với fingerprint do server hoặc nhà cung cấp báo)


10. Kết luận & lời khuyên

  • Thông báo bạn gặp thường là bình thường sau khi rebuild/di chuyển server — không vội hoảng.
  • Luôn verify fingerprint nếu có thể.
  • Nếu bạn di chuyển VPS thường xuyên, cân nhắc backup host keys và sử dụng phương pháp tự động update (CM tools) hoặc SSHFP + DNSSEC để giảm rủi ro.