SSD Nodes Learn Hosting plans →
Hướng dẫn Matt ConnorBởi Matt Connor

Sửa lỗi SSH Permission denied (publickey)

Lỗi “Permission denied (publickey)” có 5 nguyên nhân. Đọc output ssh -v để xác định đúng lỗi và sửa mà không tự khóa quyền truy cập SSH.

Ý nghĩa thực sự của “Permission denied (publickey)”

“Permission denied (publickey)” nghĩa là client của bạn đã gửi một hoặc nhiều public key nhưng server không chấp nhận key nào. Network vẫn hoạt động và sshd vẫn đang chạy: việc từ chối xảy ra ở bước cuối của quá trình xác thực. Nếu session bị ngắt trước bước đó, bạn đang gặp connection refused hoặc connection timed out, đây là một chẩn đoán khác với các bước kiểm tra khác. Không cần đoán cách sửa, vì ssh -v cho biết bạn đang gặp một trong năm nguyên nhân.

Các phương thức trong dấu ngoặc là những phương thức server chấp nhận. Permission denied (publickey) tự nó có nghĩa là đăng nhập bằng password đã bị tắt trên server đó, nên không có password để chuyển sang dùng. Permission denied (publickey,password) có nghĩa là password được cho phép nhưng bạn cũng xác thực bằng password không thành công.

Một thông báo này bao quát năm lỗi riêng biệt và cố ý không nêu rõ nguyên nhân. Nếu server trả lời “không có user đó” hoặc “key đó chưa được cài đặt”, thông tin này sẽ giúp bất kỳ ai đang quét các account hợp lệ. Vì vậy, đừng bắt đầu thay key và sửa các file cấu hình. Chạy một command, đọc ba dòng output, rồi thu hẹp năm nguyên nhân có thể xuống còn một.

Chạy ssh -v trước và đọc 3 dòng

Lặp lại command bị lỗi và thêm -v:

ssh -v deploy@203.0.113.10

Một kết quả rút gọn nhưng thực tế sẽ trông như sau:

OpenSSH_9.6p1 Ubuntu-3ubuntu13, OpenSSL 3.0.13 30 Jan 2024
debug1: Connecting to 203.0.113.10 [203.0.113.10] port 22.
debug1: Connection established.
debug1: Authenticating to 203.0.113.10:22 as 'deploy'
debug1: Authentications that can continue: publickey
debug1: Next authentication method: publickey
debug1: Will attempt key: /home/you/.ssh/id_ed25519 ED25519 SHA256:0eL/8sBw... agent
debug1: Offering public key: /home/you/.ssh/id_ed25519 ED25519 SHA256:0eL/8sBw... agent
debug1: Authentications that can continue: publickey
debug1: No more authentication methods to try.
deploy@203.0.113.10: Permission denied (publickey).

3 dòng này chứa mọi thông tin bạn cần.

Authenticating to 203.0.113.10:22 as 'deploy' là username thực sự sẽ được sử dụng. Không phải username bạn định dùng, mà là username được ssh xác định từ command line, từ ~/.ssh/config hoặc từ tên đăng nhập local của bạn.

Authentications that can continue: publickey là danh sách các method được server chấp nhận, được gửi trước khi thử bất kỳ key nào. Nếu publickey không có trong danh sách đầu tiên đó, server đã tắt đăng nhập bằng public key, nên không key nào có thể hoạt động.

Offering public key: ... là mỗi key mà client thực sự gửi, mỗi key nằm trên một dòng và có tên file nguồn cùng fingerprint SHA256. Key không có dòng Offering nghĩa là key đó chưa từng được gửi đến server.

Bây giờ hãy tách vấn đề thành 2 phần:

  • Không có dòng Offering public key cho key bạn cần dùng. Lỗi nằm trên máy của bạn vì server chưa hề nhận được key.
  • Key được gửi nhưng Authentications that can continue: publickey lại xuất hiện. Server đã nhận key đó và từ chối, nên lỗi nằm trên server.

Các nguyên nhân dưới đây được sắp xếp theo tần suất chúng thực sự là nguyên nhân gây lỗi.

Nguyên nhân 1: bạn đang kết nối bằng sai username

Đây cũng là nguyên nhân phổ biến nhất nhưng ít đáng chú ý nhất. sshd, daemon SSH (secure shell) server, không bao giờ cho biết một account không tồn tại. Nó vẫn thực hiện toàn bộ quá trình kết nối với username không có thật rồi từ chối ở cuối bằng cùng một thông báo, vì để lộ tên account hợp lệ sẽ giúp attacker. Gõ sai username trông giống hệt như key bị lỗi.

Trước tiên, hãy kiểm tra dòng Authenticating to ... as. Nếu dòng này ghi login trên laptop của bạn thay vì account trên server, bạn đã bỏ username khỏi command.

ssh -v deploy@203.0.113.10
ssh -v root@203.0.113.10

Account mặc định phụ thuộc vào image mà provider build. Tính đến tháng 08 năm 2026, Ubuntu cloud image thường có account ubuntu, Debian image có debian hoặc admin, Rocky Linux và AlmaLinux có rocky và almalinux, còn nhiều VPS provider cài key trực tiếp vào root. Control panel của provider ghi lại account mà họ đã tạo. Không có command nào chạy từ bên ngoài server có thể hỏi thông tin này.

Một block Host trong ~/.ssh/config cũng đặt username và được ưu tiên hơn login name trên máy local của bạn:

Host vps-prod
  HostName 203.0.113.10
  User deploy

Nếu bạn tự tạo account rồi không thể đăng nhập bằng account đó, có thể key chỉ được cài cho user mặc định của image và chưa được sao chép sang account mới. Đây là một bước trong 10 phút đầu tiên khi thiết lập VPS mới, nhưng rất dễ bị bỏ qua.

Nguyên nhân 2: key bạn nghĩ mình đang gửi không phải key thực sự được gửi

Mặc định, ssh chỉ gửi các key do ssh-agent giữ cùng một tập tên file cố định trong ~/.ssh: id_rsa, id_ecdsa, id_ed25519, các biến thể hardware key id_ecdsa_sk và id_ed25519_sk, cùng key post-quantum hybrid id_mldsa44_ed25519. OpenSSH hiện không còn hỗ trợ DSA (OpenSSH 10.0 đã loại bỏ tính năng này vào tháng 4 năm 2025), nên file id_dsa cũ sẽ không bao giờ được thử. Key được lưu dưới tên ~/.ssh/vps-prod sẽ không được ssh nhận ra cho đến khi bạn chỉ rõ tên file, vì vậy output verbose không hiển thị dòng Offering public key cho key đó.

Chỉ rõ file và ngăn các key của agent được dùng thay:

ssh -i ~/.ssh/vps-prod -o IdentitiesOnly=yes deploy@203.0.113.10

Chỉ dùng -i là chưa đủ khi agent đang giữ các key, vì ssh vẫn gửi các key của agent trước rồi mới gửi file được chỉ rõ. Điều này quan trọng vì server tính mọi key bị từ chối vào MaxAuthTries, mặc định là 6. Agent giữ 7 key có thể dùng hết giới hạn trước khi đến đúng key của bạn, sau đó thông báo sẽ đổi thành:

Received disconnect from 203.0.113.10 port 22:2: Too many authentication failures

Nếu bạn thấy thông báo này, server đã ngắt session trước khi thử đến đúng key của bạn. Vấn đề này được trình bày trong quá nhiều lần xác thực thất bại. IdentitiesOnly=yes giới hạn lần thử ở file bạn đã truyền vào. Liệt kê các key agent đang giữ bằng ssh-add -l và xóa chúng bằng ssh-add -D nếu agent đã tích lũy các key cũ trong nhiều năm. Sau đó ghi các thiết lập này lại để lần đăng nhập sau không phụ thuộc vào việc nhớ các flag:

Host vps-prod
  HostName 203.0.113.10
  User deploy
  IdentityFile ~/.ssh/vps-prod
  IdentitiesOnly yes

Một bẫy khác ở phía client. ssh từ chối sử dụng private key mà các account khác trên chính máy của bạn có thể đọc. ssh sẽ in cảnh báo rồi bỏ qua key, nên key không bao giờ được gửi và server không bao giờ nhìn thấy key đó:

@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@
@         WARNING: UNPROTECTED PRIVATE KEY FILE!          @
@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@
Permissions 0644 for '/home/you/.ssh/vps-prod' are too open.

chmod 600 ~/.ssh/vps-prod khắc phục vấn đề này. Việc chuyển key qua USB hoặc Windows share là nguyên nhân thường gặp làm mất mode của file. Nội dung về vị trí lưu key và cách đặt tên được trình bày trong kiến thức cơ bản về quản lý SSH key.

Nguyên nhân 3: public key chưa được đưa vào authorized_keys

Nếu ssh -v cho thấy key đã được gửi đi nhưng server vẫn từ chối, hãy kiểm tra key đó có nằm trong file authorized_keys của account hay không. Mở console của nhà cung cấp để kiểm tra, vì bạn không thể đăng nhập qua SSH để xem file này.

sudo ls -l /home/deploy/.ssh/
sudo ssh-keygen -lf /home/deploy/.ssh/authorized_keys

ssh-keygen -lf trên file authorized_keys sẽ in một fingerprint cho mỗi entry:

256 SHA256:0eL/8sBw... you@laptop (ED25519)
3072 SHA256:9Tq2yZk... old-laptop (RSA)

So sánh các fingerprint đó với fingerprint trên dòng Offering public key của bạn. Nếu fingerprint không nằm trong danh sách, key chưa được cài cho account đó, dù bạn nhớ là mình đã thực hiện thao tác này.

Có 4 lỗi thường gặp:

  • Bạn đã dán private key thay vì file .pub. Dòng public key bắt đầu bằng ssh-ed25519 hoặc ssh-rsa. Private key bắt đầu bằng -----BEGIN OPENSSH PRIVATE KEY-----.
  • Nội dung dán bị xuống dòng thành nhiều dòng. Mỗi entry phải nằm trên đúng một dòng. Vì vậy, key bị xuống dòng sẽ bị đọc thành nhiều entry hỏng và không khớp với gì cả.
  • Key được thêm vào /root/.ssh/authorized_keys nhưng bạn đăng nhập bằng deploy, hoặc ngược lại. File này thuộc riêng từng account, không có file dùng chung.
  • Hộp "add my key" của nhà cung cấp chỉ ghi key vào user mặc định của image. Vì vậy, account bạn tạo sau đó có thư mục .ssh trống.

Cách an toàn để thêm key từ console, với quyền root:

sudo install -d -m 700 -o deploy -g deploy /home/deploy/.ssh
sudo tee -a /home/deploy/.ssh/authorized_keys >/dev/null <<'EOF'
ssh-ed25519 AAAAC3NzaC1lZDI1NTE5AAAAIExampleKeyDataHere you@laptop
EOF
sudo chown deploy:deploy /home/deploy/.ssh/authorized_keys
sudo chmod 600 /home/deploy/.ssh/authorized_keys

Sau đó chạy lại sudo ssh-keygen -lf /home/deploy/.ssh/authorized_keys. Fingerprint mới sẽ xuất hiện trong danh sách. Từ một máy vẫn có thể đăng nhập bằng password, ssh-copy-id -i ~/.ssh/vps-prod.pub deploy@203.0.113.10 sẽ thực hiện công việc tương tự và tự đặt đúng mode cho bạn.

Nguyên nhân 4: vì sao sshd bỏ qua authorized_keys khi quyền truy cập quá rộng

StrictModes yes là thiết lập mặc định của sshd. Với thiết lập này, sshd từ chối đọc authorized_keys nếu file đó, thư mục .ssh hoặc thư mục home của account có thể bị bất kỳ ai không phải owner ghi. Lý do rất rõ: nếu group hoặc toàn bộ người dùng có quyền ghi vào thư mục home, bất kỳ account nào có quyền đó cũng có thể thay thế authorized_keys và chiếm quyền đăng nhập. sshd xem một đường dẫn không đáng tin cậy như thể không tồn tại key.

Client chỉ nhận được thông báo Permission denied chung chung. Log trên server ghi lại nguyên nhân thực sự:

Authentication refused: bad ownership or modes for directory /home/deploy/.ssh

hoặc khi chính file đó có vấn đề:

Authentication refused: bad ownership or modes for file /home/deploy/.ssh/authorized_keys

Những thiết lập mà sshd chấp nhận:

  • Thư mục home: không được group-writable và không được world-writable. 755, 750 và 700 đều đạt. 775 và 777 không đạt.
  • ~/.ssh: mode 700.
  • ~/.ssh/authorized_keys: mode 600.
  • Ownership: cả ba phải thuộc về account dùng để đăng nhập, không phải root.

Ownership quan trọng không kém mode. Một file bên trong /home/deploy/.ssh thuộc về root cũng không vượt qua được kiểm tra tương tự. Đây là trường hợp thường xảy ra khi bạn tạo file bằng sudo nano rồi quên chuyển ownership lại. Sửa cả hai cùng lúc:

sudo chown -R deploy:deploy /home/deploy/.ssh
sudo chmod 700 /home/deploy/.ssh
sudo chmod 600 /home/deploy/.ssh/authorized_keys
sudo chmod go-w /home/deploy
ls -ld /home/deploy /home/deploy/.ssh

Lệnh cuối hiển thị kết quả. Thư mục home cần có drwxr-xr-x hoặc chặt hơn, còn drwx------ trên .ssh. Nếu các chuỗi này vẫn chưa rõ, hãy đọc cách đọc chuỗi quyền như drwxr-xr-x trước khi thay đổi mode trên server đang chạy.

Trên Rocky Linux và AlmaLinux, hãy thêm SELinux (security-enhanced Linux) vào danh sách nguyên nhân cần kiểm tra. Thư mục .ssh được tạo bằng một cách bất thường có thể mang sai file label, khiến sshd bị từ chối quyền đọc dù mode trông đúng. sudo restorecon -Rv /home/deploy/.ssh khôi phục các label, còn sudo ausearch -m avc -ts recent cho biết SELinux có phải là thành phần từ chối quyền hay không.

Nguyên nhân 5: sshd được cấu hình để từ chối bạn

Chỉ đọc /etc/ssh/sshd_config là chưa đủ trên hệ thống Ubuntu hoặc Debian hiện tại. File đó bắt đầu bằng Include /etc/ssh/sshd_config.d/*.conf, và OpenSSH giữ lại giá trị đầu tiên tìm thấy cho mỗi setting. Vì vậy, file drop-in như 50-cloud-init.conf được đọc trước và có hiệu lực thay cho mọi thay đổi bạn thực hiện ở phía dưới trong file chính. Đây là lý do một chỉnh sửa có vẻ đúng nhưng hoàn toàn không thay đổi hành vi.

Hãy yêu cầu sshd hiển thị cấu hình có hiệu lực được tạo từ tất cả các file đó:

sudo sshd -T | grep -Ei 'pubkeyauth|authorizedkeysfile|permitrootlogin|allowusers|allowgroups|denyusers'

sshd -T khởi chạy một tiến trình test mới, đọc các file đúng theo trạng thái hiện tại trên disk. Lệnh này không hỏi tiến trình sshd đang chạy, nên một chỉnh sửa chưa được áp dụng bằng restart vẫn hiển thị ở đây trước khi server đang chạy sử dụng nó.

Kết quả bình thường có dạng như sau:

permitrootlogin prohibit-password
pubkeyauthentication yes
authorizedkeysfile .ssh/authorized_keys .ssh/authorized_keys2

Trong output của bạn, hãy kiểm tra các mục sau:

  • pubkeyauthentication no. Không có key nào được chấp nhận. Mục này cũng xuất hiện trong ssh -v dưới dạng danh sách Authentications that can continue: đầu tiên nhưng không có publickey.
  • authorizedkeysfile trỏ đến một vị trí khác, chẳng hạn /etc/ssh/authorized_keys/%u. Khi đó file trong thư mục home bị bỏ qua hoàn toàn, và các quy tắc mode ở nguyên nhân 4 được áp dụng cho path mới.
  • Có allowusers hoặc allowgroups. Mọi account không nằm trong danh sách đều bị từ chối với chính xác lỗi này và không có giải thích. denyusers và denygroups hoạt động ngược lại.
  • permitrootlogin no trong khi bạn đang đăng nhập bằng root. prohibit-password là setting trung gian phù hợp: root được dùng key nhưng không được dùng password.

Các block Match không xuất hiện trong sshd -T thông thường, vì kết quả của chúng phụ thuộc vào người đang kết nối. Hãy kiểm tra một kết nối cụ thể:

sudo sshd -T -C user=deploy,host=vps.example.com,addr=198.51.100.7

Một setting khác ảnh hưởng đến các key cũ. OpenSSH 8.8 mặc định ngừng chấp nhận chữ ký SHA-1 (ssh-rsa), nên một RSA key đã hoạt động nhiều năm có thể ngừng hoạt động sau khi một đầu được upgrade, khi đầu còn lại quá cũ để dùng RSA với SHA-256. Client hiện tại kết nối đến server cũ như vậy sẽ hiển thị rõ nguyên nhân:

debug1: send_pubkey_test: no mutual signature algorithm

Bản thân key thường không có vấn đề. Release notes của OpenSSH 8.8 cho biết không cần thay thế các ssh-rsa key, vì chúng sẽ chuyển sang RSA/SHA-256 hoặc RSA/SHA-512 khi cả hai đầu đều hỗ trợ. Do đó, upgrade đầu cũ là cách khắc phục lâu dài. Nếu không thể upgrade đầu đó, key mới cũng hoạt động: ssh-keygen -t ed25519 -C "deploy@vps-prod", sau đó cài file .pub như hướng dẫn ở trên. Đặt PubkeyAcceptedAlgorithms +ssh-rsa ở phía đã upgrade (trong block Host của ~/.ssh/config trên client hoặc trong cấu hình sshd của server) sẽ bật lại các chữ ký cũ và giúp bạn truy cập server ngay hôm nay. Tuy nhiên, hãy xem đây là cách để vào server, không phải bước hoàn tất việc xử lý. Các setting phía server khác cần xem lại nằm trong hardening SSH server trên VPS.

Cách xác minh private key khớp với public key đã cài đặt

Phần lớn việc phỏng đoán trong lỗi này xuất phát từ việc không biết hai file có phải là một cặp hay không. Một lệnh sẽ trả lời câu hỏi đó:

ssh-keygen -y -f ~/.ssh/vps-prod

Lệnh này in ra public key được suy ra từ private key. Lệnh không đọc file .pub nằm cạnh nó, nên cho biết private key thực sự chứa gì thay vì nội dung mà file .pub cũ khẳng định. Nếu key có passphrase, lệnh sẽ yêu cầu nhập passphrase. Điều này cũng xác nhận bạn vẫn biết passphrase đó.

ssh-keygen -lf ~/.ssh/vps-prod.pub
ssh-add -l

Lệnh đầu tiên in fingerprint của một file public key. Lệnh thứ hai in các fingerprint mà agent đang giữ. Bây giờ hãy đối chiếu 4 cách hiển thị của cùng một chuỗi: fingerprint trên dòng Offering public key từ ssh -v, fingerprint của file .pub, các fingerprint trong ssh-keygen -lf trên authorized_keys của server, và fingerprint trong log của server. Vị trí đầu tiên các giá trị không còn khớp chính là nguyên nhân gây lỗi.

Đọc log của server khi đăng nhập thất bại

Client cố ý không được thông báo nguyên nhân hữu ích nào. Server ghi lại lý do thực tế. Bắt đầu theo dõi log trong phiên console, sau đó chạy lệnh ssh đang thất bại từ laptop của bạn.

sudo journalctl -u ssh -f

Ubuntu 24.04 server và cloud image mặc định cài rsyslog, vì vậy các bản ghi tương tự cũng được ghi vào /var/log/auth.log trên đó. Trên Rocky Linux và AlmaLinux, unit có tên là sshd và các bản ghi tương tự cũng được ghi vào /var/log/secure.

Đặt LogLevel VERBOSE trong cấu hình sshd rồi reload service. Sau đó, mỗi lần thử sẽ ghi fingerprint mà server thực sự nhận được:

Failed publickey for deploy from 198.51.100.7 port 49812 ssh2: ED25519 SHA256:0eL/8sBw...

Dòng này cho biết lỗi nằm ở phía nào. Fingerprint bạn nhận ra nghĩa là key của bạn đã đến server nhưng bị server từ chối, vì vậy hãy kiểm tra nguyên nhân 3, 4 và 5. Fingerprint bạn không nhận ra nghĩa là client đã gửi một key khác với key bạn định dùng, vì vậy hãy quay lại nguyên nhân 2.

Nếu log vẫn chưa rõ, hãy chạy một sshd thứ hai trên cổng khác ở debug mode. Nó chạy ở foreground, xử lý một connection, in ra quá trình kiểm tra, rồi thoát:

sudo /usr/sbin/sshd -ddd -p 2222

Từ phiên console trên cùng server, hãy kết nối đến service này qua địa chỉ loopback:

ssh -p 2222 -i ~/.ssh/vps-prod -o IdentitiesOnly=yes deploy@127.0.0.1

Kết nối qua 127.0.0.1 giúp loại firewall khỏi bài kiểm tra. Output debug cho biết file đã mở, fingerprint đã được so sánh và lý do từ chối chính xác, bao gồm các dòng như Authentication refused: bad ownership or modes for directory /home/deploy. Nhấn Ctrl+C khi đã xác định được nguyên nhân. sshd thật trên cổng 22 không bị ảnh hưởng trong suốt quá trình này.

Cách tránh tự khóa quyền truy cập

Mọi bước chỉnh sửa cấu hình server đều cần có một cách truy cập dự phòng không phụ thuộc vào SSH. Hãy thiết lập cách này khi SSH vẫn hoạt động, không phải sau khi SSH bị lỗi.

  1. Mở console của nhà cung cấp qua serial hoặc VNC (virtual network computing), rồi xác nhận bạn có thể đăng nhập tại đó.
  2. Đảm bảo bạn biết một local password đang hoạt động cho account có quyền sudo. Nếu chưa có, trước tiên hãy reset root password từ console của nhà cung cấp.
  3. Giữ nguyên SSH session hiện tại. Một session đang mở vẫn tồn tại sau systemctl restart ssh, nên nó vẫn là đường truy cập dự phòng nếu cấu hình mới bị sai.
  4. Kiểm tra cú pháp trước khi restart: sudo sshd -t không in gì khi file hợp lệ, và in file cùng số dòng khi file không hợp lệ.
  5. Mở terminal thứ hai và đăng nhập lại từ đầu trước khi đóng terminal thứ nhất. Cấu hình bị lỗi sẽ chặn các lần đăng nhập mới nhưng không ảnh hưởng đến các session hiện có, nên session bạn đang sử dụng không thể cho biết thay đổi đã hoạt động hay chưa.

Dùng sudo systemctl restart ssh để restart trên Debian và Ubuntu, hoặc sudo systemctl restart sshd trên Rocky Linux và AlmaLinux. Trên Ubuntu 24.04, sshd được khởi động từ một socket unit; port và địa chỉ của unit này lấy từ sshd_config thông qua systemd generator. Vì vậy, thay đổi đối với Port hoặc ListenAddress cũng cần chạy sudo systemctl daemon-reload rồi sudo systemctl restart ssh.socket trước khi có hiệu lực.

FAQ

Vì sao tôi nhận được Permission denied (publickey) khi cùng một key vẫn hoạt động trên server khác?

Vì key không có vấn đề; vấn đề nằm ở một thành phần liên quan. Chạy ssh -v và tìm dòng Offering public key. Nếu key không được liệt kê, ssh chưa gửi key đó: file không nằm trong ~/.ssh với tên mặc định và key cũng chưa được load vào agent, nên hãy thêm -i /path/to/key -o IdentitiesOnly=yes. Nếu key đã được liệt kê nhưng server vẫn từ chối, key đó không có trong authorized_keys của account, đường dẫn đến file cho phép group ghi, hoặc cấu hình sshd chặn user. Server log sẽ phân biệt được các trường hợp này.

Làm thế nào để xem SSH thực sự đang gửi key nào?

ssh -v host in ra một dòng debug1: Offering public key: cho mỗi key. Mỗi dòng ghi file nguồn và fingerprint SHA256. ssh-add -l liệt kê fingerprint của các key mà agent đang giữ. ssh-keygen -lf ~/.ssh/id_ed25519.pub in fingerprint của một file key cụ thể, còn ssh-keygen -y -f ~/.ssh/id_ed25519 in public key thực sự được suy ra từ một private key. Để đăng nhập thành công, fingerprint trong dòng Offering cũng phải xuất hiện trong ssh-keygen -lf khi chạy lệnh này với authorized_keys của server.

Vì sao sshd bỏ qua file authorized_keys của tôi?

Vì StrictModes được bật mặc định, và file, thư mục .ssh hoặc home directory có quyền ghi cho group hoặc world, hoặc thuộc sở hữu của account không đúng. sshd sẽ không tin cậy một đường dẫn mà người khác có thể sửa, nên xử lý như thể không có key nào tồn tại. Đặt home directory về 755 hoặc chặt hơn, .ssh về 700, authorized_keys về 600, và bảo đảm cả ba đều thuộc sở hữu của login account. Khi bật LogLevel VERBOSE, server sẽ ghi lại Authentication refused: bad ownership or modes for directory /home/deploy/.ssh.

Key của tôi ngừng hoạt động ngay sau khi server được nâng cấp. Có gì đã thay đổi?

Nếu đây là RSA key, nguyên nhân nhiều khả năng là thay đổi liên quan đến SHA-1. OpenSSH 8.8 mặc định vô hiệu hóa chữ ký SHA-1 ssh-rsa, nên RSA key bị từ chối khi đầu bên kia chỉ có thể dùng key theo cách đó. Client hiện tại hiển thị debug1: send_pubkey_test: no mutual signature algorithm. Không cần thay key nếu bạn có thể nâng cấp đầu bên cũ, vì RSA key dùng SHA-256 hoặc SHA-512 khi cả hai đầu đều hỗ trợ. Nếu không thể nâng cấp, hãy tạo key hiện đại bằng ssh-keygen -t ed25519 và cài file .pub của key đó. Nếu cần truy cập ngay, PubkeyAcceptedAlgorithms +ssh-rsa trên phía đã nâng cấp sẽ bật lại các chữ ký cũ. Bạn nên xóa dòng đó sau khi đã áp dụng cách sửa lâu dài.

Tôi đã sửa sshd_config và giờ hoàn toàn không thể đăng nhập. Làm thế nào để truy cập lại?

Dùng console của nhà cung cấp. Console không đi qua SSH. Đăng nhập bằng local password, chạy sudo sshd -t để xem lỗi cú pháp và số dòng, hoàn tác thay đổi rồi restart service. Sau đó chạy sudo sshd -T để xem các giá trị hiệu lực mà những file hiện tại tạo ra, vì một file trong /etc/ssh/sshd_config.d/ có thể đang ghi đè cấu hình chính. Lệnh này đọc lại các file thay vì hỏi sshd đang chạy, nên phải restart service sau mỗi lần chỉnh sửa tiếp theo rồi mới kiểm tra đăng nhập. Nếu không có local password, hãy reset root password từ console trước, sau đó sửa file.

#SSH#openssh#troubleshooting#permissions#vps