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

Ý 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

Theo mặc định, ssh chỉ offer các key do ssh-agent giữ và một nhóm filename cố định trong ~/.ssh: id_ed25519, id_ecdsa, id_rsa cùng các biến thể hardware và DSA của những tên đó. Một key được lưu dưới tên ~/.ssh/vps-prod sẽ không được ssh nhận diện cho đến khi bạn chỉ định tên file, nên output verbose không có dòng Offering public key cho key này.

Chỉ định file và ngăn các key từ agent được offer thay cho nó:

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

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

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

Nếu thay vào đó 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 đề cập trong quá nhiều lần xác thực thất bại. IdentitiesOnly=yes giới hạn lần thử vào file bạn đã chỉ định. Dùng ssh-add -l để liệt kê các key mà agent đang giữ. Nếu agent đã tích lũy các key cũ từ nhiều năm, dùng ssh-add -D để xóa chúng. Sau đó ghi lại các thiết lập để lần đăng nhập tiếp theo 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

Còn một vấn đề 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. Nó in cảnh báo rồi bỏ qua key, nên key không bao giờ được offer và server không bao giờ nhận được 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 phổ biến làm mất mode. Phần kiến thức cơ bản về quản lý SSH key trình bày vị trí lưu key và cách đặt tên cho chúng.

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 nay. File đó bắt đầu bằng Include /etc/ssh/sshd_config.d/*.conf, và OpenSSH giữ lại giá trị đầu tiên mà nó tìm thấy cho mỗi setting. Vì vậy, file drop-in như 50-cloud-init.conf sẽ được đọc trước và có hiệu lực thay cho mọi giá trị bạn chỉnh ở 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 kết quả.

Hãy yêu cầu sshd hiển thị cấu hình thực sự đang sử dụng:

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

Kết quả đúng sẽ 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 nơi khác, ví dụ /etc/ssh/authorized_keys/%u. Khi đó file trong thư mục home hoàn toàn bị bỏ qua, còn các quy tắc mode trong 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 sẽ bị từ chối với đúng lỗi này mà không có giải thích. denyusers và denygroups cũng hoạt động tương tự theo chiều 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ó thể dùng key nhưng không thể dùng password.

Các block Match không xuất hiện trong output 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), vì vậy một RSA key đã hoạt động trong nhiều năm có thể ngừng hoạt động ngay sau khi server được upgrade. Client sẽ hiển thị rõ nguyên nhân:

debug1: send_pubkey_test: no mutual signature algorithm

Cách sửa đúng là tạo key mới: ssh-keygen -t ed25519 -C "deploy@vps-prod", sau đó cài file .pub như phần trên. Đặt PubkeyAcceptedAlgorithms +ssh-rsa trên server sẽ bật lại các chữ ký cũ và giúp bạn truy cập server ngay hôm nay. Hãy xem đây là cách để vào được server, không phải bước cuối cùng. Các setting phía server khác đáng kiểm tra nằm trong harden 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.

Theo dõi 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 nguyên nhân thực tế. Hãy 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 không cài rsyslog theo mặc định, nên /var/log/auth.log có thể không tồn tại trên hệ thống này. 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 lại 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 log đó cho biết lỗi nằm ở phía nào. Nếu fingerprint là fingerprint bạn nhận ra, key của bạn đã đến server nhưng bị server từ chối. Hãy kiểm tra nguyên nhân 3, 4 và 5. Nếu fingerprint không phải fingerprint bạn nhận ra, client đã gửi một key không đúng với ý định của bạn. 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. Tiến trình này chạy ở foreground, phục vụ một connection, in ra quá trình xử lý rồi thoát:

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

Từ phiên console trên chính server đó, hãy kết nối đến sshd 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 sẽ cho biết file đã được mở, fingerprint được đem ra so sánh và nguyên nhân 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 chính 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 phương án truy cập dự phòng không phụ thuộc vào SSH. Hãy thiết lập phương án 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ữ phiên SSH hiện tại mở. Một phiên đ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 syntax 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 trong phiên mới trước khi đóng phiên đầu tiên. 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 phiên hiện có. Vì vậy, phiên bạn đang 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, nên thay đổi đối với Port hoặc ListenAddress cũng cần chạy sudo systemctl restart ssh.socket trước khi có hiệu lực.

FAQ

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

Vì key không có vấn đề; lỗi nằm ở thành phần liên quan. Chạy ssh -v và tìm dòng Offering public key. Nếu key của bạn 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à cũng chưa được nạp vào agent, vì vậy 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 đó có thể chưa có trong authorized_keys của account, đường dẫn đến file có quyền ghi cho group, hoặc cấu hình sshd đang chặn user. Log của server sẽ phân biệt được các trường hợp này.

Làm cách nào để biết SSH thực sự đang gửi key nào?

ssh -v host in 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ê các fingerprint 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 đối với authorized_keys của server.

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

Vì StrictModes được bật theo mặc định, và file, thư mục .ssh hoặc thư mục home có quyền ghi cho group hoặc world, hoặc thuộc sở hữu của sai account. sshd không tin một đường dẫn mà người khác có thể thay đổi, nên xử lý như thể không có key nào tồn tại. Đặt quyền của thư mục home thành 755 hoặc chặt hơn, .ssh thành 700, authorized_keys thành 600, đồng thời đặt cả 3 mục thuộc sở hữu của login account. Khi dùng 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 nâng cấp server. Đã thay đổi điều gì?

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 đã tắt chữ ký SHA-1 của ssh-rsa, nên key chỉ có thể ký theo cách đó sẽ bị từ chối. Output verbose của client sẽ hiển thị debug1: send_pubkey_test: no mutual signature algorithm. Tạo key hiện đại bằng ssh-keygen -t ed25519 và cài đặt file .pub của key đó. Nếu cần truy cập ngay, PubkeyAcceptedAlgorithms +ssh-rsa trên server sẽ bật lại các chữ ký cũ. Bạn nên xóa dòng đó sau khi key mới hoạt động.

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

Dùng console của provider. 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 gây lỗi, hoàn tác thay đổi rồi restart service. Sau đó kiểm tra sudo sshd -T để xác nhận các giá trị đang chạy, vì file trong /etc/ssh/sshd_config.d/ có thể đang ghi đè cấu hình chính. Nếu không có local password, trước tiên hãy reset root password từ console, rồi sửa file.