Xây dựng SSH CA: Cấp chứng chỉ ngắn hạn cho đội vận hành

Khi đội vận hành có nhiều người và nhiều máy chủ, sao chép từng public key vào từng file authorized_keys nhanh chóng trở thành bài toán kiểm kê và thu hồi quyền. OpenSSH certificate cho phép máy chủ tin một khóa CA; người dùng giữ private key riêng và nhận certificate có thời hạn, principal cùng các giới hạn sử dụng.

Bài hướng dẫn dựng mô hình tối thiểu cho user certificate trên Linux. Mục tiêu là hiểu luồng ký, triển khai từng bước có rollback và tránh nhầm OpenSSH certificate với X.509/TLS. Ví dụ dùng Ed25519; hãy đối chiếu chính sách mật mã và phiên bản OpenSSH của tổ chức trước khi áp dụng production.

1. SSH certificate thay đổi mô hình tin cậy như thế nào?

Với public key truyền thống, mỗi máy chủ giữ danh sách khóa được phép. Với certificate, máy chủ giữ public key của CA qua TrustedUserCAKeys. CA ký public key của người dùng, nhúng danh tính, principals, thời gian hiệu lực và tùy chọn. Khi đăng nhập, sshd kiểm tra chữ ký, thời gian, principal và policy máy chủ.

Certificate không thay thế Unix account, sudo policy hay MFA. Nó chỉ là một phương thức xác thực; quyền sau đăng nhập vẫn do hệ điều hành và ứng dụng quyết định.

2. Thiết kế trước khi chạy lệnh

Xác định bốn yếu tố trước: ai được yêu cầu certificate, hệ thống nào được truy cập, principal nào biểu diễn vai trò và certificate sống bao lâu. Không nên dùng tên account đích như mô hình phân quyền duy nhất. Principal theo vai trò như ops-read, ops-admin hoặc deploy giúp máy chủ ánh xạ policy rõ hơn.

• Certificate tương tác thông thường: vài giờ, đủ một ca làm việc.
• Automation: ưu tiên workload identity và luồng cấp tự động; không cấp certificate nhiều tháng chỉ để đỡ gia hạn.
• Emergency access: policy riêng, thời hạn rất ngắn, phê duyệt và audit bắt buộc.
• User CA và host CA: dùng khóa tách biệt để giảm blast radius và tránh nhầm mục đích.

Đồng hồ sai có thể khiến certificate “chưa có hiệu lực” hoặc “đã hết hạn”. Bật đồng bộ thời gian và giám sát clock drift trên CA, client và server.

3. Tạo CA trong môi trường thử nghiệm

Thực hiện bước này trên máy ký chuyên dụng, không phải máy chủ đích. Lệnh sau tạo cặp khóa Ed25519:

umask 077
ssh-keygen -t ed25519 -f user_ca -C "OpenSSH User CA"

user_ca là private key và không được sao chép tới server. user_ca.pub là public key để phân phối. Trong production, nên bảo vệ private key bằng passphrase, HSM/PKCS#11 hoặc dịch vụ ký có xác thực mạnh, approval và audit log. Không đưa CA private key vào repository, image máy ảo hay hệ thống cấu hình chung.

Ghi lại fingerprint để đối chiếu khi phân phối:

ssh-keygen -lf user_ca.pub

4. Tạo khóa cá nhân

Mỗi người dùng tự tạo khóa trên thiết bị của mình:

ssh-keygen -t ed25519 -f ~/.ssh/id_ed25519_ops -C "alice@ops"

Chỉ gửi file id_ed25519_ops.pub cho hệ thống cấp chứng chỉ. Private key id_ed25519_ops không rời thiết bị. Nếu dùng FIDO/security key, cần thiết kế luồng tương ứng và kiểm tra client/server hỗ trợ thuật toán đã chọn.

5. Ký certificate ngắn hạn

Trên máy CA, sau khi đã xác minh yêu cầu và public key, ký một certificate có principal ops, hiệu lực từ 5 phút trước thời điểm hiện tại đến 8 giờ sau:

ssh-keygen -s user_ca -I alice-ops-20260928 -n ops -V -5m:+8h -z 1001 id_ed25519_ops.pub

Các trường quan trọng:

• -I: key ID phục vụ nhận diện và log; nên liên hệ được với người yêu cầu và ticket.
• -n: danh sách principal được certificate khai báo.
• -V: khoảng hiệu lực. Offset âm nhỏ giúp chịu sai lệch đồng hồ có kiểm soát.
• -z: serial number; nên duy nhất và được ghi vào audit log.

Lệnh tạo file id_ed25519_ops-cert.pub. Kiểm tra nội dung trước khi giao:

ssh-keygen -L -f id_ed25519_ops-cert.pub

Xem kỹ loại certificate, signing CA, key ID, serial, validity, principals, critical options và extensions. Không chỉ dựa vào tên file.

6. Cho máy chủ tin user CA

Sao chép duy nhất user_ca.pub tới máy chủ, ví dụ /etc/ssh/user_ca.pub, thuộc sở hữu root và không cho người dùng thường ghi. Thêm vào /etc/ssh/sshd_config hoặc file include được phân phối bởi configuration management:

TrustedUserCAKeys /etc/ssh/user_ca.pub
AuthorizedPrincipalsFile /etc/ssh/auth_principals/%u

Tạo danh sách principal cho account đích. Ví dụ để principal ops đăng nhập account adminops:

install -d -m 0755 -o root -g root /etc/ssh/auth_principals
printf '%s
' 'ops' | sudo tee /etc/ssh/auth_principals/adminops
sudo chown root:root /etc/ssh/auth_principals/adminops
sudo chmod 0644 /etc/ssh/auth_principals/adminops

Khi AuthorizedPrincipalsFile được cấu hình, certificate phải chứa một principal có trong file tương ứng. Nếu không cấu hình, hành vi mặc định thường yêu cầu username đích xuất hiện trong danh sách principals. Cần kiểm tra semantics trên phiên bản OpenSSH đang chạy.

7. Kiểm tra cấu hình mà không tự khóa mình

Giữ nguyên phiên SSH quản trị hiện tại. Kiểm tra cú pháp trước khi reload:

sudo sshd -t

Nếu hợp lệ, reload đúng service của distribution, ví dụ:

sudo systemctl reload ssh

Một số hệ thống dùng unit sshd. Hãy xác minh tên service thay vì copy lệnh mù quáng. Mở terminal thứ hai để thử đăng nhập; không đóng phiên cứu hộ cho đến khi certificate mới hoạt động và log đã được kiểm tra.

8. Đăng nhập bằng certificate

Đặt certificate cạnh private key, cùng basename. OpenSSH client thường tự nhận file hậu tố -cert.pub khi private key được chọn:

chmod 600 ~/.ssh/id_ed25519_ops
chmod 644 ~/.ssh/id_ed25519_ops-cert.pub
ssh -i ~/.ssh/id_ed25519_ops adminops@server.example.com

Nếu thất bại, tăng mức log client:

ssh -vvv -i ~/.ssh/id_ed25519_ops adminops@server.example.com

Trên server, xem authentication log tương ứng với distribution. Các lỗi phổ biến gồm certificate hết hạn, principal không khớp, CA khác fingerprint, quyền file sai, thuật toán bị policy từ chối hoặc client không gửi certificate.

9. Hạn chế khả năng của certificate

Certificate có thể mang critical options và extensions. Ví dụ có thể giới hạn dải địa chỉ nguồn hoặc tắt forwarding cho một luồng tự động:

ssh-keygen -s user_ca -I deploy-job-1002 -n deploy -V -2m:+30m -z 1002 -O source-address=203.0.113.0/24 -O no-agent-forwarding -O no-port-forwarding -O no-pty deploy.pub

Chỉ thêm option đã được kiểm thử trên client/server mục tiêu. Một critical option mà server không hiểu sẽ khiến certificate bị từ chối—đây là hành vi an toàn. Policy ở certificate nên bổ sung, không thay thế Match, sudoers, network segmentation và kiểm soát ứng dụng.

10. Thu hồi certificate khi cần

Certificate ngắn hạn giảm cửa sổ rủi ro nhưng không loại bỏ nhu cầu thu hồi khẩn cấp. OpenSSH hỗ trợ Key Revocation List (KRL). Có thể tạo KRL chứa certificate bị thu hồi:

ssh-keygen -k -f revoked_keys.krl id_ed25519_ops-cert.pub
ssh-keygen -Q -f revoked_keys.krl id_ed25519_ops-cert.pub

Sau khi kiểm tra, triển khai file KRL tới server bằng cơ chế thay thế nguyên tử và cấu hình:

RevokedKeys /etc/ssh/revoked_keys.krl

Tài liệu sshd_config cảnh báo rằng nếu file RevokedKeys không đọc được, xác thực public key sẽ bị từ chối cho mọi người. Vì vậy không bật directive trước khi file hợp lệ đã tồn tại, permission đúng và rollback đã sẵn sàng. Với hệ thống lớn, quản lý thu hồi theo serial/CA, version hóa KRL và giám sát độ mới trên từng server.

11. Audit và tự động hóa phát hành

Mỗi lần ký nên ghi tối thiểu: requester, approver, fingerprint public key, key ID, serial, principals, validity, options, ticket và kết quả cấp phát. Không log private key hoặc secrets. Dịch vụ ký nên từ chối principal ngoài allowlist và giới hạn thời gian tối đa ở phía server, thay vì tin input từ client.

Một luồng trưởng thành thường là: xác thực danh tính → kiểm tra trạng thái thiết bị/MFA → duyệt vai trò → ký bằng CA được bảo vệ → giao certificate → ghi audit → để certificate tự hết hạn. Với quyền đặc biệt, có thể yêu cầu phê duyệt hai người hoặc just-in-time access.

12. Lộ trình chuyển đổi an toàn

1. Thử nghiệm trên một nhóm server không quan trọng và một principal chỉ đọc.
2. Phân phối CA public key bằng configuration management; xác minh fingerprint.
3. Giữ authorized_keys như đường rollback trong giai đoạn chuyển tiếp.
4. Kiểm thử certificate hợp lệ, hết hạn, sai principal, sai CA và KRL.
5. Xác nhận audit log chứa key ID/serial đủ để điều tra.
6. Mở rộng theo nhóm máy chủ và chuẩn hóa thời hạn theo mức quyền.
7. Chỉ loại bỏ khóa tĩnh sau khi rollback, emergency access và quy trình CA outage đã được diễn tập.

13. Checklist production

• CA private key không nằm trên server đích.
• User CA và host CA tách riêng.
• Certificate có serial, key ID có ý nghĩa và thời hạn ngắn.
• Principals được allowlist; người yêu cầu không tự chọn quyền tùy ý.
• sshd -t chạy thành công trước mọi lần reload.
• Có phiên quản trị thứ hai và rollback trong rollout.
• KRL được triển khai nguyên tử và giám sát.
• Đồng hồ được đồng bộ; cảnh báo gần hết hạn CA/policy nếu có.
• Sudo, network và application authorization vẫn được kiểm soát độc lập.

Tài liệu tham khảo

• OpenBSD manual: ssh-keygen
• OpenBSD manual: sshd_config
• OpenBSD manual: sshd

Kết luận

SSH CA giúp chuyển từ phân phối hàng loạt khóa tĩnh sang tin cậy tập trung, có danh tính, vai trò và thời hạn rõ ràng. Lợi ích chỉ xuất hiện khi CA private key được bảo vệ, principals bị giới hạn, certificate sống ngắn, revocation hoạt động và rollout có kiểm thử. Hãy bắt đầu nhỏ, giữ đường lui, đo log thực tế rồi mới mở rộng toàn bộ hạ tầng.