Sửa lỗi SSH Permission denied (publickey) và Host Key Changed an toàn
Quy trình kiểm tra đúng user, private key, authorized_keys, quyền file và xác minh host key trước khi xóa known_hosts.
Bài viết bởi Phạm Minh Thiện
Front-end Developer, trực tiếp thực hành Next.js, NestJS, Docker, Nginx và VPS Ubuntu.
Bài viết đã được kiểm tra lại ngày 21/7/2026.
Mục lục bài viết
Hai lỗi SSH rất dễ bị xử lý nhầm:
Permission denied (publickey)
và:
WARNING: REMOTE HOST IDENTIFICATION HAS CHANGED!
Lỗi thứ nhất liên quan đến việc server không chấp nhận phương thức xác thực bằng khóa của bạn. Lỗi thứ hai liên quan đến danh tính của server đã khác so với khóa lưu trong known_hosts. Đặc biệt với lỗi host key, không nên xóa cảnh báo ngay mà chưa xác minh, vì nó cũng có thể xuất hiện khi bạn kết nối nhầm máy hoặc có nguy cơ giả mạo kết nối.

Phần A — Sửa Permission denied (publickey)
1. Kiểm tra đúng username
Cùng một VPS nhưng image khác nhau có thể dùng username mặc định khác nhau, ví dụ ubuntu, root, debian hoặc user do bạn tự tạo.
ssh ubuntu@203.0.113.10
Nếu public key nằm trong /home/thien/.ssh/authorized_keys nhưng bạn đăng nhập bằng user ubuntu, server sẽ kiểm tra file của ubuntu, không phải của thien.
Thử user đúng:
ssh thien@203.0.113.10
Không nên thử hàng chục username ngẫu nhiên trên máy không thuộc quyền quản lý của bạn. Với VPS của mình, hãy xem thông tin image hoặc dùng console của nhà cung cấp để xác nhận.
2. Chỉ định đúng private key
ssh -i ~/.ssh/deployeasy_ed25519 thien@203.0.113.10
Kiểm tra file:
ls -la ~/.ssh
ssh-keygen -lf ~/.ssh/deployeasy_ed25519.pub
Public key có thể chia sẻ với server. Private key phải giữ kín và không đưa lên GitHub, gửi trong chat công khai hoặc chụp nguyên nội dung lên bài viết.
Trên Linux/macOS, đặt quyền private key:
chmod 600 ~/.ssh/deployeasy_ed25519
3. Dùng chế độ verbose để biết client gửi key nào
ssh -vvv -i ~/.ssh/deployeasy_ed25519 thien@203.0.113.10
Tìm các dòng gần giống:
Offering public key: /home/minh/.ssh/deployeasy_ed25519
Server accepts key: ...
Nếu chỉ thấy client gửi một key khác, lỗi nằm ở lựa chọn key hoặc ~/.ssh/config.
Cấu hình mẫu:
Host deployeasy-vps
HostName 203.0.113.10
User thien
IdentityFile ~/.ssh/deployeasy_ed25519
IdentitiesOnly yes
Kết nối:
ssh deployeasy-vps
IdentitiesOnly yes hữu ích khi SSH agent đang giữ quá nhiều key và server từ chối trước khi client thử đúng key.

4. Kiểm tra authorized_keys trên server
Bạn cần truy cập server bằng console của nhà cung cấp hoặc một tài khoản quản trị khác.
sudo ls -ld /home/thien /home/thien/.ssh
sudo ls -l /home/thien/.ssh/authorized_keys
Đặt owner và quyền phổ biến:
sudo chown -R thien:thien /home/thien/.ssh
sudo chmod 700 /home/thien/.ssh
sudo chmod 600 /home/thien/.ssh/authorized_keys
Kiểm tra home directory:
sudo chown thien:thien /home/thien
sudo chmod 755 /home/thien
Không đặt chmod 777 để “sửa nhanh”. OpenSSH có thể từ chối file khóa nếu thư mục hoặc file cho phép người khác ghi, vì kẻ khác có thể chèn public key của họ.
Mỗi public key trong authorized_keys phải nằm trên một dòng hoàn chỉnh:
ssh-ed25519 AAAAC3NzaC1lZDI1NTE5AAAA... laptop-minh
5. Kiểm tra cấu hình và log server
Kiểm tra cấu hình trước khi reload:
sudo sshd -t
Xem các thiết lập hiệu lực:
sudo sshd -T | grep -E 'pubkeyauthentication|authorizedkeysfile|passwordauthentication'
Log Ubuntu/Debian:
sudo journalctl -u ssh --since "15 minutes ago"
Hoặc:
sudo tail -n 100 /var/log/auth.log
Log có thể chỉ ra:
Authentication refused: bad ownership or modes for directory /home/thien
Sau khi cấu hình hợp lệ:
sudo systemctl reload ssh
Giữ nguyên một phiên SSH đang hoạt động trong lúc sửa. Hãy mở phiên thứ hai để thử đăng nhập, tránh tự khóa mình khỏi VPS.
Phần B — Xử lý REMOTE HOST IDENTIFICATION HAS CHANGED
6. Vì sao host key thay đổi?
Các nguyên nhân hợp lệ:
- VPS vừa cài lại hệ điều hành.
- Nhà cung cấp thay máy chủ hoặc SSH host keys.
- IP cũ được cấp cho một VPS khác.
- Bạn đổi domain sang IP khác.
Các nguyên nhân cần cảnh giác:
- DNS hoặc file hosts trỏ sai.
- Bạn đang kết nối nhầm IP.
- Có thiết bị trung gian giả mạo server.
Vì vậy, cảnh báo không phải lỗi cần “lách”; nó là cơ chế bảo vệ danh tính server.
7. Xem khóa cũ đang lưu
ssh-keygen -F 203.0.113.10
Nếu dùng cổng riêng:
ssh-keygen -F '[203.0.113.10]:2222'
SSH thường cho biết dòng bị xung đột trong:
~/.ssh/known_hosts
Trên Windows OpenSSH, file thường nằm tại:
C:\Users\<ten-user>\.ssh\known_hosts
8. Xác minh fingerprint mới
Cách tốt nhất là dùng console của nhà cung cấp VPS — một kênh độc lập với kết nối SSH đang bị cảnh báo — rồi chạy trên server:
sudo ssh-keygen -lf /etc/ssh/ssh_host_ed25519_key.pub
So sánh fingerprint với fingerprint mà SSH client hiển thị. Chỉ tiếp tục khi chúng khớp và bạn đã xác nhận lý do host key thay đổi.
Bạn cũng có thể kiểm tra domain đang trỏ đến IP nào:
getent hosts example.com
9. Xóa đúng bản ghi cũ
Sau khi xác minh:
ssh-keygen -R 203.0.113.10
Với domain:
ssh-keygen -R deployeasy.io.vn
Với port riêng:
ssh-keygen -R '[203.0.113.10]:2222'
Kết nối lại và kiểm tra fingerprint trước khi nhập yes:
ssh thien@203.0.113.10
Không nên xóa toàn bộ file known_hosts, vì bạn sẽ mất dấu vân tay đã lưu của tất cả server khác.
10. Không dùng StrictHostKeyChecking=no như giải pháp mặc định
Lệnh dưới đây bỏ qua một phần cơ chế kiểm tra host key:
ssh -o StrictHostKeyChecking=no user@host
Nó có thể tiện trong một số môi trường tự động hóa đã có cơ chế tin cậy khác, nhưng không nên dùng để xử lý cảnh báo trên máy cá nhân. Bạn sẽ che mất tín hiệu quan trọng về việc server có đúng danh tính hay không.
11. Checklist Permission denied
- Username đúng.
- Client dùng đúng private key.
- Public key tương ứng có trong đúng
authorized_keys. -
.sshlà700,authorized_keyslà600. - Owner của home và
.sshđúng user. -
sshd -tkhông báo lỗi. - Log server không báo bad ownership/modes.
- Thử ở phiên SSH thứ hai trước khi đóng phiên cũ.
12. Checklist Host Key Changed
- Xác nhận VPS vừa reinstall, đổi IP hoặc có thay đổi hợp lệ.
- Kiểm tra IP/domain đang kết nối.
- Lấy fingerprint mới từ console độc lập.
- So sánh fingerprint.
- Chỉ xóa đúng entry bằng
ssh-keygen -Rsau khi xác minh. - Không xóa toàn bộ
known_hosts.
13. Câu hỏi thường gặp
Có thể copy private key lên VPS không?
Thông thường không cần. VPS chỉ cần public key trong authorized_keys. Private key nên ở thiết bị client của bạn.
Vì sao chmod 777 lại làm SSH từ chối?
Vì người dùng khác có thể sửa thư mục hoặc file khóa. OpenSSH kiểm tra quyền để ngăn người khác chèn khóa trái phép.
Host key khác user public key thế nào?
User public key giúp server xác minh người đăng nhập. Host key giúp client xác minh danh tính server. Hai loại khóa bảo vệ hai hướng khác nhau của kết nối.
Nguồn tham khảo
Đọc tiếp
Bài viết liên quan
SSH Key là gì? Đăng nhập VPS không cần mật khẩu an toàn
Hướng dẫn tạo SSH key trên Windows, Linux và macOS, thêm public key vào VPS, cấu hình alias, permission và sửa lỗi publickey an toàn.
Đọc bài →Docker Port Is Already Allocated: Cách tìm tiến trình chiếm cổng trên Windows và Linux
Hướng dẫn xử lý port is already allocated, address already in use và EADDRINUSE trong Docker Compose mà không tắt nhầm tiến trình.
Đọc bài →Docker bị Killed hoặc Exit Code 137 trên VPS: Cách xác định đúng nguyên nhân
Hướng dẫn kiểm tra Docker Exit Code 137, OOMKilled, RAM, swap và cách tối ưu quá trình build trên VPS cấu hình thấp.
Đọc bài →