Hướng dẫn vô hiệu hóa đăng nhập root và mật khẩu trên VPS (A-Z)
Nếu SSH Key là cánh cửa thép kiên cố, thì việc giữ lại đăng nhập bằng mật khẩu giống như để ngỏ một cửa sổ không có chấn song. Đây không phải là “tùy chọn”, mà là một yêu cầu bắt buộc để hoàn thiện tấm khiên bảo mật cho VPS của bạn.
Chào mừng bạn đến với bài viết chuyên sâu về Lớp phòng thủ thứ 4, một phần trong hướng dẫn toàn diện Bảo mật VPS từ A-Z: 10 lớp phòng thủ thiết yếu (cập nhật 2025) của chúng tôi. Ở các lớp trước, chúng ta đã rời bỏ tài khoản root (Lớp 1) và chuyển sang dùng SSH Key. Giờ là lúc niêm phong vĩnh viễn các lối vào cũ kỹ đó.
Phân tích chuyên sâu: Tại sao phải “khóa trái cửa”?
Hiểu rõ kẻ thù và điểm yếu của chính mình là bước đầu tiên để xây dựng một hệ thống phòng thủ vững chắc. Hãy cùng phân tích tại sao việc vô hiệu hóa đăng nhập root và mật khẩu lại là một bước đi thiết yếu.
Giải mã tấn công Brute-Force vào cổng 22
Trên Internet, có hàng triệu “robot” (bot) độc hại hoạt động không ngừng nghỉ. Công việc của chúng rất đơn giản: quét toàn bộ các dải địa chỉ IP để tìm những máy chủ có cổng 22 (cổng SSH mặc định) đang mở.
Khi tìm thấy một máy chủ, các bot này sẽ bắt đầu một cuộc tấn công gọi là Brute-Force (tấn công “trâu bò”). Chúng sẽ thử hàng triệu, thậm chí hàng tỷ, các cặp kết hợp tên người dùng và mật khẩu phổ biến nhất cho đến khi tìm ra một cặp chính xác.
Những mật khẩu như “123456”, “password”, “admin123” sẽ bị bẻ khóa chỉ trong vài giây. Ngay cả những mật khẩu phức tạp hơn cũng có thể bị dò ra bằng các cuộc tấn công từ điển, nơi bot thử mọi từ có trong một danh sách khổng lồ.
Minh chứng thực tế trên chính VPS của bạn
Bạn có thể tự mình chứng kiến các cuộc tấn công này đang diễn ra. Hãy mở terminal và chạy lệnh sau trên VPS của bạn:
sudo journalctl -u sshd | grep "Failed password"Lưu ý: Tên dịch vụ có thể là sshd (trên CentOS/RHEL) hoặc ssh (trên Debian/Ubuntu). Nếu lệnh trên không hoạt động, hãy thử với sudo journalctl -u ssh | grep "Failed password".
Lệnh này sẽ lọc nhật ký của dịch vụ SSH và chỉ hiển thị những dòng ghi lại các lần đăng nhập bằng mật khẩu thất bại. Bạn có thể sẽ ngạc nhiên khi thấy rất nhiều địa chỉ IP lạ từ khắp nơi trên thế giới đang cố gắng truy cập vào máy chủ của bạn.
Mỗi dòng log như Failed password for invalid user guest from 116.31.116.51 port 22 chính là một bằng chứng cho thấy máy chủ của bạn đang là mục tiêu. Vô hiệu hóa mật khẩu là cách duy nhất để chặn đứng hoàn toàn loại tấn công này.
root – “Gót chân Achilles” của mọi server
Trong thế giới Linux, root là tài khoản tối cao, có toàn quyền thay đổi mọi thứ trên hệ thống. Chính vì quyền lực này mà nó trở thành mục tiêu số một của mọi hacker.
Lý do rất đơn giản: tên người dùng root là một hằng số đã biết trước. Kẻ tấn công không cần phải đoán tên người dùng, chúng chỉ cần tập trung toàn bộ sức lực vào việc dò mật khẩu. Điều này làm giảm độ khó của cuộc tấn công đi 50%.
Nguyên tắc đặc quyền tối thiểu (Principle of Least Privilege)
Đây là một trong những nguyên tắc nền tảng của an ninh mạng. Nguyên tắc này nói rằng một tài khoản người dùng chỉ nên được cấp những quyền hạn tối thiểu cần thiết để thực hiện công việc của mình. Đăng nhập trực tiếp bằng root là hành động đi ngược lại hoàn toàn nguyên tắc này.
Khi bạn đăng nhập bằng một tài khoản người dùng thường và sử dụng sudo để thực thi các lệnh cần quyền quản trị, bạn sẽ có được nhiều lợi ích an toàn:
- Kiểm soát và truy vết: Mọi lệnh
sudođều được ghi lại trong nhật ký hệ thống. Bạn biết chính xác ai đã làm gì và khi nào. Đăng nhập trực tiếp bằng root sẽ làm mất đi khả năng truy vết này. - Giảm thiểu thiệt hại: Nếu một ứng dụng bạn chạy (ví dụ: một trang web) bị lỗ hổng và bị tấn công, thiệt hại sẽ chỉ giới hạn trong quyền hạn của người dùng thường đó. Nếu ứng dụng chạy dưới quyền
root, kẻ tấn công sẽ chiếm được toàn bộ hệ thống.
Vô hiệu hóa đăng nhập của root buộc mọi người, kể cả bạn, phải tuân theo quy trình làm việc an toàn hơn.
Chuẩn bị an toàn: 3 “lá bùa hộ mệnh”
Trước khi thực hiện bất kỳ thay đổi nào có khả năng khóa bạn khỏi VPS, sự chuẩn bị cẩn thận là tối quan trọng. Hãy xem ba bước dưới đây như những “lá bùa” bảo vệ bạn khỏi mọi rủi ro.
Lá bùa #1 – Kiểm tra lại lối vào chính
Chúng tôi không thể không nhấn mạnh điều này một lần nữa. Đây là bước kiểm tra quan trọng nhất để đảm bảo bạn không tự khóa mình ở ngoài.
- Giữ nguyên cửa sổ terminal hiện tại mà bạn đang đăng nhập.
- Mở một cửa sổ terminal hoàn toàn mới.
- Trong cửa sổ mới, hãy thử đăng nhập lại vào VPS bằng SSH Key của bạn.
- Bạn phải đăng nhập thành công.
Chỉ khi đã hoàn thành bước kiểm tra này, bạn mới nên tiếp tục.
Lá bùa #2 – Sao lưu “bảo hiểm”
Thao tác tiếp theo của chúng ta sẽ là chỉnh sửa file cấu hình của dịch vụ SSH. Trước khi làm điều đó, hãy tạo một bản sao lưu của file này. Nếu bạn vô tình làm sai, bạn có thể dễ dàng khôi phục lại từ bản sao lưu.
Hãy chạy lệnh sau trên VPS:
sudo cp /etc/ssh/sshd_config /etc/ssh/sshd_config.bakLệnh này sẽ tạo ra một file tên là sshd_config.bak trong cùng thư mục. Đây chính là “bảo hiểm” của bạn.
Lá bùa #3 – Biết trước “lối thoát hiểm”
Điều gì sẽ xảy ra trong trường hợp xấu nhất, khi bạn làm sai và không thể truy cập vào VPS qua SSH nữa? May mắn thay, hầu hết các nhà cung cấp VPS đều cung cấp một “lối thoát hiểm”: Đó chính là Web Console hoặc Recovery Console, có thể truy cập qua trang quản trị của nhà cung cấp.
Công cụ này cho phép bạn truy cập trực tiếp vào màn hình và bàn phím của VPS, giống như bạn đang ngồi trước một máy tính vật lý. Nó hoàn toàn không phụ thuộc vào SSH. Hãy tìm hiểu về tính năng này của nhà cung cấp của bạn trước để bạn biết phải làm gì khi cần.
Hướng dẫn vô hiệu hóa đăng nhập root và mật khẩu
Khi đã chuẩn bị đầy đủ các biện pháp an toàn, chúng ta có thể tự tin bắt đầu quá trình “niêm phong” VPS.
Mở file cấu hình /etc/ssh/sshd_config
Tất cả các “luật lệ” của dịch vụ SSH đều được quy định trong file này. Chúng ta sẽ sử dụng trình soạn thảo nano để chỉnh sửa nó.
sudo nano /etc/ssh/sshd_configVô hiệu hóa mọi hình thức xác thực bằng mật khẩu
Trong một số hướng dẫn cũ, bạn có thể thấy đề cập đến ChallengeResponseAuthentication. Tuy nhiên, đây là một tên gọi đã lỗi thời. Tùy chọn hiện đại của nó là KbdInteractiveAuthentication.
Để đảm bảo mọi hình thức xác thực tương tác (có thể bao gồm cả hỏi mật khẩu) đều bị tắt, hãy chắc chắn rằng cả hai tùy chọn sau đều được đặt thành no:
PasswordAuthentication no
KbdInteractiveAuthentication noThiết lập này sẽ vô hiệu hóa tất cả các phương thức xác thực dựa trên việc hỏi-đáp mật khẩu, đảm bảo chỉ có SSH Key được chấp nhận.
Ghi chú chuyên sâu về UsePAM
Bạn có thể thấy một dòng khác là UsePAM yes. Một số hướng dẫn trên mạng đề nghị đổi nó thành no, nhưng đây là một lời khuyên nguy hiểm. PAM (Pluggable Authentication Modules) là một hệ thống quản lý xác thực phức tạp của Linux.
Việc vô hiệu hóa UsePAM có thể phá vỡ các tính năng quan trọng khác như xác thực hai yếu tố (2FA) hoặc các cơ chế đăng nhập hệ thống khác. Hãy luôn giữ UsePAM yes để đảm bảo tính tương thích và bảo mật. Trên thực tế, đây là nền tảng bắt buộc để bạn có thể triển khai các cơ chế bảo mật cấp cao hơn như Lớp 8: Thiết lập xác thực hai yếu tố (2FA).
Vô hiệu hóa hoàn toàn đăng nhập của root
Tiếp theo, hãy tìm đến dòng PermitRootLogin. Trên nhiều hệ thống hiện đại, giá trị mặc định của nó là prohibit-password, nghĩa là đã cấm đăng nhập bằng mật khẩu cho root nhưng vẫn cho phép đăng nhập bằng SSH key.
Tuy nhiên, để niêm phong hoàn toàn và không cho phép bất kỳ hình thức đăng nhập nào của root, chúng ta sẽ đặt nó thành no. Đây là cấu hình an toàn nhất.
PermitRootLogin no(Nâng cao) Tạo “danh sách khách mời” với AllowUsers
Để tăng cường thêm một lớp bảo mật nữa, bạn có thể chỉ định chính xác những người dùng nào được phép đăng nhập. Bất kỳ ai không có trong danh sách này sẽ bị từ chối, ngay cả khi họ có key hợp lệ.
Thêm dòng sau vào cuối file, thay ten_user_cua_ban bằng tên người dùng thực tế của bạn:
AllowUsers ten_user_cua_banNếu bạn có nhiều người dùng, hãy liệt kê họ cách nhau bằng dấu cách: AllowUsers user1 user2 user3.
Kiểm tra “sức khỏe” file cấu hình
Đây là một mẹo chuyên nghiệp mà nhiều người bỏ qua. Trước khi khởi động lại dịch vụ SSH, hãy yêu cầu hệ thống kiểm tra xem file cấu hình bạn vừa sửa có cú pháp hợp lệ hay không.
Hãy chạy lệnh sau:
sudo sshd -tNếu không có thông báo nào xuất hiện, nghĩa là file của bạn hoàn toàn hợp lệ. Nếu có lỗi cú pháp, lệnh này sẽ chỉ ra chính xác dòng bị lỗi để bạn sửa lại. Đây là một bước cực kỳ hữu ích để tránh làm dịch vụ SSH không thể khởi động được.
Áp dụng thay đổi
Khi mọi thứ đã sẵn sàng và hợp lệ, hãy khởi động lại dịch vụ SSH để áp dụng tất cả các thay đổi của chúng ta.
- Trên Ubuntu/Debian:
sudo systemctl restart ssh
- Trên CentOS/RHEL/Fedora:
sudo systemctl restart sshdLưu ý tên dịch vụ có thể là ssh hoặc sshd tùy thuộc vào hệ điều hành của bạn.
Kiểm tra toàn diện và xác minh thành quả
Bây giờ là lúc kiểm tra xem các lớp phòng thủ của chúng ta có hoạt động đúng như mong đợi không. Hãy thực hiện tuần tự ba bài kiểm tra sau, mỗi bài trong một cửa sổ terminal mới.
Kiểm tra 1 (Phải thành công): Đăng nhập bằng SSH Key
Đây là bài kiểm tra quan trọng nhất, xác nhận bạn vẫn còn quyền truy cập vào VPS.
ssh ten_user_cua_ban@your_vps_ipBạn phải đăng nhập thành công (có thể hỏi passphrase của key).
Kiểm tra 2 (Phải thất bại): Đăng nhập bằng mật khẩu
Hãy thử đăng nhập bằng mật khẩu của người dùng. Hệ thống phải từ chối ngay lập tức.
Bạn sẽ nhận được một thông báo lỗi tương tự như sau, đây chính là dấu hiệu thành công:
ten_user_cua_ban@your_vps_ip: Permission denied (publickey).Thông báo này cho biết server chỉ chấp nhận xác thực bằng publickey và đã từ chối phương thức mật khẩu.
Kiểm tra 3 (Phải thất bại): Đăng nhập bằng root
Cuối cùng, hãy thử đăng nhập với tư cách là root.
ssh root@your_vps_ipTương tự, bạn cũng phải nhận được lỗi Permission denied (publickey), xác nhận rằng tài khoản root đã bị niêm phong hoàn toàn.
Câu hỏi thường gặp (FAQ)
1. Vô hiệu hóa đăng nhập root có an toàn tuyệt đối không?
Không. Không có một biện pháp nào là an toàn tuyệt đối. Việc vô hiệu hóa đăng nhập root là một lớp phòng thủ cực kỳ quan trọng, giúp loại bỏ một trong những vector tấn công phổ biến nhất.
Tuy nhiên, nó chỉ là một phần của một chiến lược bảo mật đa lớp. Để đạt an toàn tối đa, bạn cần kết hợp nó với tường lửa (Lớp 2), Fail2Ban (Lớp 6), và luôn cập nhật hệ thống (Lớp 7).
2. Nếu tôi tự khóa mình khỏi VPS sau khi làm theo hướng dẫn này thì phải làm sao?
Đừng quá lo lắng, vẫn có một “lối thoát hiểm”. Hầu hết các nhà cung cấp VPS đều cung cấp một công cụ gọi là Web Console hoặc Recovery Console trong trang quản trị của họ. Công cụ này cho phép bạn truy cập trực tiếp vào máy chủ mà không cần SSH.
Từ đó, bạn có thể đăng nhập và sửa lại file /etc/ssh/sshd_config (ví dụ: khôi phục từ file .bak đã tạo) để lấy lại quyền truy cập.
3. Tôi có thể bật lại đăng nhập bằng mật khẩu nếu cần không?
Có, bạn hoàn toàn có thể bật lại, nhưng chúng tôi thực sự không khuyến khích điều này vì lý do bảo mật.
Để làm vậy, bạn hãy đăng nhập bằng SSH Key, mở lại file /etc/ssh/sshd_config, đổi PasswordAuthentication no thành PasswordAuthentication yes, sau đó khởi động lại dịch vụ SSH.
4. Chỉ thị AllowUsers có thực sự cần thiết không?
Nó không “cần thiết” cho mục tiêu chính là tắt đăng nhập mật khẩu/root, nhưng nó là một lớp bảo vệ nâng cao và rất được khuyến nghị.
Chỉ thị AllowUsers tạo ra một “danh sách trắng”. Ngay cả khi SSH key của một người dùng không có trong danh sách vô tình bị đưa lên server, họ vẫn sẽ không thể đăng nhập. Đây là một lớp phòng thủ chiều sâu (defense in depth) hiệu quả.
Kết luận
Chúc mừng! Bạn đã hoàn thành xuất sắc việc vô hiệu hóa đăng nhập root và mật khẩu, một trong những nhiệm vụ quan trọng nhất để gia cố bảo mật cho máy chủ của mình. Hãy cùng nhìn lại những gì chúng ta đã đạt được.
| Mục tiêu bảo mật | Trạng thái |
| Chặn tấn công Brute-Force bằng mật khẩu | ✅ Đã hoàn thành |
| Vô hiệu hóa đăng nhập của tài khoản root | ✅ Đã hoàn thành |
| Bắt buộc xác thực chỉ bằng SSH Key | ✅ Đã hoàn thành |
| Áp dụng nguyên tắc đặc quyền tối thiểu | ✅ Đã hoàn thành |
An ninh mạng là một hành trình liên tục, không phải là một điểm đến. Sau khi đã khóa trái cửa chính, bạn có thể xem xét xây dựng thêm các lớp phòng thủ khác. Hãy tiếp tục hành trình bảo mật của bạn. Mỗi lớp phòng thủ bạn xây dựng thêm sẽ làm cho “pháo đài” VPS của bạn ngày càng trở nên vững chắc hơn.
Tài liệu tham khảo
- Trang tài liệu chính thức của OpenSSH cho file cấu hình
sshd_config: man.openbsd.org/sshd_config.5 - Giải thích về tấn công Brute Force từ OWASP: owasp.org/www-community/attacks/Brute_force_attack
- Nguyên tắc đặc quyền tối thiểu: en.wikipedia.org/wiki/Principle_of_least_privilege
