Sửa lỗi "Permission denied (publickey)" Khi Kết Nối SSH

Lỗi

$ ssh user@192.168.1.100
user@192.168.1.100: Permission denied (publickey,gssapi-keyex,gssapi-with-mic,password).

Hoặc dạng rút gọn thường thấy trên các cloud server:

Permission denied (publickey).

SSH đã từ chối kết nối của bạn. Server liệt kê tất cả các phương thức xác thực mà nó hỗ trợ — nhưng không cái nào hoạt động được. Khó chịu, nhưng có thể sửa được. Gần như lúc nào cũng quy về một trong năm nguyên nhân gốc rễ sau đây.

Nguyên Nhân

• Private key của bạn không khớp với bất kỳ public key nào trong ~/.ssh/authorized_keys trên server
• Phân quyền file trên ~/.ssh/ hoặc authorized_keys quá thoáng — SSH từ chối sử dụng chúng
• SSH agent chưa load key của bạn
• Bạn đang kết nối với sai username (thường gặp với EC2, DigitalOcean, v.v.)
• Đường dẫn file key sai hoặc bạn quên truyền tham số -i

Bước 1: Chạy SSH Ở Chế Độ Verbose Trước

Đừng đoán mò. Hãy để SSH cho bạn biết chính xác nó đang làm gì:

ssh -vvv user@your-server.com

Cuộn qua output và tìm các dòng như sau:

debug1: Offering public key: /home/you/.ssh/id_rsa RSA ...
debug1: Authentications that can continue: publickey
debug1: No more authentication methods to try.

"Offering public key" theo sau là "No more authentication methods" có nghĩa là server đã từ chối đúng key đó. Không thấy dòng "Offering" nào? Tức là client không tìm thấy key nào để thử.

Cách Sửa 1: Kiểm Tra Public Key Trong authorized_keys

Đây là nguyên nhân phổ biến nhất. Lấy public key từ máy local của bạn:

cat ~/.ssh/id_rsa.pub
# hoặc
cat ~/.ssh/id_ed25519.pub

Sau đó trên server, kiểm tra xem nó có trong danh sách không:

cat ~/.ssh/authorized_keys

Chưa có? Thêm vào:

# Từ máy local của bạn:
ssh-copy-id -i ~/.ssh/id_ed25519.pub user@your-server.com

# Hoặc thủ công — thêm key vào cuối file:
echo "your-public-key-content" >> ~/.ssh/authorized_keys

Lưu ý quan trọng: mỗi key phải nằm trên một dòng liên tục không bị ngắt. Nếu key bị xuống dòng thì SSH sẽ không nhận ra.

Cách Sửa 2: Sửa Phân Quyền File SSH

SSH sẽ âm thầm bỏ qua các key nếu phân quyền quá thoáng. Không có cảnh báo, không có thông báo gợi ý — nó chỉ đơn giản là từ chối. Dễ bỏ qua, nhưng rất dễ sửa.

Trên server:

chmod 700 ~/.ssh
chmod 600 ~/.ssh/authorized_keys

Trên máy local, sửa quyền cho private key:

chmod 600 ~/.ssh/id_rsa
# hoặc
chmod 600 ~/.ssh/id_ed25519

Các quy tắc phân quyền mà SSH bắt buộc:

• Thư mục ~/.ssh/ — phải là 700 (chỉ owner được truy cập)
• authorized_keys — phải là 600 hoặc tối đa 640
• File private key — phải là 600 (nếu ai cũng đọc được thì SSH từ chối sử dụng)

Mẹo: Nếu bạn hay quên con số chmod nào tương ứng với quyền gì, Unix Permissions Calculator trên ToolCraft cho phép bạn thiết lập quyền bằng giao diện trực quan và hiển thị số chmod tương đương. Rất tiện khi bạn cứ phân vân không biết 640 hay 644 mới đúng.

Cách Sửa 3: Chỉ Định Đúng Key Bằng -i

Có nhiều key trên hệ thống? SSH sẽ tự chọn một cái — và có thể chọn nhầm. Hãy chỉ định rõ ràng:

ssh -i ~/.ssh/my-specific-key user@your-server.com

Với AWS EC2, dùng file .pem bạn đã tải xuống khi tạo instance:

ssh -i ~/Downloads/my-ec2-key.pem ec2-user@your-ec2-ip

Cũng cần chú ý username. EC2 Amazon Linux dùng ec2-user, Ubuntu dùng ubuntu, Debian dùng admin. Sai username = bị từ chối ngay cả khi dùng đúng key.

Cách Sửa 4: Thêm Key Vào SSH Agent

SSH agent lưu key đã giải mã vào bộ nhớ để bạn không phải nhập passphrase mỗi lần kết nối. Nếu agent chưa chạy hoặc key chưa được load, key đó có thể không được đưa ra trong quá trình xác thực. Khởi động agent và thêm key:

eval "$(ssh-agent -s)"
ssh-add ~/.ssh/id_ed25519

Kiểm tra những gì đang được load:

ssh-add -l

"The agent has no identities" nghĩa là chưa có gì được load. Chạy ssh-add và nhập passphrase của bạn.

Cách Sửa 5: Kiểm Tra authorized_keys Trên Server (SELinux / Sai Owner)

Các server CentOS và RHEL chạy SELinux, thứ này kiểm soát file context ngoài phân quyền Unix thông thường. Giá trị chmod đúng chưa chắc đã đủ. Kiểm tra file context:

ls -laZ ~/.ssh/authorized_keys

Context trông sai? Khôi phục lại:

restorecon -Rv ~/.ssh

Trong khi kiểm tra, hãy xác nhận ~/.ssh thuộc sở hữu của đúng user:

ls -la ~ | grep .ssh
# Phải hiển thị: drwx------ 2 youruser youruser

~/.ssh bị sở hữu bởi root là chuyện khá phổ biến sau khi chạy các lệnh sudo. Sửa lại:

sudo chown -R youruser:youruser ~/.ssh

Cách Sửa 6: Kiểm Tra Cấu Hình sshd Trên Server

Nên kiểm tra cuối cùng — đôi khi bản thân server được cấu hình để từ chối xác thực bằng public key:

sudo grep -E 'PubkeyAuthentication|AuthorizedKeysFile|PermitRootLogin' /etc/ssh/sshd_config

Bạn muốn thấy:

PubkeyAuthentication yes
AuthorizedKeysFile .ssh/authorized_keys

Nếu PubkeyAuthentication được đặt là no, hãy sửa lại và khởi động lại sshd:

sudo systemctl restart sshd

Xác Nhận Đã Sửa Xong

Sau bất kỳ thay đổi nào, hãy kiểm tra với chế độ verbose:

ssh -v user@your-server.com

Xác thực thành công trông như thế này:

debug1: Authentication succeeded (publickey).

Vẫn lỗi? Hãy thực hiện tuần tự từng cách sửa. Vấn đề phân quyền và sai key chiếm khoảng 80% các trường hợp — rất có thể bạn sẽ tìm ra giải pháp ngay ở Cách Sửa 2 hoặc 3.

Phòng Tránh

• Tạo key bằng ssh-keygen -t ed25519 — Ed25519 nhanh hơn đáng kể so với RSA-2048 trong các thao tác ký và được xem là bền vững hơn trước các cuộc tấn công trong tương lai
• Dùng ssh-copy-id để deploy key thay vì copy-paste thủ công — lệnh này tự động thiết lập đúng phân quyền
• Lưu thông tin kết nối trong ~/.ssh/config để không bao giờ nhầm username hay đường dẫn key nữa:

Host myserver
  HostName 192.168.1.100
  User ubuntu
  IdentityFile ~/.ssh/id_ed25519

• Sao lưu thư mục ~/.ssh/ của bạn. Mất private key đồng nghĩa với mất quyền truy cập vào mọi server đã đăng ký key đó — không có cách nào khôi phục
• Thay SSH key định kỳ và luôn bảo vệ chúng bằng passphrase mạnh. Công cụ tạo mật khẩu tại ToolCraft rất hữu ích ở đây — passphrase cho SSH key cần vừa đủ mạnh vừa có thể nhớ để gõ được