Cách đổi mật khẩu root VPS Ubuntu qua SSH

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

Để thay đổi mật khẩu root cho VPS (máy chủ riêng ảo) trên Ubuntu, hãy mở một phiên SSH (secure shell) với tư cách là người dùng có quyền chạy sudo, sau đó chạy sudo passwd root. Hệ thống sẽ yêu cầu nhập mật khẩu mới hai lần và không bao giờ hỏi mật khẩu cũ, vì sudo đã xác thực danh tính của bạn trước đó. Để thay đổi mật khẩu đăng nhập của chính bạn, hãy chạy passwd mà không cần đối số, hệ thống sẽ yêu cầu bạn 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. Mọi nội dung bên dưới là những phần dễ xảy ra lỗi: kiểm tra xem mật khẩu mới có hoạt động hay không trước khi bạn làm mất phiên làm việc có thể dùng để sửa lỗi, thiết lập mật khẩu từ script, chủ động làm hết hạn mật khẩu và cách truy cập lại khi đã mất mật khẩu.

Mở phiên làm việc thứ hai trước khi thay đổi mật khẩu

Hãy mở một phiên SSH thứ hai ngay bây giờ và giữ kết nối. Hầu như mọi lỗi trong hướng dẫn này đều có thể khắc phục trong hai phút nếu vẫn còn một shell đã xác thực, thay vì phải truy cập vào console sau khi phiên làm việc cuối cùng bị đóng.

Một shell đang mở vẫn hoạt động bình thường sau khi bạn thay đổi, khóa hoặc đặt hết hạn tài khoản đó, vì SSH chỉ kiểm tra thông tin đăng nhập tại thời điểm đăng nhập và không kiểm tra lại sau đó. Ngoại lệ là sudo. Nó sẽ kiểm tra lại mật khẩu của bạn thông qua PAM (pluggable authentication modules) khi dấu thời gian hết hạn, mặc định là 15 phút sau lần nhắc cuối cùng. Do đó, mật khẩu mới sẽ được kiểm tra thực tế vào lần tiếp theo sudo yêu cầu, chứ không phải tại thời điểm đăng nhập.

Hãy kiểm tra mật khẩu mới trong phiên làm việc thứ hai trong khi phiên thứ nhất vẫn đang mở.

Thay đổi mật khẩu của chính 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à kết quả đầu ra duy nhất cho thấy mã hash trong /etc/shadow đã được thay thế. Bất kỳ kết quả nào khác đều có nghĩa là mật khẩu cũ vẫn được giữ nguyên.

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

Trên hầu hết các image VPS, tài khoản mặc định (ubuntu, hoặc bất kỳ tên nào mà nhà cung cấp của bạn phát hành) không có mật khẩu, chỉ có SSH key. passwd không có mật khẩu hiện tại để đối chiếu, vì vậy nó không thể vượt qua prompt đầu tiên. Hãy sử dụng sudo passwd $USER thay thế, lệnh này hoạt động vì tệp cấu hình sudoers của image cho phép tài khoản đó chạy sudo mà không cần mật khẩu.

Thay đổi mật khẩu người dùng khác bằng sudo passwd

sudo passwd deploy

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

Khóa tài khoản là một hành động riêng biệt. sudo passwd -l deploy đặt một ! vào phía trước mã hash đã lưu, do đó không có mật khẩu nào khớp với nó. sudo passwd -u deploy sẽ xóa ký tự này. Kiểm tra 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. Bất kỳ key nào trong ~/.ssh/authorized_keys của họ vẫn hoạt động, vì xác thực bằng public key không bao giờ đọc /etc/shadow. Để chặn hoàn toàn một tài khoản, hãy đặt hết hạn tài khoản đó:

sudo usermod --expiredate 1 deploy

Lệnh này đặt ngày hết hạn tài khoản về năm 1970, vì vậy sshd sẽ từ chối đăng nhập bất kể thông tin xác thực nào được cung cấp. 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 trống thay vì khóa tài khoản, và trên các bản phát hành cũ vẫn còn chứa nullok trong PAM stack, mật khẩu trống là mật khẩu mà bất kỳ ai cũng có thể sử dụng.

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

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

Việc thiết lập mật khẩu root mang lại một lợi ích cụ thể: một lối vào thông qua console của nhà cung cấp. Console đó kết nối với máy ảo bên dưới stack mạng, vì vậy nó vẫn hoạt động khi sshd bị cấu hình sai hoặc quy tắc firewall bị lỗi. Nó cũng gây ra một cái giá phải trả. Root shell trong menu khôi phục GRUB sẽ yêu cầu mật khẩu root khi root đã có mật khẩu, vì vậy công cụ bạn dùng để reset mật khẩu bị quên giờ đây lại nằm sau chính mật khẩu đó.

Việc thiết lập mật khẩu root không cho phép root đăng nhập qua SSH. Ubuntu xuất xưởng PermitRootLogin prohibit-password, nghĩa là chỉ chấp nhận key. Hãy kiểm tra xem 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 dụng sau khi mọi dòng Include được giải quyết, vì vậy đây là câu trả lời trung thực duy nhất khi /etc/ssh/sshd_config.d/ chứa các file drop-in.

Thiết lập mật khẩu từ script với chpasswd

passwd đọc từ terminal và không thể điều khiển được từ script. chpasswd đọc các cặp user:password từ đầu vào tiêu chuẩn (standard input), mỗi cặp một dòng.

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

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

Ubuntu 24.04 băm các mật khẩu mới bằng yescrypt ($y$) khi passwd thiết lập chúng, trong khi openssl passwd -6 cung cấp cho bạn SHA-512. Cả hai đều xác thực được khi đăng nhập vì libxcrypt đọc được cả hai định dạng. Việc trộn lẫn chúng là bình thường, và openssl passwd -6 hoạt động giống nhau trên mọi bản phát hành Ubuntu LTS, điều mà chpasswd -c YESCRYPT không làm được: gói shadow cũ hơn trên 20.04 không nhận diện được tên phương thức đó.

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

Bắt đầu với metadata, sau đó xác nhận bằng cách đă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 cho mật khẩu có thể sử dụng, L cho mật khẩu bị khóa, NP cho trường hợp không có mật khẩu. Ngày tháng là thời điểm mật khẩu thay đổi lần cuối, vì vậy nó phải hiển thị ngày hôm nay. Các con số phía sau là các trường aging được đề cập bên dưới.

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

sudo -k && sudo -v

Để kiểm tra một tài khoản khác, hãy chạy su - deploy từ một shell không có quyền root. Đừng chạy sudo su - deploy, vì root không bao giờ bị yêu cầu nhập mật khẩu và bài kiểm tra đó không có giá trị. Mật khẩu sai sẽ in ra thông báo su: Authentication failure.

Bài kiểm tra thực tế là thực hiện một phiên SSH mới từ laptop của bạn, trong khi phiên làm việc hiện tại vẫn đang mở:

ssh -o PubkeyAuthentication=no deploy@203.0.113.10

Permission denied (publickey). ở đây có nghĩa là server không cung cấp phương thức xác thực bằng mật khẩu, vì vậy việc thay đổi mật khẩu sẽ không 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 mật khẩu bạn đã nhập.

Buộc thay đổ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 cuối cùng về mốc epoch, vì vậy PAM coi mật khẩu đã hết hạn. Lần đăng nhập tương tác tiếp theo sẽ yêu cầu mật khẩu hiện tại, sau đó là mật khẩu mới, trước khi cấp quyền truy cập shell. sudo passwd -e deploy thực hiện chính xác điều tương tự.

Chỉ sử dụng lệnh này cho các tài khoản đă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 việc đăng nhập bằng key, vì sshd chạy giai đoạn tài khoản PAM ngay cả khi key đã xác thực thành công. Một tiến trình ssh deploy@203.0.113.10 'systemctl restart app' được lập lịch sau đó sẽ thất bại với lỗi này và dừng lại:

Password change required but no TTY available.

Không có lệnh nào sau dòng đó được thực thi và tác vụ chỉ báo cáo mã thoát khác 0.

Ý nghĩa các trường thiết lập thời hạn mật khẩu

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 con số này là trường thứ 4 đến thứ 8 trong dòng của người dùng đó tại /etc/shadow. Số ngày tối thiểu (chage -m) là khoảng thời gian người dùng phải chờ trước khi được phép đổi mật khẩu lần nữa, giúp ngăn chặn việc người dùng đổi ngay về mật khẩu cũ sau khi bị ép buộc thay đổi. Số ngày tối đa (chage -M) là thời hạn mật khẩu còn hiệu lực. Số ngày cảnh báo (chage -W) là thời điểm hệ thống bắt đầu hiển thị cảnh báo khi đăng nhập. Số ngày không hoạt động (chage -I) là thời gian ân hạn sau khi mật khẩu hết hạn trước khi tài khoản bị khóa hoàn toàn. Ngày hết hạn tài khoản (chage -E) là một mốc thời gian cố định và không phụ thuộc vào mật khẩu.

sudo chage -M 90 -W 14 deploy

Chỉ thiết lập các giá trị này khi chính sách 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 ép buộc thay đổi mật khẩu định kỳ, vì điều này khiến người dùng có xu hướng đặt các biến thể dễ đoán của một mật khẩu cũ. Thay vào đó, NIST khuyến nghị chỉ nên ép buộc thay đổi khi có bằng chứng về việc tài khoản bị xâm nhập. Một mật khẩu dài, duy nhất được lưu trong trình quản lý mật khẩu, kết hợp với xác thực SSH bằng key, sẽ hiệu quả hơn nhiều so với chu kỳ 90 ngày.

Phải làm gì khi mất mật khẩu root

Nếu bất kỳ tài khoản nào trên máy chủ có thể chạy sudo, bạn không cần khôi phục gì cả: sudo passwd root sẽ thiết lập mật khẩu mới. Trường hợp khó khăn là khi bạn không thể đăng nhập bằng bất kỳ tài khoản nào.

Mọi thao tác dưới đây đều cần dùng đến console của nhà cung cấp, thường hiển thị trong bảng điều khiển dưới dạng VNC (virtual network computing) hoặc serial console. Nó kết nối trực tiếp với máy ảo bên dưới ngăn xếp mạng, vì vậy các thiết lập sshd và quy tắc firewall không ảnh hưởng đến nó.

1. Khởi động lại server từ bảng điều khiển và theo dõi console.
2. Truy cập menu GRUB. Các image trên cloud thường thiết lập GRUB_TIMEOUT=0, vì vậy hãy giữ phím 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 khởi động bắt đầu.
3. Chọn Advanced options for Ubuntu, sau đó chọn mục kết thúc bằng (recovery mode), rồi chọn root trong menu khôi phục.
4. Chạy mount -o remount,rw / trước tiên. Chế độ khôi phục mount hệ thống tệp root ở trạng thái chỉ đọc (read-only), nếu không có lệnh này, passwd sẽ thất bại với lỗi passwd: Authentication token manipulation error vì không thể ghi vào /etc/shadow.
5. Chạy passwd ubuntu cho tài khoản bạn cần, sau đó khởi động lại từ bảng điều khiển.

Nếu root đã có mật khẩu và đó là mật khẩu bạn bị mất, shell khôi phục sẽ yêu cầu nhập mật khẩu đó và con đường này sẽ bị chặn. Thay vào đó, hãy boot từ image cứu hộ (rescue image) của nhà cung cấp, sau đó mount ổ đĩa thực và thay đổi mật khẩu bên trong đó.

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

Hãy đọc cấu trúc phân vùng từ lsblk thay vì sao chép /dev/vda1 từ trang này. Phân vùng root là phân vùng có dung lượng lớn. Trên image UEFI, nó nằm cạnh một phân vùng EFI nhỏ, nơi không chứa thư mục /etc nào cả.

Phải làm gì khi SSH từ chối mật khẩu của bạn

Hãy làm việc từ phiên SSH bạn vẫn đang mở. Nếu không còn phiên nào, hãy sử 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 mật khẩu nhưng từ chối thông tin bạn gửi. Nguyên nhân thường gặp là do bật caps lock, hoặc layout bàn phím trên console khác với layout bạn đã dùng khi thiết lập mật khẩu.

Permission denied (publickey). nghĩa là server không cung cấp phương thức xác thực bằng mật khẩu. PasswordAuthentication no được thiết lập ở đâu đó, và trên Ubuntu 22.04 trở về sau, nó thường nằm trong một file cấu hình con tại /etc/ssh/sshd_config.d/, ghi đè lên file chính. Hãy đọc các giá trị thực tế đang áp dụng:

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

KbdInteractiveAuthentication yes đi kèm với PasswordAuthentication no vẫn cho phép mật khẩu đi qua, vì phương thức keyboard-interactive chạy cùng một PAM stack. Việc tắt cái này nhưng để cái kia bật là lý do khiến một server trông có vẻ chỉ dùng key nhưng vẫn chấp nhận mật khẩu gõ tay.

Too many authentication failures trong thông báo ngắt kết nối nghĩa là client của bạn đã gửi thử vài key trước khi đến lượt mật khẩu, và server đã chạm ngưỡng MaxAuthTries, mặc định là 6. Hãy ép buộc sử dụng một phương thức duy nhất:

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 giám sát SSH đã cấm địa chỉ IP của bạn sau nhiều lần thử sai. Quy tắc cấm mặc định của nó từ chối gói tin thay vì drop nó, đó là lý do tại sao thông báo từ chối trả về nhanh chóng thay vì bị timeout. Từ console, sudo fail2ban-client status sshd liệt kê các địa chỉ bị cấm và sudo fail2ban-client set sshd unbanip 203.0.113.10 sẽ xóa địa chỉ của bạn khỏi danh sách đó.

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

Mật khẩu dùng cho SSH là thứ mà mọi trình quét trên internet đều có thể đoán được. Hãy chuyển sang xác thực bằng key, khi đó việc đoán mật khẩu sẽ không còn ý nghĩa. Hãy tạo một cặp key, cài đặt phần public key, và xác nhận rằng key cho phép bạn đăng nhập từ một terminal thứ hai trước khi thay đổi bất kỳ thứ gì khác. Các kiến thức cơ bản về quản lý SSH key bao gồm việc tạo key, authorized_keys và cụm mật khẩu (passphrase).

Sau đó, hãy tắt xác thực bằng mật khẩu và xác nhận lại bằng sudo sshd -T thay vì chỉ tin tưởng vào file bạn vừa chỉnh sửa. Củng cố bảo mật SSH trên VPS sẽ hướng dẫn bạn các thiết lập sshd khác cần thay đổi, và Mười phút đầu tiên trên một VPS mới sắp xếp các bước này theo thứ tự cần thực hiện trên một server mới.

Hãy giữ lại một mật khẩu sau đó. Một server chỉ dùng key với cấu hình sshd bị lỗi sẽ chỉ có thể truy cập thông qua console của nhà cung cấp, và console đó yêu cầu tên người dùng cùng mật khẩu. Một tài khoản có mật khẩu mạnh được lưu trữ an toàn chính là thứ giúp bạn phân biệt giữa việc sửa lỗi trong năm phút và việc phải cài đặt lại toàn bộ 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ũ?

Hãy đăng nhập bằng một người dùng có quyền chạy sudo và thực thi sudo passwd root. Lệnh này thiết lập 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 trước đó. Nếu không có tài khoản nào trên máy có quyền chạy sudo, hãy mở bảng điều khiển của nhà cung cấp, khởi động lại vào menu khôi phục GRUB, chọn mục shell root, chạy mount -o remount,rw /, sau đó chạy passwd. Nếu root đã có mật khẩu và bạn bị mất mật khẩu đó, shell khôi phục sẽ yêu cầu nhập mật khẩu cũ, và phương án còn lại là sử dụng image cứu hộ của nhà cung cấp với đĩa được mount và chroot.

Tại sao lệnh passwd báo lỗi "Authentication token manipulation error"?

Có hai nguyên nhân gây ra thông báo đó. Nguyên nhân phổ biến là do trả lời sai tại lời nhắc Current password:, và dòng passwd: password unchanged bên dưới xác nhận không có dữ liệu nào được ghi. Nguyên nhân khác là do hệ thống tệp không thể ghi được, đây là tình trạng bạn gặp phải ở chế độ khôi phục, vì / được mount ở chế độ chỉ đọc (read-only). Hãy chạy mount -o remount,rw / và thử lại.

Việc đổi mật khẩu Linux có làm thay đổi mật khẩu sudo của tôi không?

Có. sudo không có mật khẩu riêng. Nó xác thực bạn thông qua PAM dựa trên cùng mục nhập /etc/shadow mà SSH và su sử dụng, vì vậy mỗi tài khoản chỉ có một mật khẩu duy nhất. Đó cũng là lý do tại sao lời nhắc sudo đầu tiên sau khi đổi mật khẩu là bài kiểm tra thực tế. Hãy chạy sudo -k && sudo -v để buộc xuất hiện lời nhắc đó trong khi bạn vẫn đang có một phiên làm việc hoạt động.

Việc đổi mật khẩu có làm hỏng các SSH key hoặc các phiên làm việc đang mở của tôi không?

Không. Xác thực bằng public key không bao giờ đọc /etc/shadow, vì vậy các key vẫn hoạt động bình thường sau khi đổi mật khẩu, sau passwd -l, và sau chage -d 0. Các phiên làm việc đang mở vẫn tiếp tục hoạt động, vì SSH chỉ kiểm tra thông tin xác thực tại thời điểm đăng nhập. Điều duy nhất thay đổi bên trong một phiên làm việc đang hoạt động là sudo, nó sẽ yêu cầu mật khẩu mới một lần sau khi hết thời gian chờ 15 phút.

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

Hãy chạy sudo chage -d 0 deploy, hoặc sudo passwd -e deploy, cả hai đều có tác dụng tương tự. Ngày thay đổi mật khẩu gần nhất được chuyển về mốc epoch, PAM coi mật khẩu đã hết hạn, và lần đăng nhập tương tác tiếp theo bắt buộc phải thiết lập mật khẩu mới trước khi shell khởi động. Đừng thực hiện việc này với tài khoản được sử dụng bởi các script qua SSH: một lệnh không tương tác sẽ thất bại với lỗi Password change required but no TTY available. và không bao giờ chạy được.