Hiểu người dùng Linux qua UID, GID và tài khoản dịch vụ; thực hành quyền sudo giới hạn, xác thực SSH và kiểm tra host key trong lab cô lập riêng.
Trước khi thêm sudo, cần xác định máy đích, danh tính của tiến trình và quyền cần cho công việc.
Sau bài học, bạn có thể đọc UID/GID bằng id, phân biệt tài khoản người dùng với tài khoản phục vụ ứng dụng, giải thích /etc/passwd và /etc/shadow, hiểu su, sudo và hai bước tin cậy của SSH. Cần biết shell, tiến trình và đường dẫn.
Bài tham chiếu mục 5.1 của Linux Essentials 010-160, trang in 347–371, trang PDF 356–380, đối chiếu 015.1 của 010-200. Mốc cập nhật: 23/10/2026. Lab dùng Ubuntu 26.04.1 LTS ARM64 trong container cô lập, với tài khoản và khóa SSH dùng một lần. Binary thực tế là sudo-rs 0.2.13 và OpenSSH 10.2p1 có bản vá distro. Dự án sudo-rs lưu ý có khác biệt tính năng với sudo truyền thống; bài chỉ dùng tùy chọn đã thử. Không thay đổi tài khoản hoặc quyền của máy production.
Linux dùng UID để nhận diện người dùng, GID cho nhóm. Tên như lan giúp con người đọc; số định danh mới là thành phần hệ thống sử dụng trong nhiều kiểm tra quyền. Một tài khoản có nhóm chính và có thể có các nhóm bổ sung. UID và GID thuộc hai không gian ý nghĩa khác nhau: cùng giá trị số không có nghĩa chúng là cùng một đối tượng.
id
id -u
id -g
id -Gn
Các lệnh lần lượt hiển thị thông tin danh tính, UID hiệu lực, GID hiệu lực và tên nhóm của tiến trình hiện tại. Nếu chỉ rõ tên trong id labhelp, bạn đang truy vấn thông tin tài khoản đó, không chuyển shell sang tài khoản ấy. Đây là khác biệt cần nhớ khi kiểm tra quyền sau thay đổi nhóm.
Tư cách nhóm của một phiên đang chạy có thể chưa phản ánh thay đổi tài khoản vừa thực hiện. Đăng nhập lại hoặc tạo phiên mới theo quy trình sẽ khác với chỉ truy vấn cơ sở dữ liệu tài khoản. Không dùng kết quả id TEN để kết luận mọi tiến trình đang chạy của TEN đã nhận nhóm mới.
Các ngưỡng UID cho tài khoản thường hoặc hệ thống phụ thuộc bản phân phối và cấu hình. Đừng phân loại mọi tài khoản chỉ bằng quy tắc “nhỏ hơn 1000” hoặc “lớn hơn 1000”. Cần xem mục đích sử dụng, cấu hình và chính sách cấp phát tại máy.
Root theo mô hình Unix truyền thống có UID 0 và quyền quản trị rộng. Vì vậy, tên tài khoản khác root chưa đủ chứng minh nó ít quyền; cần xem nhóm, policy và năng lực được cấp.
Tài khoản dịch vụ giúp ứng dụng chạy dưới danh tính riêng, chẳng hạn tách tệp và tiến trình của web server khỏi người dùng đăng nhập. Nó có thể không cần shell tương tác hoặc mật khẩu đăng nhập. Shell nologin là một biện pháp hạn chế đường đăng nhập tương tác, không tự xóa mọi cách ứng dụng thực thi với UID đó.
Trong container, UID 0 chịu ranh giới namespace, capability và cấu hình nền tảng. Quyền root trong guest không tự đồng nghĩa quyền root của host. Tuy nhiên, nó vẫn có thể thay đổi dữ liệu nằm trong phạm vi được cấp, đặc biệt khi có volume. Bài lab không mount dữ liệu host để tránh nhập nhằng phạm vi.
Theo manual passwd(5), bản ghi truyền thống có bảy trường phân cách bằng dấu hai chấm:
name:password:UID:GID:GECOS:directory:shell
Trường password thường là ký hiệu như x, không phải mật khẩu đăng nhập hiển thị rõ. Trên hệ thống dùng shadow, thông tin băm mật khẩu và tuổi mật khẩu được lưu riêng trong /etc/shadow với quyền đọc hạn chế. Băm mật khẩu không phải mã hóa có thể giải mã lấy lại mật khẩu gốc.
Bạn có thể truy vấn một tài khoản qua cơ chế cơ sở dữ liệu của hệ thống:
getent passwd "$(id -un)"
getent group "$(id -gn)"
getent có thể sử dụng nguồn ngoài tệp cục bộ tùy NSS, chẳng hạn tích hợp danh tính tập trung. Không tìm thấy tên trong riêng /etc/passwd chưa chứng minh người dùng đó không tồn tại. /etc/group mô tả nhóm cục bộ; các nhóm được cấp qua dịch vụ danh tính cũng cần được xét trong đúng môi trường.
Đừng đính kèm toàn bộ /etc/shadow vào ticket hoặc yêu cầu người dùng đọc nó để chứng minh lỗi. Bản băm vẫn là dữ liệu nhạy cảm. Thông thường Help Desk chỉ cần tên tài khoản liên quan, UID/GID, trạng thái phiên và thông báo lỗi đã loại dữ liệu không cần thiết.
su và sudo giải quyết những câu hỏi khác nhausu của util-linux chạy lệnh hoặc shell với danh tính khác, theo cơ chế xác thực và policy của hệ thống. Dạng su - TEN tạo môi trường kiểu đăng nhập; các biến và thư mục làm việc có thể thay đổi. Không hiểu môi trường sau chuyển danh tính có thể khiến bạn thao tác nhầm home hoặc nhầm cấu hình ứng dụng.
sudo cho người được policy cho phép chạy lệnh với danh tính đích. Theo manual sudo của dự án, policy quyết định quyền và yêu cầu xác thực; không có quy tắc rằng mọi lần sudo đều hỏi mật khẩu hoặc mật khẩu luôn thuộc tài khoản đích. Lệnh sau xem quyền được công bố cho tài khoản hiện tại:
sudo -l
Nếu cần xác thực, chương trình có thể hỏi theo policy. Nếu bị từ chối, lưu lỗi và chuyển cho quản trị viên có trách nhiệm; không sửa sudoers để tự mở quyền. Thay đổi sudoers cần công cụ kiểm tra như visudo và quy trình phục hồi, không phải thao tác bắt buộc của học viên ở bài này.
sudo chạy được một lệnh chưa chứng minh bạn được phép chạy mọi lệnh. Đừng thay một lỗi quyền bằng sudo cho cả chuỗi xử lý, nhất là script chưa đọc.
Lab chuẩn bị sẵn tài khoản labhelp và một policy chỉ cho phép chạy /usr/bin/id dưới root mà không hỏi mật khẩu. Đây là fixture dùng một lần, không phải mẫu cấp quyền cho nhân viên trên máy thật. Bắt đầu trong shell của labhelp:
id
getent passwd labhelp
sudo -l
sudo -n /usr/bin/id -u
Kết quả mong đợi: id đầu tiên là UID khác 0; lệnh cuối in 0 vì riêng lệnh đó chạy với danh tính root. Phiên shell hiện tại vẫn là labhelp. Kiểm tra tiếp:
id -u
sudo -n /usr/bin/true
UID của shell vẫn khác 0. Lệnh true bị từ chối hoặc thất bại theo policy của fixture vì không nằm trong quyền đã cấp. -n yêu cầu không tương tác; việc thất bại trong chế độ này cũng có thể do cần mật khẩu ở môi trường khác. Chỉ kết luận dựa trên cấu hình lab đã biết, không suy rộng mọi lỗi sudo -n thành “không có quyền”.
Lab tự động đã so UID trước/sau, xác nhận lệnh được cho phép trả 0 và lệnh ngoài policy trả trạng thái thất bại. Không dùng một mật khẩu thật, không thay quyền host và không giữ policy lab trên production. Việc tạo/xóa tài khoản sẽ được học riêng trong bài tiếp theo.
SSH bảo vệ kết nối từ client tới server theo giao thức, nhưng người dùng vẫn cần biết mình đang kết nối đúng máy. Có hai câu hỏi: khóa host có thuộc server dự định không, và server có chấp nhận danh tính người dùng không? Chúng không thay thế nhau.
Ví dụ cú pháp, chỉ chạy sau khi quản trị viên cung cấp máy lab và tên tài khoản:
ssh TEN@MAY-LAB
Ở lần đầu, đối chiếu fingerprint host key qua kênh đã tin cậy, chẳng hạn thông tin bàn giao VM từ quản trị viên. Đọc manual OpenSSH để hiểu cách kiểm tra host key và xác thực public key. Không chấp nhận fingerprint chỉ vì có hộp hỏi, không tắt kiểm tra host để bỏ lỗi cảnh báo.
Theo cấu hình client OpenSSH, kiểm tra host key gắn với chính sách client. Nếu host key đổi, có thể máy vừa được cài lại hoặc địa chỉ trỏ tới máy khác, nhưng cũng cần xét nguy cơ kết nối sai đích. Dừng và xác minh thay đổi trước khi sửa known_hosts. ssh-keyscan chỉ thu thập khóa được trình bày trên mạng; một mình kết quả đó không chứng minh chủ sở hữu server.
Public key được đặt ở phía server theo cấu hình cho phép; private key phải được bảo vệ phía client. Khi có passphrase, nó bảo vệ việc sử dụng khóa riêng theo cơ chế công cụ, không thay cho xác minh host. Không gửi private key trong ticket, không nhập passphrase vào câu lệnh có thể lưu lịch sử và không bật agent forwarding theo thói quen.
Với đường dẫn mới chưa tồn tại, ssh-keygen có thể tạo cặp khóa:
ssh-keygen -t ed25519 -f ~/.ssh/lpi_lab
Không ghi đè khóa đang dùng; nhập passphrase tại lời nhắc. Public key có đuôi .pub; quản trị viên cấu hình nó trong ~/.ssh/authorized_keys của tài khoản đích với quyền phù hợp. Lab tự động dùng khóa không passphrase chỉ trong container dùng một lần.
Sau khi đã xác minh host và có thư mục đích được cấp, cú pháp chuyển fixture là:
scp ./fixture.txt TEN@MAY-LAB:/duong/dan/duoc-cap/fixture.txt
scp hiện hành của OpenSSH mặc định dùng SFTP qua SSH. Kiểm tra nguồn, đích và khả năng ghi đè; không ép giao thức cũ để bỏ lỗi. Lab đã upload, tải lại fixture và dùng cmp xác nhận byte giống nhau. Điều đó kiểm chứng lần chuyển mẫu, chưa kiểm tra mọi metadata tệp.
Bộ kiểm thử tạo server SSH chỉ nghe 127.0.0.1:2222 trong container không có mạng ngoài. Nó tạo khóa client và host dùng một lần, lấy public host key trực tiếp từ chính server lab để chuẩn bị tệp tin cậy, rồi kết nối với kiểm tra host nghiêm ngặt. Không dùng khóa cá nhân hoặc dữ liệu production.
Phép thử xác nhận đăng nhập public key tới labhelp và đọc UID không phải root. Nó không chứng minh triển khai MFA, chính sách mật khẩu, VPN hoặc đăng nhập SSH trong tổ chức đã an toàn. Mục tiêu là quan sát sự khác biệt giữa danh tính từ xa, tin cậy host và nâng quyền trong một phạm vi kiểm soát được.
who, w, last đọc thông tin phiên/lịch sử khi có dữ liệu tương ứng. Đầu ra trống trong container không chứng minh chưa có truy cập. Lab SSH không có PTY chưa nghiệm thu phiên desktop.
id labhelp có chuyển shell sang labhelp không? Không, đó là truy vấn danh tính tài khoản.Khi chuyển ticket, ghi máy đích, tài khoản liên quan, lệnh tối thiểu cần chạy, lỗi đã che bí mật và phạm vi quyền mong muốn. Giữ riêng dữ kiện đã quan sát với giả thuyết về policy. Nguồn giáo trình là khung tham chiếu; nội dung, ví dụ và hình của bài được biên soạn độc lập, không đăng lại bản sửa đổi PDF.
Thực hành Linux với ticket giả lập: tạo script đếm, kiểm tra lỗi, giới hạn dữ liệu, phục hồi TAR và xác minh báo cáo HTTP loopback bằng so sánh byte.
Hiểu thư mục tạm và tệp đặc biệt Linux; thử mktemp, sticky bit, hard link và symlink, kiểm tra đích sau di chuyển và phân biệt liên kết với backup.
Đọc quyền tệp Linux, owner và group; thử chmod, chown, search thư mục và umask bằng tài khoản không root, phân biệt ghi nội dung với xóa tên tệp.
Tạo người dùng Linux và nhóm trong lab riêng; kiểm tra home, skeleton, nhóm bổ sung, khóa mật khẩu và phạm vi xóa tài khoản trước khi áp dụng thực tế.