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ó:
User ID (UID): Số định danh duy nhất Group ID (GID): Số định danh của nhóm chính Home directory: Thư mục cá nhân Shell: Môi trường dòng lệnh mặc định Đối với 1 người quản trị máy chủ Linux, cần phân biệt giữa:
User vs Người dùng: loại tài khoản (và quyền tương ứng) khác với người dùng (đăng nhập, có trách nhiệm cụ thể). Từ “User” ở đây có thể được hiểu theo nhiều nghĩa khác nhau. User = Người dùng: con người hay người dùng hay Quản trị viên, với trách nhiệm cụ thể, sẽ được trao quyền và loại tài khoản cụ thể (thường là Regular User với quyền Quản trị thông qua Sudo) User = Process: một số ứng dụng hay process, sẽ được trao quyền và loại tài khoản tương ứng, nhưng đa phần sẽ bị bỏ đi khả năng đăng nhập (thường là System User với quyền tương ứng nhưng không thể đăng nhập) Các Loại tài khoản trong Linux
1. Tài khoản Root (Super Admin)
Đặc điểm: Có toàn quyền trên hệ thống, không bị giới hạn bởi bất kỳ kiểm soát quyền nào Mục đích: Quản trị hệ thống ở cấp cao nhất, chỉ sử dụng khi thực sự cần thiết Thực hành tốt: Không đăng nhập trực tiếp bằng root, thay vào đó sử dụng sudo 2. System User (Tài khoản hệ thống)
UID: Thường từ 1-999 (Ubuntu/Debian) hoặc 1-499 (CentOS/RHEL) Thường không có thư mục home trong /home Shell thường là /sbin/nologin hoặc /bin/false Không dùng để đăng nhập tương tác Mục đích: Chạy các dịch vụ và processes với quyền hạn hạn chế Ví dụ: mysql, nginx, apache, postgres 3. Regular User (Tài khoản thông thường)
UID: Thường từ 1000+ (Ubuntu/Debian) hoặc 500+ (CentOS/RHEL) Có thư mục home trong /home Shell tương tác (thường là /bin/bash) Có thể đăng nhập vào hệ thống Mục đích: Dùng cho người dùng thực sự để tương tác với hệ thống Ví dụ: john, maria, webadmin Các loại Quản trị viên (con người thực)
1. Super Administrator
Tài khoản sử dụng: Regular User + sudo không giới hạn (hoặc truy cập root) Quyền hạn: Toàn quyền trên hệ thống Trách nhiệm: Quản lý toàn bộ hệ thống, cài đặt, bảo trì, sao lưu, và khôi phục hệ thống 2. System Administrator
Tài khoản sử dụng: Regular User + sudo cho hầu hết các lệnh Quyền hạn: Quản lý hệ thống, không bao gồm một số tác vụ nhạy cảm Trách nhiệm: Cấu hình dịch vụ, quản lý tài khoản, theo dõi hiệu suất, xử lý sự cố 3. Service Administrator
Tài khoản sử dụng: Regular User + sudo giới hạn cho dịch vụ cụ thể Quyền hạn: Quyền trên một hoặc một nhóm dịch vụ cụ thể Trách nhiệm: Quản lý dịch vụ như web server, database, mail server Ví dụ: Web Administrator, Database Administrator 4. Application Administrator
Tài khoản sử dụng: Regular User với quyền giới hạn trên thư mục ứng dụng Quyền hạn: Quyền đối với ứng dụng cụ thể Trách nhiệm: Quản lý, cấu hình và bảo trì ứng dụng 5. User Administrator
Tài khoản sử dụng: Regular User + sudo cho lệnh quản lý người dùng Quyền hạn: Quản lý tài khoản người dùng Trách nhiệm: Tạo, sửa đổi, xóa tài khoản người dùng, quản lý mật khẩu 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)...
Là con người thực - một người có trách nhiệm quản lý hệ thống Thường đăng nhập bằng tài khoản Regular User có quyền sudo Ví dụ: john, maria, admin1 - những người thực tế quản trị hệ thống Một System User quản lý một process hoặc app nào đó...
Là tài khoản hệ thống được tạo ra để chạy các dịch vụ/processes Không dành cho con người đăng nhập tương tác, mà chỉ dùng để chạy dịch vụ Thường có UID thấp (dưới 1000) và shell nologin Ví dụ: mysql, nginx, apache, postgres Mối quan hệ đúng là:
System Administrator (con người) → quản lý → System User (tài khoản hệ thống) Phân tách nhiệm vụ giúp tăng cường bảo mật và dễ quản lý Sử dụng sudo cho phép theo dõi và kiểm soát các hành động quản trị Ví dụ minh họa
Maria là một System Administrator (con người) Cô ấy đăng nhập vào máy chủ bằng tài khoản Regular User maria với quyền sudo Cô ấy quản lý dịch vụ MySQL, đang chạy dưới tài khoản System User mysql Cô ấy sử dụng lệnh sudo systemctl restart mysql để khởi động lại dịch vụ Trong ví dụ này:
maria là tài khoản của System Administrator (con người) mysql là một System User (tài khoản hệ thống cho process) Đâ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:
adduser: Thân thiện hơn, tương tác hỏi mật khẩu, thông tin liên hệ useradd: Cơ bản hơn, không tạo home directory trừ khi chỉ định 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ó:
Một nhóm chính (primary group): Nhóm mặc định khi người dùng tạo tập tin Nhiều nhóm phụ (supplementary/secondary groups): Cung cấp quyền truy cập bổ sung 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:
Có người dùng webdev là nhà phát triển web developers: Nhóm cho các lập trình viên www-data: Nhóm cho máy chủ web (như Nginx/Apache) backup: Nhóm có quyền sao lưu dữ liệu 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 ý:
-a nghĩa là "append" (thêm vào) - rất quan trọng để không mất các nhóm phụ khác -G chỉ định nhóm phụ (viết hoa) 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ể:
Truy cập tập tin của nhóm developers Truy cập tập tin của webserver (www-data) Thực hiện các thao tác sao lưu (backup) 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ụ
Cách Linux quản lý nhóm người dùng: Mỗi người dùng Linux có chính xác một nhóm chính (primary group) Các nhóm khác được đưa vào danh sách nhóm phụ (supplementary groups) Không có sự trùng lặp tự động: Linux không tự động thêm nhóm chính vào danh sách nhóm phụ Cũng không tự động giữ nhóm chính cũ làm nhóm phụ khi thay đổi Cách hoạt động của lệnh usermod -g: Lệnh này chỉ thay đổi nhóm chính Không tự động điều chỉnh danh sách nhóm phụ theo bất kỳ cách nào 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:
Khi nhóm chính là webdev: -rw-rw-r-- 1 webdev webdev ... Khi nhóm chính là developers: -rw-rw-r-- 1 webdev developers ... Quyền truy cập:
Người dùng webdev có thể truy cập tập tin thuộc bất kỳ nhóm nào họ là thành viên Nhóm chính chỉ ảnh hưởng đến nhóm mặc định của tập tin mới Tình huống thực tế:
Người dùng cần thêm vào nhóm docker để sử dụng Docker: sudo usermod -aG docker webdev Người dùng cần quyền sudo: sudo usermod -aG sudo webdev 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
Tài khoản root có toàn quyền không giới hạn trên hệ thống Hầu hết các tác vụ quản trị không cần quyền root tuyệt đối Sử dụng tài khoản thông thường và sudo cho phép chỉ nâng cao đặc quyền khi thực sự cần thiết 2. Giảm thiểu rủi ro từ lỗi thao tác
Một lệnh sai dưới quyền root có thể gây hại nghiêm trọng ngay lập tức Ví dụ kinh điển: rm -rf / home (thiếu dấu cách) sẽ xóa toàn bộ hệ thống Dùng sudo buộc quản trị viên phải xác nhận bằng mật khẩu, giúp giảm thiểu lỗi do bất cẩn 3. Theo dõi và kiểm toán (Auditing)
Các hoạt động sudo được ghi lại trong log (/var/log/auth.log hoặc /var/log/secure) Dễ dàng theo dõi ai đã thực hiện lệnh nào với đặc quyền nâng cao Với tài khoản root trực tiếp, khó phân biệt ai đã thực hiện hành động nếu nhiều người biết mật khẩu root 4. Bảo mật SSH
Nhiều cấu hình bảo mật khuyến nghị tắt đăng nhập SSH trực tiếp bằng root Buộc phải đăng nhập bằng tài khoản thường rồi sử dụng sudo giúp tăng lớp bảo vệ 5. Phòng chống tấn công
Kẻ tấn công cần biết cả tên tài khoản và mật khẩu Tên tài khoản root đã được biết sẵn, nên chỉ cần tấn công mật khẩu Với tài khoản thông thường, kẻ tấn công phải đoán cả tên tài khoản và mật khẩu 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:
Khóa riêng tư: Lưu trên máy tính cá nhân của bạn, cần được bảo vệ an toàn Khóa công khai: Lưu trên máy chủ trong file ~/.ssh/authorized_keys Lợi ích:
Bảo mật cao hơn: Mạnh mẽ hơn nhiều so với mật khẩu thông thường, rất khó bẻ khóa Tự động hóa: Cho phép đăng nhập tự động mà không cần nhập mật khẩu Quản lý tập trung: Dễ dàng cấp phát, thu hồi quyền truy cập Giảm nguy cơ tấn công brute-force: Không còn dựa vào mật khẩu có thể đoán được 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ẽ:
Hỏi vị trí lưu khóa (mặc định là ~/.ssh/id_ed25519 hoặc ~/.ssh/id_rsa) Yêu cầu mật khẩu cho khóa (tùy chọn nhưng khuyến nghị) Đư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
Lệnh này hiển thị nội dung file khóa công khai RSA của bạn Khóa RSA thường dài hơn ED25519 và bắt đầu bằng ssh-rsa AAAAB3NzaC1yc2EA... Cần copy toàn bộ nội dung hiển thị Bước 2: Tạo thư mục SSH trên máy chủ (nếu chưa tồn tại)
Tham số -p (parents) đảm bảo tạo cả các thư mục cha nếu chúng chưa tồn tại ~/.ssh là thư mục chứa cấu hình SSH trong thư mục home của người dùng 700 có nghĩa: chỉ chủ sở hữu có quyền đọc, ghi và truy cập vào thư mục (không có quyền execute vì thư mục mà) Quyền này rất quan trọng để đảm bảo chỉ có bạn mới có thể truy cập các khóa SSH Bước 3: Thêm khóa công khai vào danh sách các khóa được ủy quyền
Lệnh echo ghi một chuỗi văn bản >> là toán tử chuyển hướng đầu ra, nó thêm (append) nội dung vào cuối file ~/.ssh/authorized_keys là file chứa danh sách các khóa công khai được phép đăng nhập Bạn cần thay "khóa_công_khai_của_bạn" bằng nội dung đã copy ở bước 1 Lệnh này đặt quyền cho file authorized_keys 600 có nghĩa: chỉ chủ sở hữu có quyền đọc và ghi file, không ai khác có quyền truy cập (khác quyền 700 ở chỗ có thể execute thôi) Quyền này rất quan trọng vì nhiều máy chủ SSH sẽ từ chối sử dụng file nếu quyền không chính xác 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à:
~/.ssh directory: 700 (rwx------) ~/.ssh/authorized_keys: 600 (rw-------) 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
Luôn sử dụng passphrase cho khóa riêng tư Không chia sẻ khóa riêng tư với bất kỳ ai Định kỳ cập nhật khóa (ví dụ: hàng năm) Khóa tài khoản khi không còn sử dụng Kiểm soát quyền truy cập chặt chẽ vào file và thư mục SSH 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:
Khôi phục private key từ bản backup Đặt vào thư mục ~/.ssh/ trên máy mới Đảm bảo quyền đúng: chmod 600 ~/.ssh/id_rsa 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 không thể tạo lại - Nếu mất nó, bạn mất quyền truy cập Public key có thể được tạo lại từ private key nếu cần, bằng lệnh: 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:
Sử dụng thiết bị khác có chứa một trong các key được ủy quyền Đăng nhập bằng key còn lại 3. Truy cập qua bảng điều khiển quản lý (nếu có)
Nếu server là VPS/cloud server:
Đăng nhập vào bảng điều khiển của nhà cung cấp (AWS, DigitalOcean, Linode...) Sử dụng tính năng console/VNC/emergency access Từ đó thêm key mới hoặc bật lại xác thực mật khẩu 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:
Khởi động server vào chế độ single-user mode hoặc recovery mode Chỉnh sửa file /etc/ssh/sshd_config để bật lại PasswordAuthentication Hoặc thêm key mới vào file ~/.ssh/authorized_keys của user 5. Liên hệ nhà cung cấp dịch vụ hosting
Nếu sử dụng dịch vụ hosting:
Liên hệ bộ phận hỗ trợ kỹ thuật Yêu cầu reset quyền truy cập (thường sẽ yêu cầu xác minh danh tính) 6. Khôi phục từ backup
Nếu có sẵn backup của toàn bộ hệ thống:
Khôi phục server từ backup gần nhất 7. Cách phòng tránh vấn đề này trong tương lai
Luôn backup private key và lưu ở nơi an toàn (ví dụ: USB được mã hóa, password manager) Cài đặt nhiều key vào file authorized_keys: Cấu hình một "emergency user" có thể đăng nhập bằng mật khẩu: Sử dụng công cụ quản lý cấu hình như Ansible để dễ dàng quản lý SSH key trên nhiều server Duy trì quy trình khôi phục thiên tai (DR - Disaster Recovery) cho tất cả các server quan trọng 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!
Thực hành
Tạo người dùng mới tên 'webadmin' với mô tả "Web Administrator" Tạo nhóm 'developers' và thêm 'webadmin' vào nhóm này Đặt mật khẩu cho 'webadmin' và buộc đổi mật khẩu khi đăng nhập lần đầu Kiểm tra thông tin về người dùng 'webadmin' trong /etc/passwd Cấp quyền sudo cho 'webadmin' chỉ với lệnh liên quan đến nginx Khóa tài khoản 'webadmin' và sau đó mở khóa
Day 2: User Management