Loại bỏ mớ hỗn độn SSH Key: Quản lý truy cập tập trung với Smallstep Certificates

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

Bắt đầu nhanh: Triển khai SSH Certificate đầu tiên của bạn trong 5 phút

Việc quản lý các SSH key thô trên hơn 50 máy chủ không chỉ là một công việc tẻ nhạt — đó còn là một thảm họa bảo mật tiềm ẩn. Sau khi một cuộc tấn công brute-force nhắm vào tài khoản root của tôi 4.500 lần chỉ trong một giờ, tôi nhận ra rằng việc quản lý key truyền thống quá chậm chạp và rủi ro. Nếu bạn muốn thấy SSH certificate khắc phục vấn đề này ngay lập tức, chúng ta có thể thiết lập một Certificate Authority (CA) tối giản bằng Smallstep ngay bây giờ.

Trước tiên, hãy tải step CLI và step-ca cho máy điều khiển. Ở đây tôi sử dụng Ubuntu 22.04:

wget https://dl.step.sm/gh-release/cli/gh-release-header/v0.24.4/step-cli_0.24.4_amd64.deb
sudo dpkg -i step-cli_0.24.4_amd64.deb

wget https://dl.step.sm/gh-release/ca/gh-release-header/v0.24.2/step-ca_0.24.2_amd64.deb
sudo dpkg -i step-ca_0.24.2_amd64.deb

Tiếp theo, hãy khởi tạo CA của bạn. Lệnh này sẽ tạo cấu hình và các root key dùng để ký định danh của bạn:

step ca init --name="My-Internal-CA" \
    --provisioner="[email protected]" \
    --dns="localhost" \
    --address=":9000"

Khởi chạy CA server trong một cửa sổ terminal riêng biệt:

step-ca $(step path)/config/ca.json

Để ký một user key, hãy chạy lệnh sau:

step ssh certificate [email protected] id_rsa

Lệnh này sẽ tạo ra id_rsa-cert.pub. Thật đơn giản. Thay vì sao chép public key vào từng node, bạn chỉ cần yêu cầu các máy chủ tin tưởng CA của mình một lần và không bao giờ phải chạm vào authorized_keys nữa. Đây là một bước chuyển đổi căn bản trong cách bạn xử lý truy cập hạ tầng.

Cái giá thực sự của SSH Key truyền thống

Tất cả chúng ta đều đã từng làm việc này: tạo một RSA key, chạy ssh-copy-id, và hy vọng không bao giờ phải đụng vào nó nữa. Cách này ổn với các dự án cá nhân. Nhưng khi nhóm của bạn phát triển, bạn sẽ gặp trở ngại. Khi một kỹ sư DevOps rời công ty, bạn phải xóa public key của họ khỏi mọi thực thể production một cách thủ công. Bỏ sót một cái? Bạn đã để lại một cửa sau (backdoor) vĩnh viễn.

Sau đó là vấn đề đau đầu mang tên “Tin tưởng trong lần sử dụng đầu tiên” (TOFU). Bạn có biết cảnh báo đáng sợ đó khi SSH vào một máy chủ mới không? Hầu hết các kỹ sư chỉ gõ “yes” mà không cần suy nghĩ. Thói quen đó là món quà cho những kẻ tấn công đang tìm cách thực hiện các cuộc tấn công Man-in-the-Middle (MITM).

Tại sao Certificates lại ưu việt hơn

SSH Certificates giới thiệu một Bên thứ ba: Certificate Authority. Hãy coi nó như một hệ thống hộ chiếu kỹ thuật số. Máy chủ của bạn không cần biết cá nhân bạn. Chúng chỉ cần tin tưởng chính phủ (CA) đã cấp hộ chiếu (Certificate) cho bạn.

  • authorized_keys trống: Máy chủ chỉ cần public key của CA. Nếu certificate được ký bởi CA đó, cánh cửa sẽ mở ra.
  • Truy cập dựa trên vai trò (RBAC): Bạn có thể nhúng trực tiếp tên người dùng hoặc vai trò cụ thể vào certificate.
  • Thời hạn tích hợp: Cấp các certificate chỉ tồn tại trong 8 hoặc 12 giờ. Nếu một chiếc laptop bị mất cắp lúc 6 giờ tối, quyền truy cập của kẻ trộm sẽ biến mất vào sáng hôm sau.

Lợi thế của Smallstep

Smallstep là công cụ giúp điều này trở nên thực tế. Nó cung cấp step-ca, một CA nhẹ và bảo mật được thiết kế để tự động hóa. Hãy quên việc ký thủ công đi. Bạn có thể liên kết Smallstep với các Nhà cung cấp định danh (Identity Provider) hiện có như Okta, Google hoặc GitHub. Một lập trình viên đăng nhập qua SSO, và Smallstep sẽ tự động trao cho họ một certificate tạm thời, chỉ có hiệu lực trong ngày.

Thiết lập nâng cao: Tự động hóa sự tin tưởng của Host và User

Để loại bỏ hoàn toàn các cảnh báo SSH, bạn phải cấu hình sự tin tưởng theo cả hai hướng.

1. Hướng dẫn máy chủ tin tưởng CA

Các máy chủ Linux mục tiêu cần biết rằng CA của bạn là hợp lệ. Đầu tiên, hãy lấy public SSH key của CA:

step ssh config --ssh-ca-user

Lưu key này vào /etc/ssh/trusted-user-ca-keys.pem trên máy chủ, sau đó cập nhật /etc/ssh/sshd_config:

# Trỏ SSH tới CA key của bạn
TrustedUserCAKeys /etc/ssh/trusted-user-ca-keys.pem

Khởi động lại dịch vụ bằng sudo systemctl restart ssh. Giờ đây, bất kỳ người dùng nào có certificate được ký bởi CA đều có thể truy cập. Không cần đồng bộ hóa key thủ công.

2. Loại bỏ cảnh báo “Unknown Host”

Các máy chủ cũng cần certificate. Bạn có thể ký host certificate trong quá trình khởi tạo (provisioning) thông qua Terraform hoặc Ansible. Trong tệp /etc/ssh/sshd_config của máy chủ, hãy thêm:

HostKey /etc/ssh/ssh_host_ecdsa_key
HostCertificate /etc/ssh/ssh_host_ecdsa_key-cert.pub

Trên máy cục bộ của bạn, hãy thêm host key của CA vào ~/.ssh/known_hosts:

@cert-authority * ecdsa-sha2-nistp256 AAAAE... (public key của CA)

Giờ đây, SSH client của bạn sẽ tin tưởng mọi máy chủ mà CA đã ký. Không còn các dòng nhắc nhở. Không còn rủi ro MITM.

3. Tích hợp SSO với ‘step ssh login’

Tiêu chuẩn vàng là quy trình step ssh login thực tế. Khi nhóm của bạn bắt đầu ngày làm việc, họ chỉ cần chạy một lệnh:

step ssh login [email protected]

Một trình duyệt sẽ hiện ra, họ xác thực bằng SSO của công ty, và Smallstep sẽ nạp một certificate có thời hạn 12 giờ vào SSH agent của họ. Người dùng thậm chí không bao giờ nhìn thấy tệp private key. Quy trình này rất liền mạch và cực kỳ bảo mật.

Thực tế triển khai: Những bài học kinh nghiệm

Chuyển sang sử dụng certificate đòi hỏi một sự thay đổi trong chiến lược. Dưới đây là những gì tôi đã học được khi triển khai hệ thống này trong các môi trường có lưu lượng truy cập cao.

Chiến lược thu hồi (Revocation)

Các certificate thời hạn ngắn (dưới 16 giờ) thường không cần Danh sách thu hồi (Revocation List). Nếu một key bị lộ, bạn chỉ cần đợi nó hết hạn. Đối với các thông tin xác thực có thời hạn dài hơn, Smallstep hỗ trợ Key Revocation Lists (KRLs). Nếu xảy ra vi phạm, bạn cập nhật KRL trên các máy chủ của mình để chặn một ID cụ thể ngay lập tức.

Độ tin cậy là ưu tiên hàng đầu

Đừng chạy step-ca trong một terminal ngẫu nhiên hay một phiên screen. Hãy sử dụng tệp unit systemd. Vì CA hiện là trái tim của hạ tầng, hãy chạy nó trong cấu hình High Availability (HA) hoặc phía sau một bộ cân bằng tải (load balancer) đáng tin cậy khi nhóm của bạn phát triển hơn vài người.

Giao thức “Phá kính” (Trường hợp khẩn cấp)

Khi mới triển khai Smallstep, hãy giữ một SSH key truyền thống trong authorized_keys của quản trị viên. Nếu bạn cấu hình sai sự tin tưởng CA, bạn chắc chắn không muốn bị khóa khỏi trung tâm dữ liệu của chính mình. Khi quá trình tự động hóa đã ổn định, bạn có thể loại bỏ hoàn toàn các static key này.

Kiểm toán và khả năng hiển thị

Smallstep ghi nhật ký mọi yêu cầu certificate. Điều này tạo ra một dấu vết kiểm toán (audit trail) hoàn hảo. Bạn có thể biết chính xác ai đã truy cập vào cái gì và khi nào. Hãy chuyển các log này vào Grafana hoặc ELK stack để theo dõi trong thời gian thực. Đây là một sự nâng cấp khổng lồ so với việc lùng sục trong các thư mục .ssh trên hàng ngàn node.

Chuyển sang SSH certificate là một khoản đầu tư mang lại sự an tâm. Bạn đang thay thế việc quản lý tệp thủ công, dễ sai sót bằng một hệ thống dựa trên định danh có khả năng mở rộng. Không còn nỗi lo bảo mật lúc nửa đêm — chỉ còn sự truy cập sạch sẽ và được tự động hóa.

Share: