Cách đổi mật khẩu root VPS trên Ubuntu

Cách đổi mật khẩu root của VPS trên Ubuntu

Để đổi mật khẩu root của VPS (virtual private server) trên Ubuntu, hãy mở một phiên SSH (secure shell) bằng tài khoản có thể chạy sudo, rồi chạy sudo passwd root. Lệnh yêu cầu nhập mật khẩu mới 2 lần và không yêu cầu mật khẩu cũ, vì sudo đã xác thực danh tính của bạn. Để đổi mật khẩu đăng nhập của chính bạn, hãy chạy passwd không có tham số. Lệnh sẽ yêu cầu mật khẩu hiện tại trước.

passwd                  # your own password
sudo passwd deploy      # another user's password
sudo passwd root        # root's password

Đó là toàn bộ thao tác. Phần bên dưới tập trung vào những vấn đề thường xảy ra: xác nhận mật khẩu mới hoạt động trước khi mất phiên có thể dùng để sửa lỗi, đặt mật khẩu từ script, chủ động làm mật khẩu hết hạn và đăng nhập lại khi đã mất mật khẩu.

Mở một phiên thứ hai trước khi thay đổi password

Mở ngay một phiên SSH thứ hai và để phiên đó kết nối. Hầu hết lỗi trong hướng dẫn này chỉ mất hai phút để khắc phục khi vẫn còn một shell đã xác thực hoạt động, nhưng sẽ phải truy cập console nếu phiên cuối cùng bị đóng.

Một shell đã mở vẫn tiếp tục hoạt động sau khi bạn thay đổi, khóa hoặc làm hết hạn account mà shell đó sử dụng, vì SSH kiểm tra credential khi đăng nhập và không kiểm tra lại sau đó. Ngoại lệ là sudo. Nó kiểm tra lại password thông qua PAM (pluggable authentication modules) khi timestamp hết hạn, mặc định là 15 phút sau lần prompt gần nhất. Vì vậy, password mới chỉ được kiểm tra thực tế lần đầu khi sudo yêu cầu password, không phải lúc đăng nhập.

Kiểm tra password mới trong phiên thứ hai, đồng thời giữ phiên thứ nhất mở.

Thay đổi password của bạn bằng passwd

passwd

Changing password for deploy.
Current password:
New password:
Retype new password:
passwd: password updated successfully

passwd: password updated successfully là output duy nhất cho biết hash trong /etc/shadow đã được thay thế. Bất kỳ output nào khác đều có nghĩa là password cũ vẫn còn nguyên.

Có 2 lỗi xảy ra ở đây. passwd: Authentication token manipulation error, tiếp theo là passwd: password unchanged, có nghĩa là password hiện tại bạn nhập không đúng, hoặc filesystem chứa /etc/shadow không thể ghi được. Đây là trạng thái bình thường trong recovery mode. You must choose a longer password. xuất phát từ pam_unix trong /etc/pam.d/common-password. Thành phần này áp dụng các kiểm tra về độ dài và mức độ tương đồng cho user thông thường.

Trên hầu hết VPS image, account mặc định (ubuntu hoặc tên tương ứng do provider cung cấp) không có password, mà chỉ có SSH key. passwd không có password hiện tại để kiểm tra nên không thể vượt qua prompt đầu tiên. Thay vào đó, hãy dùng sudo passwd $USER. Cách này hoạt động vì file sudoers drop-in của image cho phép account đó chạy sudo mà không cần password.

Đổi mật khẩu của người dùng khác bằng sudo passwd

sudo passwd deploy

root không được yêu cầu nhập mật khẩu cũ, và pam_unix bỏ qua các bước kiểm tra độ mạnh áp dụng cho người dùng thông thường. Vì vậy, root có thể đặt một mật khẩu mà người dùng đó không thể tự đặt.

Khóa mật khẩu là một thao tác riêng. sudo passwd -l deploy thêm một ! vào trước hash đã lưu, nên không mật khẩu nào khớp với hash đó. sudo passwd -u deploy xóa ký tự này. Đọc lại trạng thái bằng sudo passwd -S deploy.

Khóa mật khẩu không ngăn người dùng đó đăng nhập. Mọi key trong ~/.ssh/authorized_keys vẫn hoạt động, vì xác thực bằng public key không đọc /etc/shadow. Để vô hiệu hóa hoàn toàn tài khoản, hãy đặt tài khoản hết hạn:

sudo usermod --expiredate 1 deploy

Lệnh này đặt thời hạn tài khoản vào một ngày trong năm 1970, nên sshd từ chối đăng nhập bất kể credential được cung cấp là gì. Hoàn tác bằng sudo usermod --expiredate '' deploy.

Tránh dùng passwd -d. Lệnh này đặt mật khẩu rỗng thay vì khóa mật khẩu. Trên các bản phát hành cũ vẫn có nullok trong ngăn xếp PAM, mật khẩu rỗng là mật khẩu mà bất kỳ ai cũng có thể dùng.

Root có cần mật khẩu trên VPS không?

Ubuntu phát hành với tài khoản root bị khóa. /etc/shadow chứa ! thay cho một hash, còn sudo passwd -S root in ra một dòng bắt đầu bằng root L. Chưa thể đăng nhập bằng mật khẩu dưới tài khoản root cho đến khi bạn đặt mật khẩu, vì vậy image cung cấp cho bạn một user có quyền sudo. Cách nên duy trì là làm việc bằng tài khoản user đặc quyền tối thiểu trên VPS thay vì dùng root.

Đặt mật khẩu root chỉ mang lại một lợi ích cụ thể: có thể truy cập qua console của nhà cung cấp. Console đó kết nối với máy ảo bên dưới network stack, nên vẫn hoạt động khi sshd bị cấu hình sai hoặc rule của firewall không đúng. Tuy nhiên, việc này cũng có mặt hạn chế. Menu khôi phục GRUB sẽ yêu cầu mật khẩu root khi root có mật khẩu, nên công cụ dùng để đặt lại mật khẩu bị quên giờ lại nằm sau chính mật khẩu đó.

Đặt mật khẩu root không cho phép root đăng nhập qua SSH. Ubuntu phát hành với PermitRootLogin prohibit-password, nghĩa là chỉ cho phép dùng key. Hãy kiểm tra server của bạn thực sự đang sử dụng gì:

sudo sshd -T | grep -i permitrootlogin

sshd -T in ra cấu hình hiệu lực sau khi mọi dòng Include đã được xử lý, nên đây là câu trả lời chính xác duy nhất khi /etc/ssh/sshd_config.d/ chứa các file drop-in.

Đặt mật khẩu từ script bằng chpasswd

passwd đọc dữ liệu từ terminal nên không thể được điều khiển từ script. chpasswd đọc các cặp user:password từ standard input, mỗi dòng một cặp.

printf '%s:%s\n' 'deploy' "$NEW_PASSWORD" | sudo chpasswd

Cách này hoạt động, nhưng nó ghi mật khẩu dạng plaintext vào shell history và log CI (continuous integration) của bạn. Hãy hash mật khẩu trước:

HASH=$(openssl passwd -6)
printf '%s:%s\n' 'deploy' "$HASH" | sudo chpasswd -e

openssl passwd -6 yêu cầu nhập mật khẩu 2 lần mà không echo ký tự, sau đó in ra hash SHA-512 crypt bắt đầu bằng $6$. -e cho chpasswd biết field thứ 2 đã được hash, nên field này được chép nguyên trạng vào /etc/shadow. Bạn có thể lưu hash trong repository hoặc biến CI một cách an toàn. Mật khẩu dạng plaintext không bao giờ rời khỏi máy nơi bạn nhập nó.

Ubuntu 24.04 hash mật khẩu mới bằng yescrypt ($y$) khi passwd đặt mật khẩu, còn openssl passwd -6 tạo hash SHA-512. Cả hai đều được xác thực khi đăng nhập vì libxcrypt đọc được cả 2 format. Có thể trộn lẫn chúng. openssl passwd -6 hoạt động giống nhau trên mọi bản Ubuntu LTS, còn chpasswd -c YESCRYPT thì không: shadow package cũ trên 20.04 không biết tên method đó. Các hash này cũng được giữ nguyên khi nâng cấp release, vì vậy nâng server 24.04 lên 26.04 không buộc bạn phải đặt lại mật khẩu của bất kỳ ai.

Kiểm tra mật khẩu đã thực sự thay đổi như thế nào?

Trước tiên kiểm tra metadata, sau đó xác nhận bằng một lần đăng nhập.

sudo passwd -S deploy

deploy P 08/01/2026 0 99999 7 -1

Trường thứ hai là trạng thái: P nghĩa là mật khẩu có thể sử dụng, L nghĩa là tài khoản bị khóa, NP nghĩa là hoàn toàn không có mật khẩu. Ngày là thời điểm mật khẩu được thay đổi lần gần nhất, vì vậy phải là ngày hôm nay. Các số phía sau là những trường về thời hạn mật khẩu, được trình bày bên dưới.

Cách kiểm tra trực tiếp an toàn nhất là dùng chính sudo. sudo -k loại bỏ timestamp đã cache và sudo -v buộc hiển thị prompt mới. Nếu mật khẩu mới được chấp nhận ở đó, PAM đã chấp nhận mật khẩu và phiên làm việc của bạn không bị thay đổi.

sudo -k && sudo -v

Để kiểm tra tài khoản khác, chạy su - deploy từ một shell không có quyền đặc biệt. Không chạy sudo su - deploy, vì root không bao giờ được yêu cầu nhập mật khẩu nên kết quả kiểm tra không có ý nghĩa. Mật khẩu sai sẽ in ra su: Authentication failure.

Kiểm tra thực tế là đăng nhập SSH mới từ laptop của bạn, trong khi vẫn giữ phiên làm việc hiện tại mở:

ssh -o PubkeyAuthentication=no deploy@203.0.113.10

Permission denied (publickey). ở đây nghĩa là server chưa bật xác thực bằng mật khẩu, vì vậy dù đổi mật khẩu thế nào bạn cũng không thể đăng nhập bằng cách này. Permission denied, please try again. nghĩa là server có cung cấp xác thực bằng mật khẩu nhưng đã từ chối giá trị bạn nhập.

Buộc đổi mật khẩu ở lần đăng nhập tiếp theo bằng chage

sudo chage -d 0 deploy

-d 0 đặt ngày thay đổi mật khẩu gần nhất về epoch, nên PAM coi mật khẩu đã hết hạn. Ở lần đăng nhập tương tác tiếp theo, hệ thống yêu cầu nhập mật khẩu hiện tại, sau đó yêu cầu nhập mật khẩu mới rồi mới cấp shell. sudo passwd -e deploy thực hiện chính xác điều tương tự.

Chỉ dùng cách này cho các account đăng nhập tương tác bằng mật khẩu. Mật khẩu hết hạn cũng ảnh hưởng đến đăng nhập bằng key, vì sshd vẫn chạy bước account của PAM ngay cả khi key được dùng để xác thực. Một ssh deploy@203.0.113.10 'systemctl restart app' chạy bằng script sẽ gặp lỗi này rồi dừng:

Password change required but no TTY available.

Không có lệnh nào sau dòng đó được chạy tiếp, và job chỉ báo mã thoát khác 0.

Ý nghĩa của các trường về thời hạn password

sudo chage -l deploy

Last password change                                    : Aug 01, 2026
Password expires                                        : never
Password inactive                                       : never
Account expires                                         : never
Minimum number of days between password change          : 0
Maximum number of days between password change          : 99999
Number of days of warning before password expires       : 7

Các số đó là các trường từ 4 đến 8 trong dòng của user đó ở /etc/shadow. Số ngày tối thiểu (chage -m) là khoảng thời gian user phải chờ trước khi đổi password lần nữa. Thiết lập này ngăn user đổi liên tục để quay lại ngay password cũ sau khi bị buộc đổi password. Số ngày tối đa (chage -M) là thời gian password còn hiệu lực. Số ngày cảnh báo (chage -W) là thời điểm login bắt đầu hiển thị cảnh báo. Số ngày không hoạt động (chage -I) là thời gian gia hạn sau khi password hết hạn, trước khi password bị từ chối hoàn toàn. Thời hạn account (chage -E) là một ngày cố định và độc lập với password.

sudo chage -M 90 -W 14 deploy

Chỉ đặt giá trị này khi policy yêu cầu. NIST (Viện Tiêu chuẩn và Công nghệ Quốc gia Hoa Kỳ) đã khuyến nghị từ năm 2017 không nên tự động hết hạn password định kỳ, vì cách này khiến mọi người dùng các biến thể dễ đoán của cùng một password. NIST khuyến nghị buộc đổi password khi có bằng chứng cho thấy password đã bị lộ. Một password dài, duy nhất được lưu trong password manager, kết hợp với SSH dùng key, an toàn hơn chu kỳ 90 ngày.

Cần làm gì khi bạn mất mật khẩu root

Nếu bất kỳ account nào trên máy có thể chạy sudo thì không cần khôi phục gì cả: sudo passwd root sẽ đặt mật khẩu mới. Trường hợp khó là không còn login nào hoạt động.

Toàn bộ các bước dưới đây cần console của nhà cung cấp, thường được liệt kê trong hầu hết panel dưới dạng VNC (virtual network computing) hoặc serial console. Console này kết nối trực tiếp với virtual machine bên dưới network stack, nên cấu hình sshd và các rule của firewall không ảnh hưởng đến nó.

1. Reboot server từ panel và theo dõi console.
2. Mở menu GRUB. Cloud image thường đặt GRUB_TIMEOUT=0, vì vậy hãy giữ Shift khi boot bằng BIOS, hoặc nhấn liên tục Esc khi boot bằng UEFI, ngay khi quá trình reboot bắt đầu.
3. Chọn Advanced options for Ubuntu, sau đó chọn entry kết thúc bằng (recovery mode), rồi chọn root trong recovery menu.
4. Chạy mount -o remount,rw / trước. Recovery mount root filesystem ở chế độ chỉ đọc, nên nếu không chạy lệnh này thì passwd sẽ fail với passwd: Authentication token manipulation error vì không thể ghi vào /etc/shadow.
5. Chạy passwd ubuntu cho account cần đổi mật khẩu, sau đó reboot từ panel.

Nếu root đã có mật khẩu và đó chính là mật khẩu bạn bị mất, recovery shell sẽ yêu cầu mật khẩu đó và không thể tiếp tục theo cách này. Thay vào đó, hãy boot rescue image của nhà cung cấp, mount disk thật rồi đổi mật khẩu bên trong filesystem đó.

lsblk
sudo mount /dev/vda1 /mnt
sudo mount --bind /dev /mnt/dev
sudo mount --bind /proc /mnt/proc
sudo mount --bind /sys /mnt/sys
sudo chroot /mnt passwd ubuntu
sudo umount -R /mnt

Đọc layout của partition bằng lsblk thay vì sao chép /dev/vda1 từ trang này. Root partition là partition lớn. Trên image UEFI, nó nằm cạnh một EFI partition nhỏ không chứa thư mục /etc nào.

Cách xử lý khi SSH không còn chấp nhận password

Hãy làm việc từ session bạn vẫn còn. Nếu không còn session nào, hãy dùng console.

Permission denied, please try again. nghĩa là server đã cung cấp phương thức xác thực bằng password nhưng từ chối giá trị bạn gửi. Nguyên nhân thường gặp là Caps Lock đang bật hoặc layout bàn phím trên console khác với layout bạn đã dùng khi đặt password.

Permission denied (publickey). nghĩa là server chưa từng cung cấp phương thức xác thực bằng password. PasswordAuthentication no được đặt ở đâu đó; trên Ubuntu 22.04 trở lên, thiết lập này thường nằm trong một file drop-in bên dưới /etc/ssh/sshd_config.d/ và ghi đè file chính. Hãy đọc các giá trị có hiệu lực:

sudo sshd -T | grep -Ei 'passwordauthentication|kbdinteractiveauthentication|permitrootlogin'

KbdInteractiveAuthentication yes cùng với PasswordAuthentication no vẫn cho phép dùng password, vì phương thức keyboard-interactive chạy cùng PAM stack. Tắt một phương thức nhưng để phương thức còn lại bật là nguyên nhân khiến một server trông như chỉ cho phép key vẫn tiếp tục chấp nhận password được nhập thủ công.

Too many authentication failures trong thông báo ngắt kết nối nghĩa là client đã thử nhiều key trước khi chuyển sang password, và server đã chạm tới MaxAuthTries, mặc định là 6. Hãy buộc client chỉ dùng một phương thức:

ssh -o IdentitiesOnly=yes -o PubkeyAuthentication=no deploy@203.0.113.10

Connection refused trên một port vừa hoạt động cách đây một phút thường có nghĩa là fail2ban đang theo dõi SSH đã ban địa chỉ của bạn sau nhiều lần xác thực thất bại. Rule ban mặc định từ chối packet thay vì drop packet, nên kết nối bị từ chối ngay thay vì timeout. Từ console, sudo fail2ban-client status sshd liệt kê các địa chỉ đang bị ban và sudo fail2ban-client set sshd unbanip 203.0.113.10 gỡ ban cho địa chỉ của bạn.

Mật khẩu chỉ là bước trung gian, key mới là đích đến

Một mật khẩu dùng được qua SSH là mật khẩu mà mọi scanner trên Internet đều có thể thử đoán. Hãy chuyển sang xác thực bằng key để việc đoán mật khẩu không còn quan trọng. Tạo một cặp key, cài public key, rồi xác nhận key đăng nhập được từ một terminal thứ hai trước khi thay đổi bất kỳ cấu hình nào khác. Kiến thức cơ bản về quản lý SSH key trình bày cách tạo key, authorized_keys và passphrase.

Sau đó tắt xác thực bằng mật khẩu và xác nhận bằng sudo sshd -T thay vì chỉ tin vào file bạn đã chỉnh sửa. Hardening SSH trên VPS trình bày các thiết lập sshd còn lại nên thay đổi, còn 10 phút đầu tiên trên VPS mới sắp xếp chúng theo thứ tự nên thực hiện trên một server mới.

Sau đó vẫn giữ lại một mật khẩu. Server chỉ cho phép đăng nhập bằng key nhưng có cấu hình sshd bị hỏng chỉ có thể truy cập qua console của nhà cung cấp, và console đó yêu cầu username cùng mật khẩu. Một account có mật khẩu mạnh được lưu an toàn sẽ quyết định bạn chỉ mất 5 phút để sửa hay phải cài đặt lại hệ thống.

FAQ

Làm thế nào để đổi mật khẩu root trên VPS nếu tôi không biết mật khẩu cũ?

Đăng nhập bằng tài khoản có thể chạy sudo rồi chạy sudo passwd root. Lệnh này đặt mật khẩu mới mà không yêu cầu mật khẩu cũ, vì sudo đã xác thực bạn. Nếu không có tài khoản nào trên máy chạy được sudo, hãy mở provider console, reboot vào menu recovery của GRUB, chọn mục shell root, chạy mount -o remount,rw / rồi chạy passwd. Nếu root đã có mật khẩu và đó là mật khẩu bạn bị mất, recovery shell sẽ yêu cầu mật khẩu đó. Khi ấy, cách còn lại là dùng rescue image của provider, mount disk rồi chroot vào đó.

Vì sao passwd báo "Authentication token manipulation error"?

Thông báo này thường có 2 nguyên nhân. Nguyên nhân phổ biến là nhập sai tại prompt Current password:. Dòng passwd: password unchanged bên dưới xác nhận không có gì được ghi. Nguyên nhân còn lại là filesystem không thể ghi. Đây là tình huống thường gặp trong recovery mode, vì / được mount ở chế độ read-only. Chạy mount -o remount,rw / rồi thử lại.

Đổi mật khẩu Linux có đồng thời đổi mật khẩu sudo không?

Có. sudo không có mật khẩu riêng. Nó xác thực bạn qua PAM dựa trên cùng entry /etc/shadow mà SSH và su sử dụng, nên mỗi tài khoản chỉ có một mật khẩu. Vì vậy, prompt sudo đầu tiên sau khi đổi mật khẩu là lần kiểm tra thực tế. Chạy sudo -k && sudo -v để buộc xuất hiện prompt đó khi session hiện tại vẫn còn hoạt động.

Đổi mật khẩu có làm hỏng SSH key hoặc các session đang mở không?

Không. Public key authentication không bao giờ đọc /etc/shadow, nên key vẫn hoạt động sau khi đổi mật khẩu, sau passwd -l và sau chage -d 0. Các session đã mở vẫn tiếp tục hoạt động vì SSH chỉ kiểm tra thông tin xác thực khi đăng nhập. Thứ duy nhất thay đổi trong session đang hoạt động là sudo. Nó sẽ yêu cầu mật khẩu mới sau khi timestamp 15 phút hết hạn.

Làm thế nào để buộc một user đổi mật khẩu ở lần đăng nhập tiếp theo?

Chạy sudo chage -d 0 deploy hoặc sudo passwd -e deploy; hai lệnh này có cùng tác dụng. Ngày đổi mật khẩu gần nhất được lưu sẽ chuyển về epoch. PAM coi mật khẩu là đã hết hạn, và lần đăng nhập interactive tiếp theo phải đặt mật khẩu mới trước khi shell khởi động. Không thực hiện việc này với tài khoản được script sử dụng qua SSH: khi đó lệnh non-interactive sẽ fail với Password change required but no TTY available. và không được chạy.