Posted inSecurity

Bỏ qua authorized_keys: Cách dùng SSH CA để quản lý truy cập Server tập trung

Security tutorial - IT technology blog
Security tutorial - IT technology blog

Nỗi lo mang tên authorized_keys

Giả sử team bạn có 50 server và 10 nhân sự. Mỗi khi có thành viên mới, bạn phải cặm cụi xin Public Key rồi SSH vào từng máy để chèn vào file ~/.ssh/authorized_keys. Quy trình này mất ít nhất 30-40 phút và cực kỳ dễ sai sót.

Vấn đề thực sự phát sinh khi có người nghỉ việc. Trong một đợt audit bảo mật cho hệ thống Fintech năm ngoái, mình từng sốc khi thấy key của một dev đã nghỉ từ… 2 năm trước vẫn nằm chễm chệ trên server production. Chỉ cần một server bị bỏ sót, hệ thống của bạn đã xuất hiện lỗ hổng chết người. SSH Certificate Authority (SSH CA) chính là lời giải để chấm dứt tình trạng quản lý phân tán này.

SSH CA hoạt động như thế nào?

Thay vì bắt server phải ghi nhớ danh sách dài dằng dặc các Public Key, chúng ta sẽ chuyển sang mô hình “Cục cấp căn cước”. Bạn chỉ cần khai báo với server rằng: “Nếu ai có chứng chỉ do tôi cấp, hãy cho họ vào”.

Cơ chế này vận hành qua ba bước đơn giản:

  • Phía Server: Chỉ tin tưởng duy nhất một “chữ ký số” từ máy CA.
  • Phía Client (User): Gửi Public Key cho máy CA để ký xác nhận. CA trả về một Certificate (chứng chỉ).
  • Khi kết nối: User trình Certificate ra. Server kiểm tra chữ ký, nếu khớp là mở cửa ngay.

Cái hay của SSH CA là khả năng thiết lập thời hạn (Expiration). Bạn có thể cấp chứng chỉ chỉ có hiệu lực trong đúng 8 tiếng làm việc. Sau thời gian đó, chứng chỉ tự vô hiệu hóa. Dù máy tính của dev có bị mất cắp, hacker cũng không thể dùng key đó để truy cập vào ngày hôm sau.

Quy trình triển khai thực tế

Bạn cần chuẩn bị một máy làm CA (nên là máy offline hoặc server biệt lập) và các server mục tiêu (Target Server).

Bước 1: Khởi tạo “con dấu” cho Certificate Authority

Trên máy CA, chúng ta tạo cặp khóa gốc. Đây là tài sản quan trọng nhất, hãy bảo vệ nó bằng passphrase cực mạnh.

# Tạo thư mục lưu trữ
mkdir ~/ssh-ca && cd ~/ssh-ca

# Sử dụng thuật toán ed25519 để tối ưu bảo mật
ssh-keygen -t ed25519 -f ssh_ca -C "Company SSH CA"

Lệnh này tạo ra ssh_ca (Private Key – tuyệt mật) và ssh_ca.pub (Public Key – dùng để phân phối).

Bước 2: Cấu hình Server để tin tưởng CA

Bạn cần đẩy file ssh_ca.pub lên tất cả server mục tiêu. Ví dụ, đặt tại /etc/ssh/ssh_ca.pub.

# Đẩy file lên server
scp ssh_ca.pub [email protected]:/etc/ssh/

Mở file cấu hình SSH trên server mục tiêu:

sudo nano /etc/ssh/sshd_config

Thêm dòng cấu hình sau xuống cuối file:

TrustedUserCAKeys /etc/ssh/ssh_ca.pub

Cuối cùng, khởi động lại dịch vụ để áp dụng thay đổi:

sudo systemctl restart ssh

Bước 3: Ký chứng chỉ cho nhân viên

Khi bạn An (username: an.nguyen) cần truy cập, bạn ấy sẽ gửi Public Key cho bạn. Bạn thực hiện ký xác nhận:

# Ký key có hiệu lực 1 ngày với định danh an.nguyen
ssh-keygen -s ssh_ca -I "an.nguyen-access" -n an.nguyen -V +1d id_ed25519.pub

Các tham số quan trọng:

  • -s ssh_ca: Dùng khóa CA để ký.
  • -n an.nguyen: Chỉ định username cụ thể được phép đăng nhập.
  • -V +1d: Thời hạn chứng chỉ. Bạn có thể siết chặt hơn như +4h (4 giờ).

Kết quả trả về là file id_ed25519-cert.pub. Bạn gửi lại file này cho An.

Bước 4: Kiểm tra kết nối

An chỉ cần để file chứng chỉ vào thư mục ~/.ssh/ trên máy cá nhân. Khi thực hiện lệnh SSH, mọi thứ sẽ diễn ra tự động.

ssh [email protected]

An đã vào được server thành công. Bạn không cần chạm vào file authorized_keys của bất kỳ server nào nữa.

Nâng cao: Xóa bỏ cảnh báo “Unknown Host”

Mỗi khi SSH vào server mới, chúng ta thường thấy thông báo hỏi có tin tưởng fingerprint hay không. SSH CA có thể xử lý việc này bằng Host Certificate.

  1. Ký Public Key của chính Server bằng khóa CA với cờ -h.
  2. Cấu hình HostCertificate trong file sshd_config của server.
  3. Thêm dòng @cert-authority * [Nội dung ssh_ca.pub] vào file known_hosts của máy cá nhân.

Từ nay, mọi server trong hệ thống của bạn sẽ được máy tính cá nhân tự động tin tưởng. Không còn những dòng cảnh báo gây phiền nhiễu.

Kinh nghiệm thực tế khi vận hành

Triển khai SSH CA rất sướng, nhưng hãy lưu ý ba điểm sau:

  • An toàn là trên hết: Nếu lộ CA Private Key, hacker sẽ có quyền vào mọi server. Hãy cân nhắc lưu key trong YubiKey hoặc các thiết bị HSM chuyên dụng.
  • Tự động hóa: Đừng ký thủ công mãi. Bạn nên dùng HashiCorp Vault để cấp chứng chỉ qua API. Khi đó, dev chỉ cần login vào Vault để lấy chứng chỉ dùng trong ngày.
  • Truy vết: Kiểm tra log tại /var/log/auth.log. Mọi phiên đăng nhập sẽ ghi rõ Key ID (tham số -I), giúp bạn biết chính xác ai đã vào máy lúc nào.

Chuyển đổi sang SSH CA là bước đi chuyên nghiệp cho bất kỳ team DevOps nào. Nó không chỉ giúp bạn nhàn hơn mà còn nâng tầm bảo mật hệ thống lên một đẳng cấp mới.

Share:
Tags: