Posted inLinux

SSH Certificate Authority trên Linux: Bỏ authorized_keys để quản lý truy cập tập trung

Linux tutorial - IT technology blog
Linux tutorial - IT technology blog

So sánh các mô hình truy cập: Key tĩnh so với SSH CA tập trung

Quản lý các SSH key thô trên từ 50 máy chủ Linux trở lên là một cơn ác mộng về mặt vận hành. Thử hình dung: một kỹ sư mới gia nhập, và bạn đẩy public key của họ lên hàng chục máy ảo bằng Ansible. Sáu tháng sau, họ chuyển công ty. Liệu có ai kiểm tra xem key của họ đã được xóa sạch khỏi mọi máy staging, máy chủ backup và hệ thống legacy hay chưa? Thường là không.

Dưới đây là so sánh giữa các phương pháp phổ biến:

  • Sự tràn lan của authorized_keys: Mỗi node lưu trữ một bản sao riêng lẻ của từng public key của lập trình viên trong ~/.ssh/authorized_keys. Khi có 25 kỹ sư truy cập vào 80 máy, bạn phải xoay sở với 2.000 mục public key. Nếu một máy tính cá nhân bị xâm nhập, bạn buộc phải chạy ngay các playbook dọn dẹp trên toàn bộ hệ thống máy chủ.
  • Tích hợp thư mục LDAP hoặc PAM: Các node sẽ truy vấn một identity provider bên ngoài như FreeIPA hoặc Active Directory trong quá trình SSH handshake. Dù việc kiểm soát truy cập được tập trung hóa, cách này lại tạo ra sự phụ thuộc cứng vào mạng. Nếu node LDAP gặp sự cố hoặc rule tường lửa bị lỗi, quản trị viên có thể bị khóa khỏi các shell khôi phục khẩn cấp.
  • OpenSSH Certificate Authority (SSH CA): Thay vì theo dõi từng key riêng lẻ của client, các host đích chỉ cần tin cậy một public key CA duy nhất (có thể lưu trữ offline). Client yêu cầu CA ký vào public key cục bộ của họ. Đổi lại, họ nhận được một chứng chỉ đã ký có hiệu lực trong một khoảng thời gian cụ thể—chẳng hạn như 8 giờ—với username rõ ràng được đính kèm bên trong. Các node đích sẽ xác thực chữ ký mật mã này cục bộ trong chưa đầy 10 mili giây mà không cần bất kỳ truy vấn mạng bên ngoài nào.

Ưu và nhược điểm của SSH CA

Ưu điểm

  • Không cần chỉnh sửa host khi nhân sự rời đi: Khi ai đó rời nhóm, bạn không cần phải thao tác gì trên các máy chủ đích. Bạn chỉ đơn giản là ngừng ký key của họ. Khi chứng chỉ hiện tại của họ hết hạn, quyền truy cập sẽ tự động chấm dứt.
  • Thời gian truy cập ngắn hạn: Bạn có thể cấp chứng chỉ có thời hạn tối đa 8 giờ để phục vụ cho một ca làm việc tiêu chuẩn. Ngay cả khi kỹ sư để lộ private key không mã hóa trên một chiếc laptop bị mất cắp, thông tin xác thực này cũng sẽ hết hạn trước khi kẻ tấn công kịp lợi dụng.
  • Ranh giới đặc quyền chính xác: Nhúng trực tiếp các tài khoản đích (ví dụ: deploy, ubuntu, postgres), dải IP nguồn và các lệnh bắt buộc vào ngay trong chữ ký.
  • Xác thực offline gốc: OpenSSH xử lý mọi thứ sẵn có bằng mật mã tích hợp. Bạn không cần bất kỳ daemon bên thứ ba hay background agent nào chạy trên các máy đích.

Nhược điểm cần cân nhắc

  • Private key ký của CA có giá trị cực cao: Nếu kẻ tấn công đánh cắp được private key của CA, họ có thể tự tạo quyền truy cập cấp root hợp lệ vào toàn bộ hạ tầng của bạn. Hãy lưu trữ nó offline, giới hạn quyền truy cập hoặc bảo vệ bằng hardware token như YubiKey.
  • Cần hạ tầng cấp phát khi mở rộng quy mô: Việc ký chứng chỉ thủ công bằng ssh-keygen hoạt động tốt cho các nhóm nhỏ từ 5 đến 10 quản trị viên. Khi quy mô vượt quá mức đó, bạn sẽ cần một gateway tự động hóa như HashiCorp Vault, Smallstep Step-CA hoặc Teleport.

Tổng quan kiến trúc

Một mô hình triển khai SSH CA trong môi trường production dựa trên ba vai trò riêng biệt:

  1. Máy chủ CA (CA Host): Một máy trạm cô lập, được tăng cường bảo mật (hardened) hoặc bastion offline. Máy này lưu trữ private signing key (ssh_user_ca) và công khai public key (ssh_user_ca.pub).
  2. Các máy chủ đích (Target Servers): Mọi host production trong toàn bộ hệ thống của bạn. Mỗi máy chủ sẽ trỏ sshd_config của mình tới ssh_user_ca.pub.
  3. Client: Các kỹ sư tạo keypair ed25519 tiêu chuẩn tại máy cục bộ, yêu cầu ký chứng chỉ và xác thực bằng file id_ed25519-cert.pub được tạo ra.

Quy tắc nằm lòng: Luôn mở sẵn một terminal root dự phòng trong một session tmux đang chạy khi chỉnh sửa cấu hình SSH daemon. Nếu gõ sai một chỉ thị cấu hình, shell đang mở đó sẽ cứu bạn khỏi việc bị khóa hoàn toàn khỏi hệ thống production.

Hướng dẫn triển khai từng bước

Bước 1: Tạo cặp khóa CA (CA Keypair)

Chạy các lệnh sau trên máy chủ ký chuyên dụng. Tuyệt đối không đặt private key này trên các máy chủ đa mục đích:

# Tạo thư mục bảo mật cho CA
sudo mkdir -p /etc/ssh/ca
sudo chmod 700 /etc/ssh/ca
cd /etc/ssh/ca

# Tạo cặp khóa root CA với mật khẩu bảo vệ (passphrase) mạnh
sudo ssh-keygen -t ed25519 -C "prod-ssh-user-ca" -f ssh_user_ca

# Phân quyền bảo mật nghiêm ngặt cho file
sudo chmod 600 /etc/ssh/ca/ssh_user_ca
sudo chmod 644 /etc/ssh/ca/ssh_user_ca.pub

Bước 2: Cấu hình các máy chủ đích tin cậy CA

Sao chép ssh_user_ca.pub tới các máy chủ của bạn. Lưu file tại /etc/ssh/trusted-user-ca-keys.pub:

# Sao chép public key của CA vào node đích
sudo tee /etc/ssh/trusted-user-ca-keys.pub <<'EOF'
ssh-ed25519 AAAAC3NzaC1lZDI1NTE5AAAAIPEXAMPLEKEY1234567890 prod-ssh-user-ca
EOF

sudo chmod 644 /etc/ssh/trusted-user-ca-keys.pub

Tiếp theo, cấu hình sshd chấp nhận bất kỳ chứng chỉ hợp lệ nào được ký bởi CA này. Tạo một drop-in file tại /etc/ssh/sshd_config.d/ca.conf (hoặc chỉnh sửa /etc/ssh/sshd_config):

TrustedUserCAKeys /etc/ssh/trusted-user-ca-keys.pub
AuthorizedPrincipalsFile none

Kiểm tra cú pháp trước khi áp dụng. Một chỉ thị bị sai cú pháp có thể khiến cổng SSH ngừng hoạt động:

# Kiểm tra cú pháp cấu hình
sudo sshd -t

# Nếu không có lỗi, reload lại sshd một cách an toàn
sudo systemctl reload sshd

Bước 3: Cấp chứng chỉ đã ký cho người dùng

Kỹ sư tạo một cặp key ed25519 tiêu chuẩn trên laptop cá nhân:

# Chạy trên laptop của client
ssh-keygen -t ed25519 -f ~/.ssh/id_ed25519

Kỹ sư chỉ gửi file id_ed25519.pub cho quản trị viên CA. Trên máy chủ CA, tiến hành ký public key với các principal phù hợp và thời hạn hiệu lực chặt chẽ:

# Ký public key trên máy chủ CA
ssh-keygen -s /etc/ssh/ca/ssh_user_ca \
  -I alex-laptop \
  -n ubuntu,deploy \
  -V +8h \
  -z 2026110501 \
  id_ed25519.pub

Ý nghĩa của các tham số này:

  • -s /etc/ssh/ca/ssh_user_ca: Đường dẫn đến private key của CA.
  • -I alex-laptop: Mã định danh key dễ đọc (Key ID). Giá trị này sẽ được ghi trực tiếp vào /var/log/auth.log của máy chủ đích khi đăng nhập.
  • -n ubuntu,deploy: Danh sách tài khoản Linux cụ thể mà chứng chỉ này được phép đăng nhập. Điều này ngăn chặn việc một lập trình viên cấp dưới đăng nhập bằng tài khoản root.
  • -V +8h: Thời gian hiệu lực của chứng chỉ. Ở đây chứng chỉ sẽ hết hạn sau 8 giờ kể từ khi cấp. Bạn cũng có thể chỉ định mốc thời gian tuyệt đối (ví dụ: 20261105090000:20261105170000).
  • -z 2026110501: Số serial duy nhất dùng cho việc theo dõi và kiểm toán (audit).

Lệnh trên sẽ tạo ra một chứng chỉ đã ký có tên là id_ed25519-cert.pub.

Bước 4: Kết nối bằng chứng chỉ

Gửi lại file id_ed25519-cert.pub cho kỹ sư. Họ cần đặt file này vào thư mục ~/.ssh/, ngay cạnh private key của mình.

Kiểm tra nội dung chứng chỉ để xem quyền hạn và thời hạn còn lại:

ssh-keygen -L -f ~/.ssh/id_ed25519-cert.pub

Bạn sẽ thấy các siêu dữ liệu (metadata) được nhúng bên trong chứng chỉ:

Type: [email protected] user certificate
Public key: ED25519-CERT SHA256:7vQ... 
Signing CA: ED25519 SHA256:4kM... (prod-ssh-user-ca)
Key ID: "alex-laptop"
Serial: 2026110501
Valid: from 2026-11-05T08:30:00 to 2026-11-05T16:30:00
Principals: 
        ubuntu
        deploy
Critical Options: (none)
Extensions: 
        permit-pty
        permit-user-rc

Do tên file chứng chỉ khớp với tên private key (id_ed25519 và id_ed25519-cert.pub), OpenSSH client sẽ tự động tải chứng chỉ này:

ssh -v [email protected]

Kiểm tra log chi tiết (verbose log). Bạn sẽ thấy dòng Server accepts key: ... [Certificate]. Quá trình đăng nhập thành công ngay cả khi file ~/.ssh/authorized_keys từ xa hoàn toàn trống hoặc đã bị khóa quyền.

Bước 5: Thu hồi chứng chỉ trước thời hạn

Nếu một kỹ sư bị mất laptop trong giờ nghỉ trưa, bạn không cần phải chờ hết khoảng thời gian 8 giờ. Hãy thu hồi chứng chỉ ngay bằng danh sách thu hồi khóa OpenSSH (Key Revocation List – KRL).

# Trên máy chủ CA, thu hồi chứng chỉ có số serial 2026110501
ssh-keygen -k -f /etc/ssh/revoked-keys -s /etc/ssh/ca/ssh_user_ca.pub -z 2026110501

Đẩy file /etc/ssh/revoked-keys vừa tạo lên toàn bộ hệ thống máy chủ và chỉ định cho sshd đường dẫn tới file đó:

# Thêm vào /etc/ssh/sshd_config.d/ca.conf
RevocationFile /etc/ssh/revoked-keys

Tải lại dịch vụ bằng lệnh sudo systemctl reload sshd. Các máy chủ đích sẽ ngay lập tức từ chối các kết nối cung cấp số serial đã bị thu hồi.

Share:
Tags: