SSD Nodes Learn 🎉 VPS từ $5.50/tháng
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 3 dòng đầu của ssh -v để xác định đúng lỗi và sửa mà không tự khóa quyền truy cập server.

Ý nghĩa thực sự của lỗi 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. Mạng vẫn hoạt động bình thường và sshd đang chạy. Lỗi xảy ra ở bước cuối của quá trình xác thực. Không cần sửa lỗi bằng cách đoán mò, vì ssh -v cho biết bạn đang gặp một trong 5 nguyên nhân.

Các từ trong dấu ngoặc là những phương thức mà server chấp nhận. Chỉ có Permission denied (publickey) nghĩa là đăng nhập bằng password đã bị tắt trên server đó, nên không có password để dự phòng. Permission denied (publickey,password) nghĩa là server có cho phép dùng password 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 bao quát 5 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ẽ hỗ trợ kẻ đang dò tìm các account hợp lệ. Vì vậy, đừng bắt đầu bằng cách thay key và sửa file cấu hình. Hãy chạy một command, đọc 3 dòng output, và thu hẹp 5 nguyên nhân có thể xuống còn 1.

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

Chạy lại lệnh bị lỗi, thêm -v:

ssh -v deploy@203.0.113.10

Kết quả đã rút gọn nhưng vẫn thực tế thường 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).

Ba 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ừ dòng lệnh, từ ~/.ssh/config hoặc từ tên đăng nhập cục bộ của bạn.

Authentications that can continue: publickey là danh sách các phương thức mà 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 sẽ có một dòng, trong đó ghi tên file chứa key và fingerprint SHA256 của key đó. Key không có dòng Offering thì chưa từng được gửi đến server.

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

  • Không có dòng Offering public key cho key bạn mong đợi. 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 đ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 bên dưới đượ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 kết nối bằng sai username

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

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à nhà cung cấp tạo. Tính đến tháng 8 năm 2026, image cloud Ubuntu thường có account ubuntu, image Debian có debian hoặc admin, Rocky Linux và AlmaLinux có rocky và almalinux, còn nhiều nhà cung cấp VPS cài key trực tiếp vào root. Control panel của nhà cung cấp ghi rõ 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à sẽ được ưu tiên hơn login name trên máy 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 đã được cài cho user mặc định của image nhưng chưa được sao chép sang account mới. Đây là một bước trong 10 phút đầu tiên trên VPS mới, và rất dễ bị bỏ qua.

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

Theo mặc định, ssh chỉ gửi các key do ssh-agent quản lý, cùng một danh sách cố định các tên file trong ~/.ssh: id_ed25519, id_ecdsa, id_rsa và các biến thể hardware và DSA của những tên đó. Key được lưu dưới tên ~/.ssh/vps-prod sẽ không được ssh sử dụng cho đến khi bạn chỉ rõ file đó. Vì vậy output verbose không có dòng Offering public key tương ứng.

Chỉ rõ file và ngăn các key từ agent được dùng thay thế:

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 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. Agent giữ 7 key có thể dùng hết giới hạn trước khi ssh thử đúng key, rồi thông báo sẽ chuyển thành:

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

IdentitiesOnly=yes giới hạn lần thử vào file bạn đã truyền vào. Dùng ssh-add -l để liệt kê các key agent đang giữ, và dùng ssh-add -D để xóa chúng 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 vào cấu hình để 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 đề 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 đượ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 di chuyển key qua USB stick 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 nơi lưu key và cách đặt tên cho chúng.

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

Nếu ssh -v cho thấy key đã được gửi đi nhưng server vẫn từ chối, câu hỏi tiếp theo là key đó có nằm trong file authorized_keys của account hay không. Hãy mở console của provider để 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

Chạy 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 có trong danh sách, key chưa được cài cho account đó, bất kể bạn nhớ mình đã làm gì.

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 chính xác trên một dòng. Nếu key bị xuống dòng, nó sẽ được đọc thành nhiều entry bị hỏng và không khớp với gì cả.
  • Key được ghi vào /root/.ssh/authorized_keys trong khi 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 provider 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 rỗ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 phải 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 công việc 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à giá trị mặc định của sshd. Với giá trị này, sshd từ chối đọc authorized_keys nếu file đó, thư mục .ssh hoặc thư mục home của tài khoản có thể bị bất kỳ ai không phải chủ sở hữu ghi vào. Lý do rất rõ: nếu group hoặc mọi user có quyền ghi vào thư mục home, bất kỳ tài khoản 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 có key nào tồn tại.

Client chỉ hiển thị thông báo Permission denied chung chung. Log trên server ghi lại nguyên nhân thật:

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 gì sshd chấp nhận:

  • Thư mục home: không được cho phép group ghi và không được cho phép mọi user ghi. 755, 750 và 700 đều hợp lệ. 775 và 777 không hợp lệ.
  • ~/.ssh: mode 700.
  • ~/.ssh/authorized_keys: mode 600.
  • Quyền sở hữu: cả ba phải thuộc về tài khoản dùng để đăng nhập, không phải root.

Quyền sở hữu 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 quyền sở hữu 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 theo cách bất thường có thể mang sai nhãn file, 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 nhãn, còn sudo ausearch -m avc -ts recent cho biết SELinux có phải thành phần từ chối truy cập 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 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 ưu tiên hơn mọi thay đổi bạn thực hiện ở phần thấp hơn trong file chính. Đây là lý do một thay đổi có vẻ đúng nhưng hoàn toàn không có tác dụng.

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

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

Kết quả bình thườ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 một vị trí khác, chẳng hạn /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 từ nguyên nhân 4 được áp dụng cho đường dẫn 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 đúng lỗi này mà không có giải thích. denyusers và denygroups hoạt động ngược lại.
  • Có permitrootlogin no khi bạn đang thử đă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 nhiều năm có thể ngừng hoạt động ngay sau khi server được nâng cấp. 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ư đã trình bày ở trên. Thiết lập 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, nhưng đây chỉ là cách để vào được server, không phải bước hoàn tất xử lý. Các setting phía server còn lại cần xem xét được trình bày 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 tạo từ private key. Nó không đọc file .pub nằm cạnh đó, nên cho bạn biết private key thực sự chứa gì, thay vì giá trị 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 rằng 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 biểu diễn 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à nơi xảy ra 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 nguyên nhân thực tế. Hãy chạy lệnh theo dõi log trên phiên console, rồi chạy lệnh ssh đang lỗ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 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ử đăng nhập 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 này cho biết lỗi nằm ở phía nào. Fingerprint bạn nhận ra cho biết key của bạn đã đến server nhưng bị server từ chối, nên hãy kiểm tra nguyên nhân 3, 4 và 5. Fingerprint bạn không nhận ra cho biết client đã gửi một key khác với key bạn định dùng, nê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 ở chế độ debug. Process 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 process 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 mà sshd đã mở, fingerprint mà nó đã đối chiếu 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 cách truy cập khác không phụ thuộc vào SSH. Hãy thiết lập cách này khi SSH vẫn còn hoạt động, không phải sau khi SSH đã hỏng.

  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 khẩu local đang hoạt động của một account có quyền sudo. Nếu chưa có, trước tiên hãy đặt lại mật khẩu root từ console của nhà cung cấp.
  3. Giữ nguyên phiên SSH hiện tại. 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ị lỗi.
  4. Kiểm tra cú pháp trước khi restart: sudo sshd -t không in gì nếu file hợp lệ, và in file cùng số dòng bị lỗi nếu 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 các phiên đang tồn tại, nên phiên bạn đang sử dụng không thể cho biết thay đổi có hoạt động hay không.

Restart bằng sudo systemctl restart ssh trên Debian và Ubuntu, hoặc bằng 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 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 đề; lỗi nằm ở phần cấu hình hoặc môi trường xung quanh. 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, 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 đó chưa 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. Log của server sẽ phân biệt được các trường hợp này.

Làm sao biết 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 rõ 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 riêng lẻ, 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 đó 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 thư mục home có thể cho group hoặc mọi user ghi, hoặc thuộc ownership 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ể 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 ownership của cả 3 thành login account. Với 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 đó 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 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. Hãy 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ũ. Sau khi key mới hoạt động, hãy xóa dòng đó.

Tôi đã sửa sshd_config và giờ hoàn toàn không thể đăng nhập. Làm sao 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 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.

#SSH#openssh#troubleshooting#permissions#vps