Quản lý khóa SSH tập trung bằng SSH Certificate Authority (SSH CA)

Khi quản trị một vài máy chủ đơn lẻ, quy trình thông dụng mà nhiều kỹ sư thường áp dụng là tạo cặp khóa bất đối xứng và sao chép thủ công khóa công khai vào tệp ~/.ssh/authorized_keys trên từng máy, như chúng tôi từng chia sẻ trong bài viết về sử dụng SSH key an toàn. Cách làm này trực quan, không đòi hỏi thêm hạ tầng phụ trợ và hoạt động trơn tru trong giai đoạn đầu của dự án.

Tuy nhiên, khi hạ tầng mở rộng lên hàng chục máy chủ VPS và đội ngũ kỹ thuật có thêm nhiều thành viên—từ lập trình viên, chuyên viên kiểm thử cho đến kỹ sư dữ liệu—mô hình khóa tĩnh bắt đầu bộc lộ những rủi ro vận hành nghiêm trọng. Mỗi lần tuyển thêm nhân sự, bạn phải chạy lệnh sao chép khóa tới toàn bộ các node. Đáng ngại hơn, khi một nhân sự chuyển đổi vị trí hoặc rời khỏi tổ chức, việc truy vết và dọn dẹp sạch sẽ khóa công khai của họ trên từng máy chủ phân tán gần như trở thành một nhiệm vụ quá tải. Một chiếc khóa tĩnh bị bỏ quên trên một máy chủ thử nghiệm (staging) có thể vô tình trở thành lỗ hổng truy cập tồn tại nhiều tháng sau đó.

Giải pháp chuẩn mực được các hạ tầng lớn áp dụng để giải quyết bài toán này là chuyển từ cơ chế khóa tĩnh sang SSH Certificate Authority (SSH CA). Thay vì để từng máy chủ phải ghi nhớ danh sách khóa của từng cá nhân, máy chủ chỉ cần tin cậy một khóa công khai duy nhất của cơ quan cấp chứng chỉ (CA). Kỹ sư sẽ nhận được các chứng chỉ SSH ngắn hạn có giá trị trong ngày làm việc, tự động mất hiệu lực mà không cần bất kỳ can thiệp thủ công nào trên máy chủ đích.

Bài viết này đi sâu vào nguyên lý mật mã học của OpenSSH Certificate, cách thiết lập một SSH CA bằng chính công cụ OpenSSH gốc, phương pháp tự động hóa cấp chứng chỉ qua công cụ mã nguồn mở step-ca kết hợp Single Sign-On (SSO), và quy trình xử lý khẩn cấp khi cần thu hồi quyền truy cập tức thì.

Điểm giới hạn của việc quản lý SSH bằng authorized_keys tĩnh

Để hiểu vì sao cần tới SSH CA, chúng ta cần nhìn thẳng vào những điểm nghẽn kỹ thuật của phương pháp truyền thống khi hạ tầng phát triển.

1. Hiện tượng trôi nổi khóa công khai (Key Sprawl)

Trong mô hình khóa tĩnh, mối quan hệ giữa danh tính kỹ sư và quyền truy cập máy chủ được lưu trực tiếp tại tệp ~/.ssh/authorized_keys của từng tài khoản người dùng trên từng máy chủ.

Giả sử doanh nghiệp có 8 kỹ sư cần quyền truy cập vào 15 máy chủ (bao gồm máy chủ web, cơ sở dữ liệu, máy chủ hàng đợi và máy chủ ghi nhật ký). Số lượng khóa cần được duy trì và đồng bộ là 8 × 15 = 120 điểm lưu trữ. Khi số lượng máy chủ tăng lên vài chục node, việc kiểm soát xem tệp authorized_keys trên máy chủ nào đang chứa khóa của ai trở nên vô cùng khó khăn. Khóa công khai của một lập trình viên thực tập đã kết thúc hợp đồng từ 6 tháng trước vẫn có thể nằm nguyên vẹn trên một node phụ trợ mà không ai hay biết.

2. Khóa tĩnh không có khái niệm về thời hạn hiệu lực

Về mặt thiết kế kỹ thuật, một cặp khóa SSH thông thường (dù là RSA 4096-bit hay Ed25519 hiện đại) không mang theo bất kỳ siêu dữ liệu (metadata) nào về thời gian. Một khi khóa công khai đã được thêm vào authorized_keys, khóa riêng tư tương ứng sẽ có quyền truy cập vĩnh viễn cho đến khi có người dùng tài khoản quản trị đăng nhập vào máy chủ để xóa dòng chứa khóa đó đi.

Điều này tạo ra một rủi ro tiềm tàng: nếu máy tính xách tay của một kỹ sư bị thất lạc hoặc mã độc sao chép được khóa riêng tư từ ổ đĩa cá nhân, kẻ tấn công có thể sử dụng chiếc khóa này bất kỳ lúc nào trong tương lai.

3. Hạn chế của các công cụ tự động hóa cấu hình

Nhiều đội ngũ cố gắng khắc phục tình trạng này bằng cách dùng Ansible, Puppet hoặc SaltStack để đẩy và xóa khóa định kỳ. Mặc dù cách này giúp giảm bớt thao tác tay, nó vẫn tạo ra trạng thái phân tán (stateful distribution).

Nếu trong lúc Ansible chạy playbook thu hồi khóa, có một vài máy chủ VPS đang bị ngắt kết nối mạng tạm thời, đang tắt nguồn để bảo trì, hoặc một máy chủ mới vừa được tạo tự động từ template cũ, khóa của nhân sự đã nghỉ việc vẫn tiếp tục tồn tại trên các máy chủ đó. Nghĩa là quyền truy cập không được thu hồi một cách nhất quán trên toàn bộ hạ tầng.

Nguyên lý hoạt động của SSH Certificate Authority (SSH CA)

OpenSSH hỗ trợ cơ chế chứng chỉ số riêng biệt từ phiên bản 5.4. Cần phân biệt rõ rằng chứng chỉ SSH không sử dụng chuẩn chứng chỉ X.509 cồng kềnh thường thấy trên các website HTTPS/TLS, mà dùng một cấu trúc dữ liệu nhị phân chuyên dụng, tối giản và được xử lý rất nhanh bởi chính tiến trình sshd.

1. Chuỗi tin cậy mật mã học (Cryptographic Trust Chain)

Thay vì cấu hình từng máy chủ phải biết mặt từng kỹ sư, chúng ta áp dụng mô hình niềm tin bắc cầu:

• Doanh nghiệp khởi tạo một cặp khóa SSH đóng vai trò là Certificate Authority (CA).
• Toàn bộ máy chủ trong hạ tầng chỉ cần lưu một thông tin duy nhất: Khóa công khai của CA (ssh_user_ca.pub) thông qua chỉ thị cấu hình TrustedUserCAKeys /etc/ssh/ssh_user_ca.pub.
• Khi kỹ sư cần truy cập hệ thống, họ dùng khóa công khai cá nhân gửi tới CA để xin cấp một chứng chỉ SSH (SSH Certificate). CA dùng khóa riêng tư của mình để ký lên chứng chỉ này.
• Khi kỹ sư kết nối vào máy chủ qua lệnh ssh, họ gửi kèm chứng chỉ đã được ký. Máy chủ dùng khóa công khai của CA để giải mã và kiểm tra chữ ký. Nếu chữ ký hợp lệ và các điều kiện bên trong chứng chỉ thỏa mãn, máy chủ lập tức cho phép đăng nhập mà không cần kiểm tra tệp authorized_keys.

Như vậy, máy chủ không cần lưu bất kỳ dữ liệu nào về từng kỹ sư cụ thể. Khi có kỹ sư mới gia nhập, chỉ cần CA cấp chứng chỉ cho họ; toàn bộ hệ thống máy chủ sẽ tự động chấp nhận kết nối mà không cần thay đổi bất kỳ tệp cấu hình nào.

2. Cấu trúc của một SSH User Certificate

Một chứng chỉ người dùng OpenSSH chứa các trường dữ liệu quan trọng sau:

1. Public Key: Khóa công khai thực tế của kỹ sư (thường dùng thuật toán Ed25519).
2. Key ID: Chuỗi định danh chứng chỉ, thường đặt theo định dạng ten_kysi_ngay_cap hoặc mã số định danh nội bộ. Giá trị này được in trực tiếp vào nhật ký hệ thống của máy chủ khi đăng nhập, hỗ trợ việc kiểm toán sau này.
3. Valid Principals: Danh sách các tài khoản người dùng cục bộ trên hệ điều hành mà chứng chỉ này được phép đăng nhập (ví dụ: ubuntu, deploy, devops). Nếu chứng chỉ chỉ ghi principal là deploy, kỹ sư sẽ không thể dùng nó để SSH vào tài khoản root hay admin.
4. Validity Period: Khoảng thời gian chứng chỉ có hiệu lực, quy định chính xác từ thời điểm nào đến thời điểm nào (ví dụ: chỉ có giá trị trong vòng 8 tiếng). Sau thời điểm này, tiến trình sshd sẽ tự động từ chối kết nối.
5. Serial Number: Số thứ tự của chứng chỉ, hỗ trợ quản lý và đưa vào danh sách thu hồi nếu xảy ra sự cố.
6. Extensions và Critical Options: Các cờ kiểm soát tính năng, chẳng hạn như cho phép hoặc cấm mở terminal tương tác (PTY), chuyển tiếp cổng (port forwarding), hoặc chuyển tiếp khóa (agent forwarding).

Triển khai SSH CA cơ bản bằng công cụ OpenSSH gốc

Trước khi đưa vào các hệ thống tự động hóa phức tạp, chúng ta sẽ xem xét cách vận hành một SSH CA thủ công bằng chính các lệnh gốc của OpenSSH. Thao tác này giúp bạn hiểu rõ từng mắt xích bảo mật mà không bị che khuất bởi các lớp phần mềm trung gian.

Bước 1: Khởi tạo cặp khóa Certificate Authority

Khóa CA cần được tạo trên một máy tính quản trị độc lập, có mức độ bảo mật cao hoặc được ngắt kết nối mạng (air-gapped), không nên đặt trực tiếp trên các máy chủ web thông thường.

Để tạo cặp khóa CA sử dụng thuật toán Ed25519:

mkdir -p /etc/ssh/ca
chmod 700 /etc/ssh/ca
cd /etc/ssh/ca

ssh-keygen -t ed25519 -f ssh_user_ca -C "HTS-Viet-User-CA-2026"

Hệ thống sẽ yêu cầu bạn nhập mật khẩu bảo vệ (passphrase) cho khóa riêng tư. Bạn nên đặt một mật khẩu có độ dài tối thiểu 16 ký tự bao gồm chữ hoa, chữ thường, số và ký tự đặc biệt. Sau khi hoàn tất, thư mục sẽ có hai tệp:

• ssh_user_ca: Khóa riêng tư của CA. Tệp này có mức độ nhạy cảm cao nhất trong toàn bộ hạ tầng. Bất kỳ ai có tệp này đều có thể ký chứng chỉ để đăng nhập vào mọi máy chủ. Cần phân quyền chặt bằng lệnh chmod 600 ssh_user_ca.
• ssh_user_ca.pub: Khóa công khai của CA. Tệp này sẽ được phân phối tới mọi máy chủ đích.

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

Trên mỗi máy chủ VPS trong cụm hạ tầng, bạn sao chép tệp ssh_user_ca.pub vào thư mục cấu hình hệ thống:

sudo cp ssh_user_ca.pub /etc/ssh/ssh_user_ca.pub
sudo chmod 644 /etc/ssh/ssh_user_ca.pub
sudo chown root:root /etc/ssh/ssh_user_ca.pub

Tiếp theo, mở tệp cấu hình của dịch vụ OpenSSH Daemon /etc/ssh/sshd_config và thêm chỉ thị:

# Khai bao khoa cong khai cua CA tin cay
TrustedUserCAKeys /etc/ssh/ssh_user_ca.pub

# Bat muc do ghi log chi tiet de kiem toan chung chi
LogLevel VERBOSE

Trước khi áp dụng thay đổi, luôn kiểm tra tính hợp lệ của cú pháp cấu hình để tránh sự cố bị khóa ngoài máy chủ:

sudo sshd -t

Nếu lệnh không trả về bất kỳ thông báo lỗi nào, bạn có thể nạp lại cấu hình dịch vụ một cách an toàn mà không làm gián đoạn các phiên SSH hiện tại:

sudo systemctl reload sshd

Bước 3: Ký cấp chứng chỉ cho kỹ sư

Giả sử một kỹ sư DevOps gửi khóa công khai của máy trạm cá nhân (id_ed25519.pub) cho quản trị viên. Quản trị viên tiến hành ký chứng chỉ với thời hạn 8 tiếng, chỉ cho phép đăng nhập vào tài khoản ubuntu và deploy:

ssh-keygen -s /etc/ssh/ca/ssh_user_ca \
  -I "engineer_devops_20261025" \
  -n "ubuntu,deploy" \
  -V +8h \
  -z 1001 \
  id_ed25519.pub

Giải thích ý nghĩa từng tham số:

• -s /etc/ssh/ca/ssh_user_ca: Chỉ định khóa riêng tư của CA dùng để ký.
• -I "engineer_devops_20261025": Gán Key ID định danh người dùng và ngày cấp.
• -n "ubuntu,deploy": Danh sách tài khoản người dùng hợp lệ (Principals).
• -V +8h: Thời hạn hiệu lực là 8 tiếng tính từ thời điểm thực thi lệnh.
• -z 1001: Số serial định danh chứng chỉ.
• id_ed25519.pub: Khóa công khai của kỹ sư được ký.

Sau khi thực thi, OpenSSH sẽ sinh ra tệp id_ed25519-cert.pub nằm cùng thư mục. Quản trị viên gửi tệp chứng chỉ này lại cho kỹ sư.

Bước 4: Kiểm tra nội dung chứng chỉ

Kỹ sư hoặc quản trị viên có thể xem chi tiết thông tin đã được đóng gói bên trong chứng chỉ bằng lệnh:

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

Đầu ra thực tế từ hệ thống sẽ hiển thị như sau:

id_ed25519-cert.pub:
        Type: ssh-ed25519-cert-v01@openssh.com user certificate
        Public key: ED25519-CERT SHA256:qR8...
        Signing CA: ED25519 SHA256:7uK... (HTS-Viet-User-CA-2026)
        Key ID: "engineer_devops_20261025"
        Serial: 1001
        Valid: from 2026-10-25T08:00:00 to 2026-10-25T16:00:00
        Principals: 
                ubuntu
                deploy
        Critical Options: (none)
        Extensions: 
                permit-X11-forwarding
                permit-agent-forwarding
                permit-port-forwarding
                permit-pty
                permit-user-rc

Bước 5: Thực hiện kết nối và kiểm tra nhật ký

Trên máy tính cá nhân của kỹ sư, đặt tệp chứng chỉ id_ed25519-cert.pub nằm cùng thư mục ~/.ssh/ với khóa riêng tư id_ed25519. Trình khách SSH của OpenSSH sẽ tự động phát hiện tệp -cert.pub tương ứng và đính kèm vào phiên bắt tay.

Kỹ sư thực hiện kết nối tới máy chủ VPS:

ssh -i ~/.ssh/id_ed25519 ubuntu@10.0.0.5

Ngay cả khi tệp ~/.ssh/authorized_keys trên máy chủ 10.0.0.5 hoàn toàn trống rỗng hoặc chưa từng chứa khóa của kỹ sư, phiên đăng nhập vẫn thành công.

Khi kiểm tra nhật ký xác thực trên máy chủ tại /var/log/auth.log (đối với Ubuntu/Debian) hoặc qua lệnh journalctl -u ssh, bạn sẽ thấy dòng nhật ký rõ ràng:

Accepted publickey for ubuntu from 10.0.0.12 port 51240 ssh2: ED25519-CERT SHA256:qR8... ID engineer_devops_20261025 (serial 1001) CA ED25519 SHA256:7uK...

Nhật ký ghi nhận chính xác: tài khoản nào đã được sử dụng (ubuntu), từ địa chỉ IP nào, sử dụng chứng chỉ có Key ID nào và do CA nào phát hành. Đây là cơ sở kiểm toán minh bạch, loại bỏ hoàn toàn tình trạng dùng chung khóa hoặc không xác định được danh tính người thực hiện thao tác.

Tự động hóa cấp chứng chỉ ngắn hạn bằng step-ca

Việc ký chứng chỉ thủ công bằng lệnh ssh-keygen -s như trên giúp chúng ta nắm vững cơ chế, nhưng không thực tế trong vận hành hàng ngày. Quản trị viên không thể ngồi trực để ký chứng chỉ mỗi sáng cho từng thành viên trong nhóm.

Để tự động hóa hoàn toàn quy trình này, chúng ta sử dụng step-ca (một giải pháp quản lý chứng chỉ nguồn mở phát triển bởi Smallstep) kết hợp với hệ thống quản lý danh tính (Identity Provider - IdP) hỗ trợ giao thức OpenID Connect (OIDC) như Google Workspace, Microsoft Entra ID hoặc Authentik.

1. Kiến trúc vận hành với step-ca

Mô hình tự động hóa hoạt động như sau:

1. Dịch vụ step-ca được triển khai bên trong một container Docker độc lập, lưu trữ khóa riêng tư của CA trong một volume được mã hóa.
2. step-ca được cấu hình làm việc với IdP của doanh nghiệp thông qua OIDC.
3. Kỹ sư cài đặt tiện ích dòng lệnh step trên máy trạm của họ. Đầu mỗi ngày làm việc, kỹ sư chạy một lệnh duy nhất:

   step ssh login devops@htsviet.vn

1. Lệnh này mở một tab trên trình duyệt web, yêu cầu kỹ sư đăng nhập bằng tài khoản email công ty và vượt qua bước xác thực đa yếu tố (MFA).
2. Sau khi xác thực thành công, IdP trả về token OIDC cho step. CLI này sẽ tự động tạo một cặp khóa SSH tạm thời trong bộ nhớ RAM, gửi yêu cầu tới step-ca, và nhận về chứng chỉ SSH có hiệu lực trong 8 tiếng.
3. Chứng chỉ này được tự động nạp thẳng vào tiến trình ssh-agent của máy trạm. Kỹ sư sử dụng lệnh ssh bình thường suốt ngày làm việc mà không cần nhập thêm mật khẩu.
4. Khi hết 8 tiếng (hoặc khi kỹ sư tắt máy), chứng chỉ tự động hết hạn và biến mất khỏi bộ nhớ.

2. Triển khai step-ca trên máy chủ quản trị bằng Docker Compose

Dưới đây là tệp cấu hình mẫu docker-compose.yml để khởi chạy dịch vụ step-ca:

version: '3.8'

services:
  step-ca:
    image: smallstep/step-ca:latest
    container_name: step-ca
    restart: unless-stopped
    ports:
      - "9000:9000"
    volumes:
      - ./step-data:/home/step
    environment:
      - DOCKER_STEPCA_INIT_NAME=HTS-Viet-CA
      - DOCKER_STEPCA_INIT_DNS_NAMES=ca.internal.htsviet.vn,localhost
      - DOCKER_STEPCA_INIT_SSH=true

Khởi tạo cấu hình ban đầu bằng lệnh:

docker compose run --rm step-ca step ca init \
  --name="HTS-Viet-Infrastructure" \
  --dns="ca.internal.htsviet.vn" \
  --address=":9000" \
  --provisioner="admin@htsviet.vn" \
  --ssh

Sau khi hoàn tất khởi tạo, trong thư mục cấu hình step-data/config/ca.json, bạn có thể thêm khối cấu hình OIDC Provisioner để kết nối tới hệ thống xác thực tập trung của công ty:

{
  "type": "OIDC",
  "name": "Google-Workspace",
  "clientID": "your-client-id.apps.googleusercontent.com",
  "clientSecret": "your-client-secret",
  "configurationEndpoint": "https://accounts.google.com/.well-known/openid-configuration",
  "claims": {
    "enableSSHCA": true
  },
  "domains": [
    "htsviet.vn"
  ]
}

Với cấu hình trên, chỉ những ai sở hữu hòm thư có đuôi miền @htsviet.vn và vượt qua bước xác thực hai lớp của Google mới có thể xin cấp chứng chỉ SSH để truy cập vào cụm máy chủ nội bộ.

Cơ chế thu hồi quyền khẩn cấp: Key Revocation List (KRL)

Một trong những ưu điểm lớn nhất của mô hình chứng chỉ ngắn hạn (8 đến 12 tiếng) là giảm bớt 95% nhu cầu thu hồi quyền thủ công. Nếu một nhân sự nghỉ việc, quản trị viên chỉ cần khóa tài khoản của họ trên hệ thống SSO/IdP trung tâm. Kỹ sư đó sẽ không thể xin cấp chứng chỉ mới vào ngày hôm sau, và quyền truy cập tự động chấm dứt khi chứng chỉ cũ hết thời hạn còn lại trong ngày.

Tuy nhiên, trong những tình huống khẩn cấp—chẳng hạn như một kỹ sư bị mất cắp máy tính xách tay trong giờ làm việc khi chứng chỉ vẫn còn 6 tiếng hiệu lực—bạn cần một cơ chế để chặn đứng quyền truy cập ngay lập tức. OpenSSH cung cấp tính năng Key Revocation List (KRL) cho mục đích này.

1. Khởi tạo và cập nhật danh sách KRL

KRL là một tệp nhị phân nén chứa danh sách các khóa hoặc số serial của chứng chỉ đã bị vô hiệu hóa.

Để thu hồi một chứng chỉ dựa trên số serial (ví dụ serial 1001 mà chúng ta đã cấp trước đó):

ssh-keygen -k -f /etc/ssh/ca/revoked_keys -s /etc/ssh/ca/ssh_user_ca -z 1001

Nếu muốn thu hồi trực tiếp bằng tệp khóa công khai của thiết bị bị xâm phạm:

ssh-keygen -k -f /etc/ssh/ca/revoked_keys compromised_key.pub

Để kiểm tra xem một chứng chỉ cụ thể đã nằm trong danh sách thu hồi hay chưa:

ssh-keygen -Q -l -f /etc/ssh/ca/revoked_keys id_ed25519-cert.pub

Nếu chứng chỉ đã bị thu hồi, lệnh sẽ trả về thông báo:

id_ed25519-cert.pub (ED25519-CERT SHA256:...): REVOKED

2. Kích hoạt KRL trên máy chủ đích

Trên các máy chủ VPS, bạn chỉ cần cấu hình đường dẫn tới tệp KRL trong /etc/ssh/sshd_config:

RevokedKeys /etc/ssh/revoked_keys

Điểm thuận tiện của cơ chế này là tiến trình sshd kiểm tra tệp revoked_keys trực tiếp trên mỗi kết nối mới. Do đó, khi bạn đồng bộ tệp revoked_keys mới tới máy chủ qua một lệnh rsync hoặc Ansible task, quyền truy cập sẽ bị chặn đứng tức thì mà không cần khởi động lại hay reload dịch vụ SSH daemon.

Sử dụng Host Certificate để loại bỏ cảnh báo máy chủ lạ

Bên cạnh User Certificate (xác thực người dùng với máy chủ), OpenSSH CA còn hỗ trợ Host Certificate (xác thực máy chủ với người dùng).

Khi bổ sung thêm máy chủ mới vào cụm, mỗi kỹ sư khi SSH lần đầu thường nhận được cảnh báo:

The authenticity of host '10.0.0.15' can't be established.
ED25519 key fingerprint is SHA256:abcd...
Are you sure you want to continue connecting (yes/no/[fingerprint])?

Hầu hết kỹ sư đều có thói quen gõ yes theo phản xạ mà không đối chiếu lại fingerprint thực tế của máy chủ. Thói quen này làm giảm hiệu quả phòng vệ trước các cuộc tấn công trung gian (Man-in-the-Middle) trên đường truyền mạng nội bộ.

Quy trình thiết lập Host Certificate

1. Ký Host Key của máy chủ bằng CA:

Trên máy CA, lấy khóa công khai host của máy chủ VPS (thường là /etc/ssh/ssh_host_ed25519_key.pub) và thực hiện ký:

   ssh-keygen -s /etc/ssh/ca/ssh_host_ca \
     -I "web-node-01" \
     -h \
     -n "web-node-01.internal.htsviet.vn,10.0.0.15" \
     -V +52w \
     /etc/ssh/ssh_host_ed25519_key.pub

Lưu ý cờ -h biểu thị đây là chứng chỉ dành cho máy chủ (Host Certificate).

1. Cấu hình trên máy chủ VPS (/etc/ssh/sshd_config):

Sao chép tệp chứng chỉ ssh_host_ed25519_key-cert.pub vừa tạo về máy chủ và thêm dòng:

   HostCertificate /etc/ssh/ssh_host_ed25519_key-cert.pub

Sau đó reload lại sshd.

1. Cấu hình trên máy trạm của toàn bộ kỹ sư:

Mỗi kỹ sư chỉ cần thêm duy nhất một dòng vào tệp ~/.ssh/known_hosts trên máy tính của họ:

   @cert-authority *.internal.htsviet.vn,10.0.0.* ssh-ed25519 AAAAC3NzaC1lZDI1NTE5AAAAI... (Khóa công khai của Host CA)

Từ thời điểm này, bất kỳ máy chủ mới nào được tạo ra trong dải mạng nội bộ hoặc tên miền *.internal.htsviet.vn và có Host Certificate do CA ký sẽ được máy trạm kỹ sư tự động xác thực ngầm định. Cảnh báo hỏi yes/no biến mất hoàn toàn, vừa tối ưu trải nghiệm làm việc vừa ngăn chặn triệt để nguy cơ giả mạo máy chủ.

So sánh: Khóa tĩnh authorized_keys vs Hệ thống SSH CA

Dưới đây là bảng tổng hợp các khác biệt cốt lõi giữa hai mô hình:

Quy trình chuyển đổi an toàn và Kế hoạch dự phòng (Rollback)

Việc thay đổi cấu hình xác thực SSH trên hạ tầng đang vận hành luôn đi kèm rủi ro gián đoạn truy cập. Để quá trình chuyển dịch diễn ra êm xuôi, bạn nên tuân thủ các bước sau:

1. Đồng bộ thời gian hệ thống bằng NTP

Do chứng chỉ OpenSSH có kiểm tra chặt chẽ mốc thời gian bắt đầu và kết thúc, nếu đồng hồ của máy chủ bị lệch so với máy trạm quá vài phút, chứng chỉ có thể bị coi là chưa hợp lệ hoặc đã hết hạn.

Đảm bảo dịch vụ đồng bộ thời gian luôn hoạt động ổn định trên mọi máy chủ:

sudo timedatectl set-ntp true
timedatectl status

Đảm bảo dòng System clock synchronized: yes và NTP service: active được hiển thị.

2. Thiết lập khóa cứu nạn dự phòng (Break-glass Key)

Trong suốt quá trình cấu hình thử nghiệm SSH CA, bạn không nên xóa ngay tệp ~/.ssh/authorized_keys cũ. Hãy giữ lại ít nhất một cặp khóa quản trị đặc biệt không phụ thuộc vào CA, lưu trữ khóa riêng tư trong một phần mềm quản lý mật khẩu an toàn của tổ chức (như Vaultwarden).

Nếu có sự cố phát sinh với cấu hình CA hoặc dịch vụ step-ca, quản trị viên vẫn có thể sử dụng khóa dự phòng này để đăng nhập và xử lý sự cố.

3. Nguyên tắc giữ phiên kết nối song song

Mỗi khi chỉnh sửa tệp /etc/ssh/sshd_config:

1. Luôn mở sẵn một cửa sổ terminal đang SSH vào máy chủ và giữ nguyên phiên làm việc đó.
2. Mở một cửa sổ terminal thứ hai để chỉnh sửa cấu hình và chạy lệnh kiểm tra cú pháp sudo sshd -t.
3. Chỉ chạy sudo systemctl reload sshd khi không có lỗi cú pháp.
4. Mở cửa sổ terminal thứ ba để thử nghiệm đăng nhập bằng chứng chỉ SSH mới.
5. Nếu phiên thứ ba kết nối thành công và xác nhận chứng chỉ hợp lệ qua nhật ký hệ thống, bạn mới đóng hai cửa sổ ban đầu. Nếu phát sinh lỗi, bạn vẫn còn phiên làm việc thứ nhất để sửa lại tệp cấu hình về trạng thái ban đầu mà không bao giờ bị khóa ngoài.

Việc làm chủ cơ chế SSH Certificate Authority giúp doanh nghiệp loại bỏ hoàn toàn gánh nặng quản lý khóa tĩnh phân tán, chuẩn hóa quy trình phân quyền theo nguyên tắc đặc quyền tối thiểu, và tạo nền tảng vững chắc để kết nối hạ tầng máy chủ vào mạng nội bộ Zero Trust.