Lộ Trình Bảo Mật VPS Mới Tạo: Từ User Sudo, SSH Key Đến Firewall Mà Không Tự Nhốt Mình Ngoài Cửa

Khi bắt tay vào gia cố bảo mật cho một chiếc VPS mới tạo, quy tắc vàng của dân quản trị hệ thống là: chuẩn bị đường cứu hộ (Web Console) trước tiên, tạo tài khoản User riêng, gắn SSH Key rồi mới siết cấu hình Firewall và SSH — đặc biệt, sau mỗi bước đều phải kiểm chứng trên một cửa sổ Terminal thứ hai! Đã có không biết bao nhiêu anh em hăng hái làm theo các bài viết “10 bước bảo mật VPS trong 5 phút”, hùng hổ tắt đăng nhập root và bật tường lửa cùng một lúc rồi gõ exit, để rồi 10 giây sau nhận ra mình vừa… tự nhốt mình ở ngoài cửa sắt mà chìa khóa vẫn để quên trong nhà!

Bài viết này đóng vai trò là tấm bản đồ chiến lược định hình thứ tự thực hành cho cụm bài viết về SSH, User Sudo và Firewall trong toàn bộ series. Các câu lệnh chi tiết tới từng dấu chấm phẩy đã được tách riêng ở hai bài thực hành chuyên sâu: Tạo User Sudo và thử nghiệm bằng phiên SSH thứ hai cùng bài Bật tường lửa UFW cho SSH, HTTP, HTTPS mà không tự khóa VPS. Tại đây, chúng ta sẽ cùng nắm vững các chốt chặn an toàn trước khi đi tiếp và hiểu vì sao một dòng thông báo “Command succeeded” trên màn hình chưa bao giờ đủ để khẳng định hệ thống đã vận hành trơn tru.

1. Chuẩn bị một “Lối thoát hiểm” (Web Console) hoạt động thật sự

Trước khi đụng chạm vào bất kỳ file cấu hình nhạy cảm nào của hệ thống, hãy đăng nhập vào bảng điều khiển (Panel) của nhà cung cấp Cloud, tìm tới đúng chiếc VPS lab của bạn và mở thử tính năng Web Console (hoặc chế độ Rescue Mode chính thức). Một sai lầm rất phổ biến là thấy trên giao diện web có cái nút tên là “Console” thì yên tâm nghĩ rằng mình đã có phao cứu sinh, nhưng đến lúc gặp sự cố bấm vào mới phát hiện ra tài khoản bên trong không có mật khẩu nội bộ để đăng nhập qua màn hình Console! Hãy bấm mở cửa sổ Console lên và thử đăng nhập thật sự ít nhất một lần khi máy đang bình thường.

Đồng thời, hãy ghi chép đầy đủ Tên máy, Mã ID, Địa chỉ IP, tài khoản gốc và chuỗi Host Fingerprint đã xác minh vào sổ tay vận hành. Trong suốt quá trình chỉnh sửa cấu hình bảo mật, luôn giữ nguyên cửa sổ Terminal SSH hiện tại mở thông suốt (không được đóng!). Nếu máy chủ đã có dữ liệu hoặc cấu hình quan trọng, hãy tạo một bản Snapshot hoặc sao lưu trước; ngay cả với một chiếc VPS lab mới tinh thì việc ghi nhật ký từng bước thay đổi cũng giúp bạn biết đường khôi phục ngay khi lỡ tay.

Tuyệt đối đừng bao giờ coi nút “Rebuild / Cài lại OS” là phương án cứu hộ đầu tiên khi mất kết nối SSH, bởi thao tác đó sẽ xóa sạch toàn bộ công sức cài đặt của bạn. Khi không vào được máy, người kỹ sư điềm tĩnh sẽ dùng Web Console để phân tích xem nguyên nhân nằm ở tầng mạng, sai khóa SSH, nhầm quyền User hay do tường lửa chặn cổng.

Sơ đồ tư duy kỹ thuật: Web Console đóng vai trò như cửa thoát hiểm nối thẳng vào màn hình máy ảo mà không đi qua mạng SSH thông thường, nhưng bạn vẫn cần có thông tin đăng nhập hợp lệ bên trong hệ điều hành.

Thực tế trên máy chủ LAB-CF-02 vào ngày 01/10/2026, chúng tôi đã mở giao diện Web Console của CloudFly và đăng nhập thành công bằng tài khoản root hiện hữu vào lúc 08:16; ngay sau đó vào lúc 08:17:04 (giờ Việt Nam), chúng tôi chạy lệnh xuất Hostname cùng mã băm Host Fingerprint chuẩn Ed25519 để đối chiếu khớp 100% với danh bạ known_hosts trên laptop cá nhân. Bước này chứng minh đường vào dự phòng qua Console hoàn toàn thông suốt và đáng tin cậy.

Ảnh chụp màn hình Web Console thực tế ngày 01/10/2026 lúc 08:17:04 (giờ Việt Nam) trên máy chủ LAB-CF-02. Phần hiển thị giữ nguyên độ phân giải gốc và đính kèm logo localhost.vn ở chân ảnh. Bấm vào ảnh để xem kích thước đầy đủ.

2. Tạo tài khoản User vận hành riêng biệt kèm quyền Sudo

Trong quản trị Linux chuyên nghiệp, tài khoản root giống như chiếc ấn thượng phương bảo kiếm: quyền lực tối thượng nhưng hễ vung tay trượt một nhát (như gõ nhầm rm -rf) là đi tong cả hệ thống mà không ai cản lại. Vì vậy, nguyên tắc chuẩn là tạo một tài khoản người dùng thông thường (Regular User) để làm việc hằng ngày, và chỉ mượn quyền quản trị thông qua từ khóa sudo khi thực sự cần cài đặt gói phần mềm hay sửa file hệ thống. Khi làm việc theo nhóm, việc mỗi người có một tài khoản riêng còn giúp lưu vết rõ ràng trong nhật ký hệ thống (Log) xem ai vừa gõ lệnh gì, và dễ dàng khóa đúng tài khoản đó khi một thành viên nghỉ việc.

Tuy nhiên, xin nhấn mạnh một điều: chỉ gõ xong lệnh adduser và thêm tài khoản vào nhóm sudo thì chưa thể coi là hoàn thành nhiệm vụ! Rất nhiều trường hợp thêm user xong xuôi nhưng quên chưa tạo thư mục ~/.ssh, chép nhầm nội dung file authorized_keys, hoặc tệ hơn là để chủ sở hữu (Owner) của thư mục .ssh vẫn thuộc về root:root khiến OpenSSH lập tức từ chối cho user mới đăng nhập. Cách nghiệm thu duy nhất đúng là giữ nguyên cửa sổ Terminal cũ, bật một cửa sổ Terminal thứ hai trên laptop, đăng nhập SSH trực tiếp vào user mới đó, gõ whoami và chạy thử sudo whoami xem hệ thống có trả về chữ root hay không.

Trong đợt rà soát trạng thái hệ thống lúc 14:02:36 (giờ Việt Nam) ngày 01/10/2026 trên máy chủ LAB-CF-02, chúng tôi đã ghi nhận tài khoản vận hành mang tên tutorial có định danh UID/GID 1000, nằm trong nhóm sudo, thư mục nhà /home/tutorial có quyền 750, thư mục .ssh đạt chuẩn 700 và file authorized_keys đạt chuẩn 600 với chủ sở hữu đồng nhất là tutorial:tutorial. Chính sách phân quyền sudo hiển thị rõ (ALL : ALL) ALL (yêu cầu nhập mật khẩu xác nhận đàng hoàng chứ không bật chế độ thả cửa NOPASSWD). Khả năng kết nối SSH mới và nâng quyền sudo thực tế của tài khoản này cũng đã được kiểm chứng độc lập ở phiên kết nối lúc 13:52 cùng ngày.

Ảnh chụp màn hình thực tế lúc 14:03:16 (giờ Việt Nam) ngày 01/10/2026 ghi lại kết quả đọc thông tin tài khoản lúc 14:02:36 trên LAB-CF-02. Phần hiển thị giữ nguyên pixel gốc, có chân ảnh logo localhost.vn.

3. Quản lý khóa SSH Key và những cạm bẫy trong file cấu hình sshd_config

Hãy cấp phát cặp khóa SSH riêng biệt cho từng cá nhân vận hành máy chủ. Trên VPS chỉ lưu trữ phần khóa công khai (Public Key), còn file khóa bí mật (Private Key) phải nằm an toàn trên thiết bị của từng người — tuyệt đối không gửi file Private Key qua tin nhắn chat hỗ trợ kỹ thuật, cũng không lưu cứng mật khẩu mở khóa (Passphrase) vào các file script hay để lộ trên ảnh chụp màn hình.

Trước khi bạn định sửa cấu hình để tắt hẳn tính năng đăng nhập bằng mật khẩu (PasswordAuthentication no), hãy đảm bảo 100% rằng mọi tài khoản vận hành cần thiết đều đã đăng nhập mượt mà bằng SSH Key và đường cứu hộ Web Console vẫn hoạt động tốt. Đừng bao giờ ngây thơ nghĩ rằng khi tạo một user mới bằng lệnh adduser thì hệ điều hành sẽ tự động chép luôn SSH Key của tài khoản root sang cho user mới đó!

Thêm một kinh nghiệm cực kỳ đắt giá trên các bản Ubuntu đời mới (như Ubuntu 22.04 / 24.04): dịch vụ OpenSSH Server không chỉ đọc mỗi file /etc/ssh/sshd_config truyền thống, mà còn nạp thêm các file cấu hình phụ nằm trong thư mục /etc/ssh/sshd_config.d/*.conf (ví dụ các file do Cloud-init sinh ra). Do quy tắc ưu tiên của OpenSSH hoặc các khối điều kiện Match, nhiều khi bạn sửa trong file chính nhưng vẫn bị file phụ trong thư mục .d ghi đè! Vì vậy, sau khi chỉnh sửa, hãy luôn chạy lệnh kiểm tra cú pháp sudo sshd -t (nếu không báo lỗi gì mới là chuẩn) và dùng sudo sshd -T để xem cấu hình thực tế đang có hiệu lực trước khi nạp lại dịch vụ.

4. Nguyên tắc bật Tường lửa (Firewall): Phải mở lối cho SSH trước khi kéo cầu!

Tường lửa trên hệ điều hành (như UFW – Uncomplicated Firewall trên Ubuntu) hoạt động như người gác cổng kiểm tra từng gói tin ra vào máy chủ. Ngoài ra, nếu nhà cung cấp Cloud của bạn có trang bị thêm một lớp Cloud Firewall (Security Group) trên bảng điều khiển web, thì gói tin từ Internet phải lọt qua được cả hai tầng tường lửa này mới chạm tới được ứng dụng bên trong. Nói cách khác: nếu bạn mở cổng 80/443 trong UFW của Ubuntu nhưng trên Panel Cloud lại đang khóa cổng đó thì khách truy cập vẫn gặp lỗi kết nối như thường.

Quy trình sống còn khi bật UFW là: kiểm tra xem dịch vụ SSH đang lắng nghe ở cổng nào (mặc định là 22/tcp) → thêm quy tắc cho phép (Allow) cổng SSH đó trước tiên → sau đó mới gõ lệnh bật UFW (ufw enable) → cuối cùng mở một cửa sổ Terminal mới tinh để thử kết nối SSH vào lại! Đối với máy chủ chạy website WordPress thông thường, bạn chỉ cần mở thêm cổng 80/tcp (HTTP) và 443/tcp (HTTPS). Cơ sở dữ liệu MariaDB/MySQL chạy chung trên cùng chiếc VPS đó giao tiếp nội bộ qua 127.0.0.1 hoặc Unix Socket, nên tuyệt đối không có lý do gì để mở toang cổng 3306 ra ngoài Internet cho hacker dò mật khẩu cả!

Một cái bẫy rất nhiều người dính: khi bật nhầm Firewall chặn cổng SSH, cửa sổ SSH cũ đang mở sẵn đôi khi vẫn gõ lệnh được tiếp một lúc (do kết nối ESTABLISHED), làm bạn tưởng lầm là mọi thứ vẫn ổn cho tới khi thoát ra và không bao giờ vào lại được nữa!

Trong đợt rà soát lúc 13:50:46 (giờ Việt Nam) ngày 01/10/2026 trên máy chủ LAB-CF-02, kết quả ghi nhận tường lửa UFW đang ở trạng thái active, chính sách mặc định chặn toàn bộ kết nối chiều vào (deny (incoming)) và cho phép chiều ra (allow (outgoing)); chỉ mở đúng 3 cổng TCP 22, 80 và 443 trên cả IPv4 lẫn IPv6. Khi kiểm tra danh sách tiến trình lắng nghe (Listeners) thực tế bên dưới: giao thức IPv4 có đủ mặt các cổng 22, 80, 443; IPv6 đang lắng nghe ở 22 và 80; còn dịch vụ cơ sở dữ liệu MariaDB nằm im an toàn tại địa chỉ nội bộ 127.0.0.1:3306. Một nhận xét rất tinh tế của dân kỹ thuật: việc UFW có dòng rule cho phép cổng 443 (v6) chỉ có nghĩa là tường lửa không chặn, chứ chưa chứng minh Web Server đã cấu hình lắng nghe HTTPS trên IPv6!

Ảnh chụp màn hình thực tế lúc 13:54:16 (giờ Việt Nam) ngày 01/10/2026 ghi lại kết quả đọc trạng thái UFW và danh sách cổng lắng nghe lúc 13:50:46 trên LAB-CF-02.

5. Kỷ luật sắt: “Mỗi lần chỉ thay đổi đúng một biến số!”

Hãy tập thói quen đi từng bước vững chắc như người leo núi đóng từng chiếc chốt an toàn: Xác minh Web Console → Tạo User mới → Gắn SSH Key → Mở cửa sổ mới thử SSH vào User mới → Kiểm tra quyền Sudo → Cấu hình và bật Firewall → Lại mở cửa sổ mới kiểm tra kết nối lần nữa. Chỉ khi toàn bộ các mắt xích đó đã chạy trơn tru 100%, bạn mới bắt đầu tính đến chuyện khóa đăng nhập mật khẩu hoặc khóa đăng nhập trực tiếp vào tài khoản root.

Hãy tưởng tượng nếu bạn làm một lèo: vừa đổi cổng SSH từ 22 sang 2222, vừa tắt mật khẩu, vừa cấm root, vừa bật UFW trong cùng một phút — đến lúc gõ lệnh kết nối báo lỗi, bạn sẽ hoàn toàn mù tịt không biết thủ phạm nằm ở bước nào! Nhân tiện nói về chuyện đổi cổng SSH mặc định: việc chuyển cổng 22 sang một con số khác thực chất chỉ giúp giảm bớt rác trong file log do các tool quét tự động gây ra (Security through obscurity), chứ hoàn toàn không thể thay thế cho độ an toàn của cặp khóa SSH Key chuẩn Ed25519/RSA. Khi mới bắt đầu học quản trị VPS, bạn cứ giữ nguyên cổng 22 chuẩn mực và dùng SSH Key kết hợp UFW là đã cực kỳ vững chắc rồi.

Việc thay đổi từng bước nhỏ còn giúp bạn khôi phục (Rollback) cực nhanh khi gặp sự cố: vừa sửa 1 dòng mà thấy lỗi ngay thì chỉ cần hoàn tác đúng dòng đó trong cửa sổ SSH đang giữ mở, thay vì hoảng loạn tắt sạch cả tường lửa lẫn cơ chế bảo mật để cứu máy.

Biên bản nghiệm thu bảo mật máy chủ cần ghi nhận những gì?

Một biên bản bàn giao bảo mật VPS chuẩn chỉnh cần ghi rõ: tên tài khoản vận hành hằng ngày, dấu vân tay (Fingerprint) của các Public Key được cấp quyền, cổng lắng nghe SSH, danh sách quy tắc tường lửa UFW, cùng kết quả thực nghiệm mở kết nối SSH mới và nâng quyền sudo. Đối với đường cứu hộ Web Console, phải ghi rõ là “Đã đăng nhập vào trong shell thành công” chứ không chỉ ghi “Mở lên thấy màn hình đen nhấp nháy”.

Trong chuỗi thực nghiệm của chúng tôi, chiếc máy chủ đầu tiên LAB-CF-01 đã hoàn thành kiểm chứng SSH Key, User Sudo và mở phiên SSH mới sau khi bật UFW cho cổng 22 (tuy nhiên ở LAB-CF-01 chưa thực hiện bước đăng nhập Web Console). Do đó, trên chiếc máy chủ thứ hai LAB-CF-02 vào ngày 01/10/2026, chúng tôi đã thực hiện đầy đủ các bước kiểm chứng toàn diện và tổng hợp minh bạch trong bảng dưới đây:

Một ghi chú minh bạch nữa: tại mốc kiểm tra cấu hình dịch vụ lúc 00:36 trên máy chủ thử nghiệm này, hai thông số PasswordAuthentication yes và PermitRootLogin yes vẫn đang giữ ở trạng thái mở phục vụ các bài tập thực hành khác trong chuỗi lab — đây là hiện trạng chủ đích của máy thử nghiệm, không phải cấu hình khuyến nghị cuối cùng cho máy chủ Production. Khi bạn bước sang giai đoạn đóng hai cánh cửa này trên máy thật, hãy nhớ luôn kiểm tra cú pháp bằng sudo sshd -t và thử nghiệm trên cửa sổ Terminal thứ hai ngay sau khi nạp lại dịch vụ.

Sơ đồ tư duy kỹ thuật: Mỗi trụ cột bảo mật đều phải được nghiệm thu độc lập bằng kết quả thực tế, không bao giờ đánh giá qua cảm tính.

Câu hỏi thường gặp (FAQ)

Tôi vừa nhận VPS xong thì có nên cấm đăng nhập tài khoản root ngay giây đầu tiên không? Tuyệt đối khoan hãy làm ngay! Hãy tạo xong user mới, gắn SSH Key, mở cửa sổ Terminal thứ hai đăng nhập thử vào user mới và chạy sudo whoami thấy trả về root ngon lành, đồng thời biết chắc chắn cách vào Web Console cứu hộ rồi mới được phép khóa đăng nhập trực tiếp của root. Làm đúng thứ tự quan trọng hơn làm nhanh gấp trăm lần!

Đã bật tường lửa UFW chặn hết các cổng thừa rồi thì có cần cập nhật bản vá bảo mật của hệ điều hành nữa không? Vẫn bắt buộc phải cập nhật định kỳ! Tường lửa chỉ giúp đóng các cánh cửa không dùng tới, còn cổng 80/443 (Web) và cổng 22 (SSH) vẫn đang mở để đón khách; nếu phần mềm đứng sau các cổng đó có lỗ hổng bảo mật thì bạn vẫn phải cập nhật bản vá (apt upgrade) để bịt lỗ hổng.

Tạo một cặp khóa SSH duy nhất rồi gửi cho cả nhóm 5 anh em kỹ thuật dùng chung có tiện hơn không? Tiện lúc đầu nhưng là thảm họa lúc sau! Dùng chung một khóa khiến bạn không thể biết ai là người vừa đăng nhập, và khi một người trong nhóm nghỉ việc hoặc làm mất laptop, bạn sẽ phải đổi khóa lại cho cả 4 người còn lại.

Hành động tiếp theo ngay bây giờ: Hãy bắt tay vào thực hành từng câu lệnh cụ thể ở bài Hướng dẫn tạo User Sudo và kiểm chứng phiên SSH thứ hai, sau đó tiến thẳng sang bài Bật tường lửa UFW cho SSH, HTTP, HTTPS an toàn. Nhớ chỉ thực hành trên máy chủ lab mà bạn có toàn quyền quản trị nhé!

Tài liệu tham khảo chuẩn (đối chiếu ngày 01/10/2026): Ubuntu Server: OpenSSH Server, Ubuntu Server: Firewalls (UFW), và tài liệu gốc OpenBSD Manual: sshd_config (đối chiếu ngày 30/09/2026).

Cùng chuỗi bài học: Xem toàn bộ Lộ trình cài đặt WordPress trên VPS từ A đến Z.