OpenSSH CA ile Kısa Ömürlü SSH Sertifikaları

Kurumsal yapılarda SSH erişimi genelde iki uç arasında sıkışır: ya aşırı kısıt (iş yapamazsın) ya da aşırı gevşek (kalıcı anahtarlar, paylaşılan bastion hesapları). OpenSSH’nin yerleşik sertifika desteği bu dengeyi düzeltmek için pratik bir araçtır: kullanıcı anahtarı “kimlik” olur, erişim ise CA tarafından süreli ve denetlenebilir şekilde imzalanır.

Neden CA modeli?

Benim en sık gördüğüm iki problem:

• Sunucularda authorized_keys dosyaları zamanla şişer ve kimse temizleyemez.
• Incident anında “kimin anahtarı nerede?” kaosu oluşur.

CA modeliyle yaklaşım değişir:

• Sunucu, hangi CA’ya güvendiğini bilir (tek dosya)
• Kullanıcı, kendi anahtarını taşır ama erişim için süreli sertifika alır
• Denetim: kimin, ne zaman, hangi “principal” ile bağlandığı izlenebilir

Mimari: 3 bileşen

• CA anahtarı: imzalama yetkisi (çok iyi korunmalı)
• SSH sunucular: CA’ya güvenir, principal kurallarını uygular
• İmzalama servisi/akışı: onay + süre + log + sertifika üretimi

1) CA anahtarını üret

İmzalama host’unda:

ssh-keygen -t ed25519 -f /etc/ssh/ca_user_ed25519 -C "ssh-user-ca"
install -m 0644 /etc/ssh/ca_user_ed25519.pub /etc/ssh/ca_user_ed25519.pub

Özel anahtar (/etc/ssh/ca_user_ed25519) yalnızca imzalama akışında kullanılmalı.

2) SSH sunucuda CA güvenini tanımla

Hedef sunucularda CA public key’i koy:

install -d -m 0755 /etc/ssh/trust
install -m 0644 ca_user_ed25519.pub /etc/ssh/trust/ca_user_ed25519.pub

/etc/ssh/sshd_config içine:

TrustedUserCAKeys /etc/ssh/trust/ca_user_ed25519.pub
AuthorizedPrincipalsFile /etc/ssh/auth_principals/%u
PubkeyAuthentication yes

Sonra:

sshd -t && systemctl reload sshd

3) Principal modeli: erişimi isimle yönet

Benim pratikte kullandığım model:

• Sunucudaki Linux kullanıcı adı: ops
• Sertifika principal’ları: prod-readonly, prod-admin, db-maint

Sunucuda ops kullanıcısı için:

install -d -m 0755 /etc/ssh/auth_principals
printf "prod-readonly\n" > /etc/ssh/auth_principals/ops
chmod 0644 /etc/ssh/auth_principals/ops

Bu dosya “ops kullanıcısına hangi principal ile girilebilir?” sorusunun cevabıdır.

4) Kullanıcı sertifikasını imzala (kısa ömürlü)

Kullanıcının public key’i üzerinden, 60 dakikalık sertifika:

ssh-keygen -s /etc/ssh/ca_user_ed25519 \
  -I "ticket-INC-14372" \
  -n "prod-readonly" \
  -V "+60m" \
  -z 1001 \
  user_ed25519.pub

Çıktı user_ed25519-cert.pub olur. Kullanıcı bağlanırken:

ssh -i user_ed25519 ops@server01

OpenSSH, -i anahtarının yanındaki -cert.pub dosyasını otomatik bulur.

5) Sertifika iptali (KRL) ve “break glass”

Sertifika süresi kısa olduğu için çoğu durumda iptal bile gerekmeyebilir. Ama “anahtar çalındı” senaryosu için KRL pratik bir emniyet kemeridir:

ssh-keygen -k -f /etc/ssh/revoked.krl user_ed25519.pub

Sonra sshd_config içine:

RevokedKeys /etc/ssh/revoked.krl

Break glass için ayrı bir principal (ör. prod-breakglass) ve ayrı onay kuralı tanımlayın.

Otomasyon: imzalama akışını nasıl bağlarım?

Sertifika imzalama, insanın elle koşacağı bir komut olmamalı. Operasyonel olarak sağlam olan model:

• IAM/SSO → kimlik doğrulama
• Ticket/incident → gerekçe
• Onay → süre (varsayılan kısa)
• İmzalama → log + audit trail
• Süre bitince → otomatik kapanış

Bu akış kurulduğunda, SSH erişimi “kalıcı hak” olmaktan çıkar; olay-temelli bir operasyon olur.