Có một sự thật mà dân làm运维 (vận hành) ai cũng từng nếm trải: đó là cái cảm giác đứng trước màn hình SSH, gõ password mà nó cứ báo “Access denied”. Trong khi server thì đang chạy ngon lành, log thì đầy lỗi cần xử lý gấp.
Tôi nhớ có lần phải thức đến 2 giờ sáng chỉ vì quên mật khẩu của một instance EC2 chạy production. Mà AWS thì không có cái nút “Forgot password” như Facebook đâu nhé.Bài viết này tôi viết dựa trên kinh nghiệm thực chiến và tham khảo từ các nguồn đáng tin cậy, bao gồm cả những chia sẻ từ cộng đồng AWS trên Reddit và các chuyên gia bảo mật tại Việt Nam. Mục tiêu là giúp bạn hiểu rõ bản chất việc đổi mật khẩu trên EC2, tránh những sai lầm cơ bản mà ngay cả dân có kinh nghiệm cũng có thể vấp phải.Hiểu đúng về “mật khẩu” trên EC2 Không phải chuyện đơn giản
Nhiều người mới sang AWS từ các hạ tầng truyền thống thường bị “ngợp” vì cách quản lý truy cập ở đây khác hẳn. Trên một VPS bình thường, bạn có username + password là xong.
Nhưng với EC2, câu chuyện nó phức tạp hơn nhiều. Thực tế là EC2 instance của bạn không hề có khái niệm “mật khẩu mặc định” như nhiều người lầm tưởng.Khi tạo instance, bạn phải chọn một cặp key pair (.pem hoặc .ppk) để SSH vào lần đầu. Nếu mất cái key đó mà chưa từng đặt password cho userec2-user hay ubuntu, thì coi như bạn đã “tự nhốt mình ngoài cửa”.Một trường hợp điển hình được chia sẻ trên Reddit r/aws vào tháng 7/2024: một người dùng tạo instance với user dev, không có quyền sudo, không đặt mật khẩu, rồi sau đó không thể leo quyền root. Đây là tình huống cực kỳ phổ biến khi doanh nghiệp phân quyền theo nhóm mà không tính toán trước đường “thoát hiểm”.Dưới đây là bảng so sánh các cách truy cập EC2 mà tôi tổng hợp từ kinh nghiệm và các nguồn tham khảo:
| Kiểu truy cập | Đặc điểm chính | Dùng khi nào |
|---|---|---|
| Key pair (.pem) | File private key, không có password | Lần đầu SSH, bảo mật cao |
| Password user | Đặt bằng cloud-init hoặc thủ công | Cần đăng nhập console hoặc SSH |
| IAM Role | Không cần key/password | EC2 gọi API AWS service khác |
| Session Manager | Qua AWS Console, không cần mở port 22 | Quản trị từ xa an toàn |
Chính vì sự phức tạp này mà nhiều người tìm đến cách đổi mật khẩu EC2 AWS như một “phao cứu sinh”. Nhưng khoan, trước khi đi vào chi tiết kỹ thuật, chúng ta cần phân biệt rõ: bạn đang muốn đổi mật khẩu cho user hệ điều hành trên instance, hay đang muốn đổi mật khẩu cho tài khoản AWS (root account hoặc IAM user)?
Nếu là tài khoản AWS, bạn có thể đổi trực tiếp qua console. Còn nếu là user trên EC2, câu chuyện sẽ cần nhiều bước hơn.Phần tiếp theo tôi sẽ nói kỹ về khác biệt giữa tài khoản root AWS và IAM user, vì nhiều người nhầm lẫn hai khái niệm này dẫn đến việc sửa sai đối tượng.Phân biệt Root Account và IAM User Nhiều người nhầm đến mức “khóc thét”
Tôi từng gặp một khách hàng – anh chàng tự xưng là “dân AWS 5 năm” – gọi điện hỏi: “Sao tao đổi mật khẩu root mà vẫn không vào được EC2?”. Nghe xong tôi chỉ biết cười trừ.
Bạn thấy đó, cái gọi là “root account” trong AWS với userroot trên Linux là hai thứ hoàn toàn khác nhau. Theo tài liệu từ CMC Telecom (Advanced Tier Services Partner của AWS tại Việt Nam), AWS Account Root User là tài khoản gốc đăng ký AWS, có quyền kiểm soát cao nhất.Tài khoản này được tạo bằng email và mật khẩu khi bạn đăng ký. Nó có thể làm những việc mà không ai khác làm được, ví dụ như thay đổi cài đặt tài khoản, khôi phục quyền IAM khi bị khóa, hoặc kích hoạt quyền truy cập IAM vào billing.Còn IAM User là người dùng được tạo ra từ root account, có quyền hạn do admin phân quyền. Mỗi IAM user có thể có mật khẩu riêng để vào AWS console, hoặc access key để dùng CLI/SDK.Họ không có toàn quyền như root, mà chỉ được phép làm những gì policy cho phép. Cùng xem bảng phân biệt nhanh:
| Đặc điểm | Root User | IAM User |
|---|---|---|
| Quyền tối đa | Toàn quyền | Theo policy gán |
| Xác thực | Email + mật khẩu | Mật khẩu + MFA |
| Access key | Không nên tạo | Có thể tạo |
| Mục đích | Quản trị tài khoản | Hoạt động hàng ngày |
Điều quan trọng cần nhấn mạnh: việc đổi mật khẩu root account hoặc IAM user không hề ảnh hưởng đến việc SSH vào EC2 instance. Vì EC2 dùng key pair hoặc mật khẩu của user Linux (như ec2-user, ubuntu, centos), hoàn toàn tách biệt với hệ thống IAM.
Cách xử lý khi “kẹt cứng” không vào được EC2 Chi tiết từng bước
Đây là phần tôi muốn chia sẻ kỹ nhất, vì nó giải quyết đúng nỗi đau của nhiều người: mất key pair hoặc quên mật khẩu user Linux. Có một cách “kinh điển” mà dân AWS nào cũng biết: đó là detach volume từ instance cũ, gắn vào instance mới để sửa file cấu hình, rồi gắn ngược lại.
Tôi nhớ lần đầu làm việc này, tôi cứ tưởng phải “cầu cứu” AWS support. Nhưng thực ra quy trình khá đơn giản nếu bạn làm đúng thứ tự.Dưới đây là các bước tôi đúc kết từ kinh nghiệm và tham khảo từ cộng đồng:Bước 1: Tạo instance “cứu hộ” Bạn cần một EC2 instance mới (cùng AMI hoặc cùng hệ điều hành) để làm bàn đạp. Instance này sẽ dùng để gắn volume của instance “bị khóa” vào và chỉnh sửa.
Bước 2: Detach volume gốc từ instance cũ Vào EC2 Console → chọn instance bị lỗi → chọn volume gốc (thường là/dev/xvda hoặc /dev/sda1) → Detach. Lưu ý là instance phải ở trạng thái stopped.Bước 3: Attach volume vào instance cứu hộ
Gắn volume vừa detach vào instance mới với tên thiết bị như /dev/sdf. Sau đó SSH vào instance cứu hộ và mount volume này.Bước 4: Sửa file cấu hình sudoers
Khi đã mount thành công, bạn cần sửa file /etc/sudoers hoặc tạo file mới trong /etc/sudoers.d/ để thêm quyền sudo cho user hiện tại. Cụ thể, thêm dòng:
username ALL=(ALL) NOPASSWD:ALL
Điều này cho phép user đó SSH vào mà không cần mật khẩu sudo. Bước 5: Đặt mật khẩu mới hoặc sửa key
Nếu muốn đặt mật khẩu mới, bạn có thể chroot vào volume và chạy lệnh passwd username.
/home/username/.ssh/authorized_keys. Bước 6: Gắn lại volume và khởi động
Sau khi hoàn tất, detach volume khỏi instance cứu hộ, gắn lại vào instance gốc với đúng tên thiết bị ban đầu, rồi start instance lên.Một mẹo quan trọng mà tôi học được từ Reddit: hãy luôn kiểm tra file /etc/ssh/sshd_config để chắc chắn rằng cấu hình PasswordAuthentication được bật (nếu bạn muốn SSH bằng mật khẩu). Nhiều bản AMI mặc định tắt tính năng này, nên dù bạn có đặt mật khẩu mới cũng không thể đăng nhập được.
| Bước thao tác | Mục đích | Lưu ý |
|---|---|---|
| Stop instance | Ngăn ghi dữ liệu | Bắt buộc trước khi detach |
| Detach volume | Tách khỏi instance | Ghi nhớ tên thiết bị |
| Attach vào máy cứu hộ | Truy cập file system | Dùng tên khác như /dev/sdf |
| Sửa sudoers | Cấp quyền sudo | Cú pháp phải chính xác |
| Đặt password | Tạo mật khẩu mới | Kiểm tra sshd_config |
| Gắn lại volume | Khôi phục instance | Đúng tên thiết bị ban đầu |
Cách này hơi thủ công nhưng hiệu quả 100%, không cần liên hệ support AWS. Tuy vậy, có một phương án khác nhanh hơn và an toàn hơn nhiều, đó là dùng AWS Systems Manager Session Manager.
Với Session Manager, bạn không cần mở port 22, không cần key pair, mà vẫn SSH vào được instance – miễn là instance có cài SSM agent và được gán IAM role phù hợp. Nếu bạn đang dùng instance Linux, cách này giúp bạn “cứu” instance mà không cần detach volume.Tôi sẽ nói rõ hơn về cách phòng tránh và các lỗi thường gặp trong phần tiếp theo, vì “phòng bệnh hơn chữa bệnh” mà.Kinh nghiệm phòng tránh và những lỗi “ngớ ngẩn” dễ mắc phải
Sau nhiều năm làm việc với AWS, tôi nhận ra rằng hầu hết các sự cố về mật khẩu EC2 đều xuất phát từ những sai lầm rất cơ bản. Không phải do kỹ thuật phức tạp, mà do quy trình làm việc thiếu chặt chẽ.
Bài học đầu tiên: đừng bao giờ tạo IAM user mà không có kế hoạch dự phòng. Tôi từng chứng kiến một team phát triển phần mềm tạo userdev trên EC2, không cho quyền sudo, rồi một hôm cần cài thêm package nhưng không thể vì không có mật khẩu.Họ không biết rằng user dev này chưa từng được đặt password, nên mọi lệnh sudo đều báo lỗi. Câu chuyện tương tự như bài đăng trên Reddit tôi đề cập ở đầu bài.Bài học thứ hai: quy trình lưu trữ key pair phải nghiêm túc. Nhiều người để file .pem trong thư mục Downloads, rồi khi máy tính hỏng là “mất trắng”.Tôi khuyến khích bạn nên lưu key pair vào nơi an toàn như password manager (ví dụ: 1Password, Bitwarden) hoặc ít nhất là một ổ cứng mã hóa riêng. Đồng thời, hãy tạo một second key pair ngay từ đầu và thêm public key vào instance để phòng hờ.Một sai lầm phổ biến nữa là không kiểm tra sshd_config sau khi đổi mật khẩu. Bạn có thể đặt mật khẩu mới thành công nhưng vẫn không SSH vào được vì Amazon Linux 2 và Ubuntu mặc định tắt PasswordAuthentication.Hãy chắc chắn sửa dòng PasswordAuthentication yes trong /etc/ssh/sshd_config và restart sshd service. Về phía tài khoản AWS, các chuyên gia từ CMC Telecom cũng đưa ra khuyến nghị rất cụ thể.Họ nhấn mạnh việc sử dụng MFA cho cả root account lẫn IAM user là điều bắt buộc, không phải tùy chọn. Thêm vào đó, họ đề xuất dùng AWS CloudTrail để ghi lại toàn bộ hoạt động, kết hợp với SNS và Lambda để cảnh báo sớm khi có hành vi bất thường.
| Sai lầm phổ biến | Hậu quả | Cách phòng tránh |
|---|---|---|
| Không lưu key pair cẩn thận | Mất quyền SSH | Dùng password manager |
| Quên đặt password cho user | Không sudo được | Cấu hình cloud-init |
| Tắt PasswordAuthentication | Không SSH bằng pass | Sửa sshd_config |
| Không bật MFA | Dễ bị hack | Bắt buộc cho root |
| Dùng root hàng ngày | Rủi ro cao | Tạo IAM user riêng |
Đặc biệt, có một chi tiết tôi muốn nhấn mạnh: khi bạn tạo instance mới, hãy dùng user data script để tự động đặt password và cấu hình SSH. Ví dụ, bạn có thể thêm đoạn script nhỏ trong phần “Advanced details” khi launch instance:
#!/bin/bash
echo 'ec2-user:YourNewPassword' | chpasswd
sed -i 's/PasswordAuthentication no/PasswordAuthentication yes/' /etc/ssh/sshd_config
systemctl restart sshd
Làm vậy ngay từ đầu sẽ giúp bạn không bao giờ rơi vào tình huống “kẹt cứng” như tôi từng gặp. Cuối cùng, hãy nhớ rằng bảo mật là một quá trình liên tục, không phải một lần rồi thôi.
Định kỳ 3-6 tháng, bạn nên rà soát lại danh sách IAM user, xóa những tài khoản không dùng, và đổi mật khẩu cho những user quan trọng. Kết hợp với việc theo dõi log qua CloudTrail, bạn sẽ giảm thiểu được rủi ro một cách đáng kể.Hy vọng bài viết này giúp bạn tự tin hơn khi xử lý vấn đề đổi mật khẩu EC2 AWS. Nếu bạn có kinh nghiệm hay mẹo nào khác, đừng ngại chia sẻ trong phần bình luận nhé!