DeployEasy
LinuxCơ bản

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.

· 6 phút đọc· 1.273 từ
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.

Luồng xác thực SSH và nơi thường xảy ra lỗ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.

Terminal demo kiểm tra public key và host 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.
  • .ssh700, authorized_keys600.
  • Owner của home và .ssh đúng user.
  • sshd -t khô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 -R sau 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