Day 2: User Management
Quản trị viên, Loại tài khoản và Quyền hạn
2.1. Khái niệm Cơ bản về User trên Linux
Linux là hệ điều hành đa người dùng, cho phép nhiều người dùng truy cập vào hệ thống cùng một lúc. Mỗi người dùng có:
Đối với 1 người quản trị máy chủ Linux, cần phân biệt giữa:
Các Loại tài khoản trong Linux
1. Tài khoản Root (Super Admin)
2. System User (Tài khoản hệ thống)
3. Regular User (Tài khoản thông thường)
Các loại Quản trị viên (con người thực)
1. Super Administrator
2. System Administrator
3. Service Administrator
4. Application Administrator
5. User Administrator
Có thể có nhiều loại Quản trị viên khác tùy vào mục đích của mỗi doanh nghiệp, mỗi hệ thống.
Quan hệ giữa Quản trị viên và Loại tài khoản
Phân biệt rõ 2 khái niệm này để tránh nhầm lẫn:
Ví dụ, một người có chức vụ là System Administrator (Sysadmin)...
Một System User quản lý một process hoặc app nào đó...
Mối quan hệ đúng là:
Ví dụ minh họa
Trong ví dụ này:
Đây chính là cách phân tách đúng: System Administrator (con người) quản lý hệ thống, còn System User (tài khoản hệ thống) chạy các dịch vụ với quyền hạn hạn chế.
Hiểu rõ sự khác biệt giữa các loại tài khoản và cấp độ quản trị viên là nền tảng quan trọng để quản lý hệ thống Linux một cách hiệu quả và bảo mật.
2.2. Câu lệnh cơ bản để quản lý User và Group
Tạo và Quản lý User
Tạo người dùng mới:
Sự khác biệt:
Thêm tùy chọn khi tạo người dùng:
Đặt/thay đổi mật khẩu:
Sửa đổi thông tin người dùng:
Xóa người dùng:
/etc/passwd - Thông tin tài khoản người dùng
Cấu trúc của mỗi dòng (7 trường được phân cách bởi dấu hai chấm):
Ví dụ:
Truy cập thông tin:
/etc/shadow - Mật khẩu mã hóa
Chứa mật khẩu được mã hóa và thông tin về mật khẩu. Cấu trúc:
Truy cập thông tin (yêu cầu quyền root):
Quản lý chính sách mật khẩu
Thiết lập thời hạn mật khẩu:
Kiểm tra thông tin thời hạn mật khẩu:
Buộc người dùng đổi mật khẩu khi đăng nhập lần sau:
Theo dõi hoạt động người dùng
Kiểm tra người dùng đang đăng nhập:
Kiểm tra lịch sử đăng nhập:
Kiểm tra lịch sử lệnh của người dùng:
Tạo và Quản lý Group
Group là cách để tổ chức và quản lý quyền cho nhiều người dùng cùng lúc.
Trong Linux, mỗi người dùng có:
Tạo nhóm mới:
Thêm người dùng vào nhóm:
Xóa người dùng khỏi nhóm:
Xóa nhóm:
Xem nhóm của người dùng:
Nâng cao: Quản lý Nhóm chính, Nhóm phụ
Giả sử chúng ta có một máy chủ web với cấu trúc sau:
Bước 1: Kiểm tra nhóm hiện tại của người dùng
Kết quả có thể là:
Như vậy, webdev hiện chỉ thuộc nhóm chính là webdev.
Bước 2: Thêm webdev vào nhóm phụ developers
Lưu ý:
Kiểm tra lại:
Kết quả:
Bước 3: Thêm webdev vào nhiều nhóm phụ
Kiểm tra lại:
Kết quả:
Giờ đây webdev thuộc nhiều nhóm phụ và có thể:
Bước 4: So sánh với thay đổi nhóm chính
Nếu chúng ta thay đổi nhóm chính:
Lưu ý: -g (viết thường) thay đổi nhóm chính
Kiểm tra lại:
Kết quả:
Giờ nhóm mặc định khi webdev tạo tập tin sẽ là developers, không còn là webdev nữa.
Tại sao khi đổi Group chính, thì mất luôn quyền Group phụ?
Khi bạn thay đổi nhóm chính của người dùng webdev từ webdev thành developers bằng lệnh sudo usermod -g developers webdev, bạn sẽ thấy nhóm webdev không còn xuất hiện trong danh sách nhóm của người dùng này nữa.
Lý do nhóm cũ biến mất khỏi danh sách nhóm phụ
Trước khi thay đổi, nhóm webdev là nhóm chính, nên nó hiển thị trong gid=1001(webdev) chứ không phải trong danh sách nhóm phụ. Sau khi thay đổi, nhóm webdev không còn là nhóm chính nữa, và vì nó chưa bao giờ nằm trong danh sách nhóm phụ, nên nó biến mất hoàn toàn khỏi danh sách nhóm của người dùng.
Giải pháp: Thêm lại nhóm cũ làm nhóm phụ
Nếu bạn muốn giữ lại nhóm webdev trong danh sách nhóm của người dùng, bạn cần thêm hai lệnh:
Sau khi thực hiện cả hai lệnh, kết quả id webdev sẽ là:
Giờ đây người dùng webdev vẫn có quyền truy cập vào các tệp của nhóm webdev, nhưng các tệp mới tạo ra sẽ thuộc về nhóm developers.
Tuy nhiên, cần suy nghĩ kỹ. Khi thay đổi nhóm chính của người dùng, luôn xem xét có nên thêm nhóm chính cũ vào danh sách nhóm phụ hay không, đặc biệt nếu có các tệp hiện có thuộc về nhóm đó mà người dùng vẫn cần truy cập.
Tác động của Group lên File
Tạo tập tin:
Quyền truy cập:
Tình huống thực tế:
Nhóm phụ là cách linh hoạt để cung cấp quyền truy cập bổ sung mà không thay đổi cách tập tin mới được tạo ra.
2.3. Thiết lập sudo và đăng nhập SSH
Tại sao phải thiết lập Regular User với Sudo?
Tại sao không nên sử dụng tài khoản Root và phải tạo Regular User có quyền Quản trị thông qua Sudo?
Đó là một câu hỏi rất hay! Việc tách biệt Super Admin (root) và System Admin là một thực hành bảo mật cực kỳ quan trọng trong quản trị Linux.
Lý do không nên sử dụng tài khoản Super Admin (root) trực tiếp
1. Nguyên tắc đặc quyền tối thiểu
2. Giảm thiểu rủi ro từ lỗi thao tác
3. Theo dõi và kiểm toán (Auditing)
4. Bảo mật SSH
5. Phòng chống tấn công
Ví dụ thực tế về thiệt hại
Đây là một ví dụ từ kinh nghiệm thực tế:
Một quản trị viên mới đăng nhập trực tiếp bằng tài khoản root và dự định xóa tất cả file trong thư mục /tmp:
Lệnh sai này sẽ bắt đầu xóa toàn bộ hệ thống từ thư mục gốc và gây thiệt hại không thể khôi phục. Nếu dùng sudo, quản trị viên có thêm một bước xác nhận và cơ hội suy nghĩ lại.
Best-practice
Khóa tài khoản root:
Tạo tài khoản quản trị riêng biệt:
Cấu hình sudo cho phép đặc quyền theo nhu cầu:
Vô hiệu hóa đăng nhập SSH trực tiếp bằng root:
Áp dụng xác thực hai yếu tố cho tài khoản quản trị
Tuân thủ các thực hành này sẽ giúp bảo vệ máy chủ Linux và giảm thiểu rủi ro từ cả lỗi vô tình và các cuộc tấn công có chủ đích.
Cấp quyền Sudo
Cấu hình sudo tùy chỉnh:
Chỉnh sửa tập tin sudoers:
Ví dụ thiết lập:
Đăng nhập bằng SSH Key
Lợi ích của xác thực bằng SSH Key
SSH Key là một cặp khóa mật mã gồm khóa riêng tư (private key) và khóa công khai (public key) được sử dụng để xác thực khi kết nối SSH đến máy chủ Linux:
Lợi ích:
Tạo cặp SSH Key
Trên máy tính cá nhân của bạn (không phải máy chủ), chạy:
Quá trình này sẽ:
Đưa khóa công khai lên máy chủ
Cách 1: Sử dụng ssh-copy-id (đơn giản nhất)
Cách 2: Thủ công
Bước 1: Hiển thị khóa công khai để copy
Bước 2: Tạo thư mục SSH trên máy chủ (nếu chưa tồn tại)
Bước 3: Thêm khóa công khai vào danh sách các khóa được ủy quyền
Kiểm tra SSH Key trên máy chủ
Xem các khóa được ủy quyền
Kiểm tra quyền trên thư mục và tập tin SSH
Quyền đúng phải là:
Cập nhật 29/8/2025: SSH vào AWS Instance bằng SSH Key tải về
Tải về Private PEM Key từ AWS, định dạng Lightsail-ap-southest-1.pem
Chuyển PEM vào thư mục ~/.ssh rồi đổi tên thành key mặc định và chuyển quyền
Như vậy là có thể SSH vào như bình thường
Cập nhật 9/12/2025: Quản lý nhiều SSH Keys cho nhiều AWS Instances
Trong thực tế, quản trị viên thường phải làm việc với nhiều servers và nhiều SSH keys khác nhau.
Không nên đổi tên tất cả keys thành id_rsa vì:
Cách 1: Sử dụng tên file riêng cho mỗi key
Bước 1: Lưu key với tên có ý nghĩa
Bước 2: Sử dụng option -i khi SSH
Cách 2: Cấu hình SSH Config (Khuyến nghị)
Đây là cách tốt nhất để quản lý nhiều keys và servers.
Bước 1: Tạo/Sửa file SSH config
Bước 3: SSH đơn giản với alias
Kết nối SSH bằng Key vừa tạo
Để SSH vào server sử dụng khóa RSA mà bạn vừa thiết lập, bạn dùng lệnh sau:
Hệ thống sẽ tự động sử dụng khóa RSA của bạn (file ~/.ssh/id_rsa) để xác thực. Nếu bạn đã thiết lập passphrase cho khóa, bạn sẽ được yêu cầu nhập passphrase này (không phải mật khẩu của tài khoản trên server).
Nếu bạn có nhiều khóa SSH khác nhau hoặc khóa không nằm ở vị trí mặc định, bạn có thể chỉ định đường dẫn đến khóa:
Ví dụ: Lưu ý là bạn phải chỉ định file khóa riêng tư (private key, không có phần mở rộng .pub), không phải khóa công khai (public key).
Quản lý SSH Key
Thêm nhiều khóa
Mỗi khóa cần được thêm vào một dòng riêng trong file ~/.ssh/authorized_keys:
Xóa khóa
Để xóa khóa, cần chỉnh sửa file authorized_keys và xóa dòng chứa khóa đó:
Cấu hình máy chủ SSH chỉ cho phép xác thực bằng khóa
Chỉnh sửa file /etc/ssh/sshd_config:
Thêm hoặc sửa các dòng:
Khởi động lại dịch vụ SSH:
Quản lý SSH Key cho nhiều máy chủ
Sử dụng SSH config file
Tạo hoặc chỉnh sửa file ~/.ssh/config trên máy tính cá nhân:
Sử dụng ssh-agent để quản lý nhiều khóa
Mẹo bảo mật SSH Key
Việc sử dụng SSH Key là một trong những thực hành bảo mật tốt nhất khi quản lý máy chủ Linux. Điều này giúp giảm đáng kể nguy cơ bị tấn công và tăng hiệu quả khi làm việc với nhiều máy chủ.
Nguyên tắc Bảo mật SSH Key
Phải làm gì nếu bị mất máy tính (mất private key)? Làm sao đăng nhập lại vào SSH khi đã khóa luôn hình thức đăng nhập password?
Đó là một câu hỏi rất quan trọng về bảo mật và khôi phục quyền truy cập! Khi bạn bị mất private key và đã tắt xác thực bằng mật khẩu trên server, đây là tình huống khá nghiêm trọng. Dưới đây là các giải pháp:
1. Sử dụng key backup
Nếu bạn đã cẩn thận backup private key ở nơi an toàn khác:
Chỉ cần backup private key (id_rsa) là đủ. Đây là lý do:
Private key (id_rsa) là thành phần quan trọng nhất cần được backup, vì:
Private key phải được giữ bí mật và an toàn - Đây là "mật khẩu" thực sự của bạn
2. Sử dụng key thứ hai (nếu đã thiết lập)
Nếu bạn đã thêm nhiều public key vào file authorized_keys:
3. Truy cập qua bảng điều khiển quản lý (nếu có)
Nếu server là VPS/cloud server:
4. Sử dụng quyền root của máy chủ vật lý
Nếu bạn có quyền truy cập vật lý đến server:
5. Liên hệ nhà cung cấp dịch vụ hosting
Nếu sử dụng dịch vụ hosting:
6. Khôi phục từ backup
Nếu có sẵn backup của toàn bộ hệ thống:
7. Cách phòng tránh vấn đề này trong tương lai
Tình huống này nhấn mạnh tầm quan trọng của việc luôn có phương án dự phòng khi làm việc với server và SSH key!
