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

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ở một session thứ hai trước khi thay đổi password

Mở ngay một session SSH thứ hai và giữ kết nối đó. Gần như mọi lỗi trong hướng dẫn này chỉ mất 2 phút để xử lý khi vẫn còn một shell đã xác thực, nhưng sẽ phải truy cập console nếu session 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 thông tin xác thực 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 của nó 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 session thứ hai, đồng thời giữ session 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 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ũ. pam_unix cũng 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à chính 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 được lưu, vì vậy không có mật khẩu nào khớp với hash đó. sudo passwd -u deploy xóa ký tự này. Dùng sudo passwd -S deploy để đọc lại trạng thái.

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 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 của account vào một ngày trong năm 1970. Vì vậy, sshd sẽ từ chối đăng nhập bất kể credential nào được cung cấp. Dùng sudo usermod --expiredate '' deploy để hoàn tác.

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 release cũ vẫn có nullok trong PAM stack, 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 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 password từ script bằng chpasswd

passwd đọc dữ liệu từ terminal nên không thể được điều khiển bằng 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 password dạng plaintext vào shell history và log của CI (continuous integration). Hãy hash password trước:

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

openssl passwd -6 yêu cầu nhập password 2 lần mà không hiển thị ký tự, sau đó in ra một SHA-512 crypt hash bắt đầu bằng $6$. -e cho chpasswd biết trường thứ hai đã được hash, nên giá trị đó được ghi 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. Plaintext không bao giờ rời khỏi máy nơi bạn nhập nó.

Ubuntu 24.04 hash password mới bằng yescrypt ($y$) khi passwd đặt password, còn openssl passwd -6 tạo SHA-512. Cả hai đều được xác thực khi đăng nhập vì libxcrypt đọc được cả hai định dạng. Có thể trộn lẫn hai loại này. 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 nhận diện được tên phương thức đó. Các hash này vẫn dùng được sau khi nâng cấp release. Vì vậy, nâng cấp server 24.04 lên 26.04 không buộc bạn phải reset password 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.

Ép đổ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 đổi mật khẩu 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 chính xác cùng thao tác.

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 giai đoạn 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ẽ 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 và job chỉ báo exit code 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 đó 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.

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

Hãy thao tác từ session vẫn còn mở. 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 thông tin 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 chưa từng cung cấp phương thức xác thực bằng password. PasswordAuthentication no đang được thiết lập ở đâ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ị thực tế đang 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ỉ nhận key vẫn tiếp tục chấp nhận password được nhập bằng bàn phím.

Dòng thông báo đó cũng xuất hiện 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, thiết lập password của server chỉ là một trong năm nguyên nhân gây ra Permission denied (publickey). Output của ssh -v cho biết bạn đang gặp nguyên nhân nào.

Too many authentication failures trong thông báo disconnect nghĩa là client đã cung cấp nhiều key trước khi chuyển sang password, và server đã chạm giới hạn 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 trước đó thường 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 của nó từ chối packet thay vì drop packet. Vì vậy 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 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 user 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ó account nào trên máy chạy được sudo, hãy mở console của nhà cung cấp, 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 làm mất, recovery shell sẽ hỏi 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 hệ thống.

Vì 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 thường gặp là nhập sai 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à 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 account 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 prompt này xuất hiện khi session hiện tại vẫ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. Xác thực bằng public key không đọ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 lúc đă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 một lần khi timestamp 15 minute hết hạn.

Làm thế nào để buộc 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ó tác dụng như nhau. 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 account được script sử dụng qua SSH: khi đó lệnh không tương tác sẽ fail với Password change required but no TTY available. và không chạy.