Đổi mật khẩu root VPS trên Ubuntu bằng passwd

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

Để thay đổ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, sau đó chạy sudo passwd root. Lệnh này 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. Nếu muốn thay đổi mật khẩu đăng nhập của chính mình, hãy chạy passwd không có tham số. Lệnh này sẽ yêu cầu nhập 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 tình huống dễ phát sinh lỗi: 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 khẩu đã bị mất.

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

Hãy mở một phiên SSH thứ hai ngay bây giờ và giữ kết nối đó. Hầu hết lỗi trong hướng dẫn này chỉ mất 2 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 credential đã cache hết hạn, mặc định sau 15 phút trên Ubuntu. Khoảng thời gian này không được tính từ prompt gần nhất, vì sudo -v làm mới credential đã cache mà không yêu cầu nhập lại. Vì vậy, password mới chỉ được kiểm tra thực sự vào lần tiếp theo sudo yêu cầu password, không phải lúc đăng nhập.

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

Đổ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ế. Mọi output khác đều có nghĩa là password cũ vẫn được giữ nguyên.

Ở đây xảy ra 2 lỗi. passwd: Authentication token manipulation error, sau đó 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. Đâ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 image VPS, account mặc định (ubuntu hoặc tên tương ứng do nhà cung cấp đặt) 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 password 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 password 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 password mà chính người dùng đó không thể tự đặt.

Lock password là một thao tác riêng. sudo passwd -l deploy thêm một ! vào trước hash đã lưu, vì vậy không có password 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.

Lock password không ngăn người dùng đó đăng nhập. Mọi key trong ~/.ssh/authorized_keys vẫn hoạt động, vì public key authentication không kiểm tra password hash. Để vô hiệu hóa hoàn toàn account, hãy expire chính account đó:

sudo usermod --expiredate 1 deploy

Lệnh này đặt thời điểm hết hạn account vào một ngày trong năm 1970, vì vậy sshd sẽ từ chối đăng nhập dù credential nào được cung cấp. Khôi phục bằng sudo usermod --expiredate '' deploy.

Tránh dùng passwd -d. Lệnh này đặt password rỗng thay vì lock password. Trên các release cũ vẫn có nullok trong PAM stack, password rỗng là password mà bất kỳ ai cũng có thể sử dụng.

Root có cần password trên VPS không?

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

Đặt root password 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 này 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 firewall rule bị sai. Tuy nhiên, việc này cũng có mặt trái. Menu recovery của GRUB yêu cầu root password khi root đã có password. Vì vậy, công cụ bạn dùng để reset password bị quên giờ lại nằm sau chính password đó.

Đặt root password 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ỉ dùng key. Kiểm tra server của bạn thực sự đang dùng gì:

sudo sshd -T | grep -i permitrootlogin

sshd -T in ra cấu hình có 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ể chạy 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 sẽ ghi mật khẩu dạng plaintext vào shell history và log CI (continuous integration) của bạn. Hãy băm 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 hiển thị ký tự, sau đó in ra hash SHA-512 crypt bắt đầu bằng $6$. -e cho chpasswd biết trường thứ hai đã được băm, nên nó được chép nguyên trạng vào /etc/shadow. Bạn có thể lưu hash này an toàn trong repository hoặc biến CI; plaintext không bao giờ rời khỏi máy nơi bạn nhập nó.

Ubuntu 24.04 băm 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 định dạng. Có thể trộn lẫn 2 định dạng này. openssl passwd -6 hoạt động giống nhau trên mọi bản Ubuntu LTS từ 18.04 trở lên, còn chpasswd -c YESCRYPT thì không: shadow package cũ trên 20.04 không biết tên method đó. Ubuntu 16.04 là ngoại lệ vì OpenSSL 1.0.2 của bản này hoàn toàn không có tùy chọn -6. Các hash này vẫn dùng được sau khi nâng cấp release, nên nâng cấp server 24.04 lên 26.04 không buộc bạn phải reset mật khẩu của bất kỳ ai.

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

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 khi mật khẩu có thể sử dụng, L khi bị khóa, NP khi hoàn toàn không có mật khẩu. Ngày này là thời điểm mật khẩu được thay đổi lần cuối, vì vậy phải là ngày hôm nay. Các số sau đó là những trường về thời hạn mật khẩu, được giải thích 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à session hiện tại không bị thay đổi.

sudo -k && sudo -v

Để kiểm tra account 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 phép kiểm tra này không chứng minh được gì. Mật khẩu sai sẽ in ra su: Authentication failure.

Phép kiểm tra thực tế là đăng nhập SSH mới từ laptop của bạn, trong khi session đang làm việc vẫn mở:

ssh -o PubkeyAuthentication=no deploy@203.0.113.10

Permission denied (publickey). ở đây có nghĩa là server chưa bật xác thực bằng mật khẩu, vì vậy không có thay đổi mật khẩu nào giúp bạn đăng nhập được. Permission denied, please try again. có nghĩa là server đã cung cấp phương thức đó nhưng từ chối nội dung 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 gần nhất về epoch, để 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, rồi nhập mật khẩu mới, trước khi cấp shell. sudo passwd -e deploy thực hiện đúng thao tác này.

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 lệnh ssh deploy@203.0.113.10 'systemctl restart app' chạy trong script sẽ fail với lỗi này trước khi command được thực thi:

Password change required but no TTY available.

Remote command không bao giờ chạy và ssh thoát với mã khác 0. Nếu script gọi không dừng khi có lỗi, bằng set -e hoặc một phép kiểm tra rõ ràng, các dòng phía sau vẫn tiếp tục chạy và job có thể kết thúc như thể thao tác restart đã thành công.

Ý 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 đó trong /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. Điều này ngăn user đổi ngay về 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 các lần đăng nhập bắt đầu hiển thị cảnh báo. Số ngày không hoạt động (chage -I) là khoảng thời gian gia hạn sau khi password hết hạn, trước khi password hoàn toàn không còn được chấp nhậ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. Từ năm 2017, NIST (Viện Tiêu chuẩn và Công nghệ Quốc gia Hoa Kỳ) đã khuyến cáo không nên thường xuyên buộc password hết hạn, vì cách này khiến người dùng chọn 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ộ quy trình dưới đây cần provider console, thường được liệt kê trong hầu hết panel là VNC (virtual network computing) hoặc serial console. Console 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à 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 trên BIOS, hoặc nhấn liên tục Esc khi boot trên 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 khôi phục, rồi reboot từ panel.

Nếu root đã có password và đó chính là password bạn bị mất, recovery shell sẽ yêu cầu password này và cách trên không dùng được. Thay vào đó, hãy boot provider rescue image, mount disk thật rồi đổi password 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 UEFI image, nó nằm cạnh một EFI partition nhỏ và partition này hoàn toàn không chứa thư mục /etc.

Việc cần làm khi SSH không còn chấp nhận password

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 nội dung bạn gửi. Các nguyên nhân thường gặp là bật Caps Lock 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 không cung cấp phương thức xác thực bằng password, nên giá trị hiệu lực là PasswordAuthentication no. no đó có thể nằm trong file chính hoặc trong drop-in, vì vậy hãy kiểm tra cả hai. sshd đọc các file bên dưới /etc/ssh/sshd_config.d/ khi bắt đầu nạp cấu hình và giữ giá trị đầu tiên tìm thấy cho mỗi keyword, nên drop-in sẽ ghi đè /etc/ssh/sshd_config. Quy tắc tương tự thường hoạt động theo chiều ngược lại trên các server Ubuntu 24.04 được cài từ ISO với SSH đã bật: trình cài đặt để lại một drop-in của cloud-init là 50-cloud-init.conf, đặt PasswordAuthentication yes, nên một no được thêm vào file chính sẽ bị bỏ qua. Đọc các giá trị 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 kia bật là nguyên nhân khiến một server có vẻ chỉ cho phép key vẫn tiếp tục chấp nhận password được nhập bằng bàn phím.

Dòng đó cũng là thông báo được in ra khi đăng nhập bằng key bị từ chối. Vì vậy, nếu bạn đang cung cấp key thay vì password, cấu hình password của server chỉ là một trong năm lỗi gây ra Permission denied (publickey), và output của ssh -v cho biết bạn đang gặp lỗi nào.

Too many authentication failures trong thông báo disconnect nghĩa là connection đã dùng hết giới hạn MaxAuthTries của server, mặc định là 6 lần thử. Nguyên nhân thường gặp là client đã cung cấp nhiều key trước khi chuyển sang password. Ép 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 bình thường thường nghĩa là fail2ban đang theo dõi SSH đã ban địa chỉ của bạn sau nhiều lần đăng nhập 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 nhanh 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 khẩu hoạt động qua SSH là thứ mà mọi scanner trên Internet đều có thể đoán. Hãy chuyển sang xác thực bằng key; khi đó việc đoán mật khẩu không còn đáng kể. Tạo một cặp key, cài public key, rồi xác nhận key có thể đăng nhập từ một terminal thứ hai trước khi thay đổi bất kỳ thứ gì 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 đã sửa. Hardening SSH trên VPS trình bày các thiết lập sshd còn lại đáng thay đổi, còn 10 phút đầu tiên trên một VPS mới sắp xếp chúng theo thứ tự nên thực hiện trên server mới.

Sau đó vẫn nên giữ 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ị lỗi 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 việc khắc phục mất 5 phút hay phải cài đặt lại hệ thống.

FAQ

Làm cách 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 hỏi 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 có thể chạy sudo, hãy mở console của nhà cung cấp, reboot vào menu khôi phục 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 nhà cung cấp, mount disk rồi chroot vào đó.

Tại sao passwd báo "Authentication token manipulation error"?

Có 2 nguyên nhân gây ra thông báo này. Nguyên nhân phổ biến là nhập sai câu trả lời tại prompt Current password:; dòng passwd: password unchanged bên dưới xác nhận rằng không có gì được ghi. Nguyên nhân còn lại là filesystem không thể ghi. Đây là trường hợp thường gặp trong recovery mode, vì / được mount ở chế độ chỉ đọc tại đó. 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 bằng entry /etc/shadow, cũng là entry được 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à phép kiểm tra thực tế. Chạy sudo -k && sudo -v để buộc xuất hiện prompt đó khi bạn vẫn còn một session đang 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. Việc đổi mật khẩu hoặc passwd -l không làm hỏng chúng. Xác thực bằng public key không kiểm tra password hash, nên key vẫn hoạt động sau cả hai thao tác. chage -d 0 là trường hợp khác: sshd vẫn chạy các kiểm tra account của PAM sau khi đăng nhập bằng key. Các kiểm tra này đọc thông tin aging của mật khẩu trong /etc/shadow. Vì vậy, mật khẩu hết hạn khiến lần đăng nhập bằng key yêu cầu đặt mật khẩu mới và khiến các lệnh SSH chạy bằng script thất bại. 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. Thay đổi duy nhất trong một session đang hoạt động là sudo. Lệnh này yêu cầu nhập mật khẩu mới một lần khi timestamp 15 minute hết hạn.

Làm cách nào để buộc người dùng đổ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 cuối cùng được lưu sẽ chuyển về epoch. PAM coi mật khẩu đã hết hạn, và lần đăng nhập tương tác 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 không tương tác sẽ thất bại với Password change required but no TTY available. và không chạy.