SSH Sertifika Otoritesi: authorized_keys Yerine Kısa Ömürlü Erişim, Principal'lar ve Sunucu Sertifikaları

Bir ekip büyüdükçe SSH erişimi sessizce çürür. Her sunucunun authorized_keys dosyasında kimin anahtarı olduğunu kimse bilmez, işten ayrılan birinin anahtarı üç sunucudan silinir ama dördüncüde kalır, yeni bir makineye ilk bağlanışta herkes parmak izine bakmadan "yes" yazar. Sorun anahtarların kendisi değil, anahtarlarla kişiler arasındaki eşlemenin hiçbir yerde merkezi olarak tutulmaması. OpenSSH bunun için yıllardır yerleşik bir çözüm sunuyor: sertifika otoritesi. Ek bir sunucu, ek bir yazılım gerektirmeden kısa ömürlü, kime ve hangi kullanıcıya verildiği belli erişim kimlikleri üretebilirsiniz.

Üç yaklaşım ve hangisi nerede işe yarar

Dağıtılmış authorized_keys. Anahtarları bir yapılandırma yönetimi aracıyla her sunucuya yazarsınız. Beş sunucu ve üç kişi için gayet iyidir. Ölçek büyüyünce iki zayıflığı belirginleşir: iptal ancak bütün sunuculara yeni dosya ulaştığında gerçekleşir, ve bir anahtarın süresi yoktur. Dizüstü bilgisayarından iki yıl önce kopyalanmış bir özel anahtar bugün hâlâ geçerlidir.

AuthorizedKeysCommand ile merkezi sorgu. sshd her girişte bir komut çalıştırıp anahtarları bir dizin servisinden alır. İptal anında etkili olur, ama giriş artık o servisin ayakta olmasına bağlıdır. Dizin servisi yavaşladığında ya da ağ koptuğunda sunuculara girilemez, ve bu genellikle tam da sunuculara girmeniz gereken andır.

Sertifika otoritesi. Bir CA anahtarı kullanıcının açık anahtarını imzalar; sunucu yalnızca CA'nın açık anahtarına güvenir. Sertifikanın içinde kimliği, hangi Unix kullanıcılarına girebileceği ve geçerlilik süresi yazar. Sunucu doğrulama için kimseye sormaz, yani giriş anında dış bağımlılık yoktur. İptal sorununu süre çözer: sertifika sekiz saat geçerliyse, iptal listesine çoğu zaman ihtiyaç bile kalmaz.

Taraf tutmak gerekirse: on sunucuyu ya da birden fazla ekibi geçtiyseniz sertifika yaklaşımı açık ara doğru seçimdir. Merkezi sorgunun getirdiği iptal hızını, bağımlılık riskini almadan kısa ömürle elde edersiniz.

Kullanıcı sertifikası: temel kurulum

CA anahtarını, sunuculardan ayrı ve iyi korunan bir yerde üretin:

ssh-keygen -t ed25519 -f user_ca -C "user-ca"

Bir kullanıcının açık anahtarını imzalamak:

ssh-keygen -s user_ca -I "ayse@ornek" -n ayse,deploy -V -5m:+8h -z 1001 id_ed25519.pub

Bu komut yanına id_ed25519-cert.pub dosyasını üretir. Bayrakların anlamı önemlidir:

• -I sertifika kimliğidir ve sunucu günlüğüne yazılır. Kişiyi ve cihazı tanıtan bir değer verin, giriş kayıtlarında bunu arayacaksınız.
• -n principal listesidir, yani bu sertifikanın hangi adlarla kabul edileceği.
• -V -5m:+8h geçerliliği beş dakika önce başlatıp sekiz saat sonra bitirir. Geriye kaydırılmış başlangıç saat farkı olan sunucular için emniyet payıdır.
• -z seri numarasıdır, iptal için gerekir.

Sertifikanın içeriğini her zaman doğrulayın:

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

Sunucu tarafında sshd_config:

TrustedUserCAKeys /etc/ssh/user_ca.pub
AuthorizedPrincipalsFile /etc/ssh/auth_principals/%u

/etc/ssh/auth_principals/deploy dosyasına deploy satırını yazarsanız, principal listesinde deploy bulunan her sertifika o kullanıcı olarak girebilir. AuthorizedPrincipalsFile kullanmazsanız varsayılan kural, principal adının Unix kullanıcı adıyla birebir eşleşmesidir. Principal'ları kişi adı yerine rol adı olarak tasarlamak (örneğin web-operator, db-readonly) sunucu dosyalarını değiştirmeden yetki vermenizi sağlar: yetki imza anında belirlenir.

İmza sırasında kısıtlama da eklenebilir. Bir CI işinin anahtarı için:

ssh-keygen -s user_ca -I "ci-deploy" -n deploy -V +30m \
  -O no-port-forwarding -O no-pty -O source-address=203.0.113.0/24 ci_key.pub

Sunucu sertifikası: "yes" yazma alışkanlığını bitirmek

Aynı mekanizma ters yönde de çalışır ve çoğu kurulumda unutulan yarı budur. Ayrı bir host CA ile sunucunun anahtarını imzalayın:

ssh-keygen -s host_ca -I "web01" -h -n web01.example.com,web01 -V +52w \
  /etc/ssh/ssh_host_ed25519_key.pub

-h bunun bir sunucu sertifikası olduğunu belirtir. sshd'ye sertifikayı gösterin:

HostCertificate /etc/ssh/ssh_host_ed25519_key-cert.pub

İstemcilerin known_hosts dosyasına tek satır yeter:

@cert-authority *.example.com ssh-ed25519 AAAA...host_ca_acik_anahtari

Artık yeni bir sunucu kurulduğunda kimse parmak izi onaylamaz; imza geçerliyse bağlantı kurulur, geçersizse istemci uyarır. Ortadaki adam saldırısına karşı korumanın kullanıcı disiplinine bağlı olduğu durum ortadan kalkar.

Tuzaklar

Tek CA ile hem kullanıcı hem sunucu imzalamak. Aynı anahtarı iki iş için kullanırsanız, sunucu imzalama yetkisi olan bir otomasyon dolaylı olarak kullanıcı sertifikası da üretebilir hâle gelir. İki ayrı CA tutun, erişimlerini de ayırın.

Principal vermeyi unutmak. -n olmadan imzalanan bir sertifikanın nasıl yorumlanacağı OpenSSH sürümüne ve sunucu ayarına göre değişir. Bu davranışa güvenmeyin; her sertifikada principal listesini açıkça verin ve imzalama aracınız boş listeyi reddetsin.

Eski authorized_keys dosyalarının açık kalması. Sertifikaya geçtiniz ama her sunucuda eski anahtarlar duruyorsa, sistem eskisi kadar güvensizdir; sadece daha karmaşıktır. Geçiş bittiğinde AuthorizedKeysFile none ile bu yolu kapatın. Bunu yapmadan önce sertifikayla giriş yapabilen ikinci bir oturumunuzun açık olduğundan emin olun.

Saat farkı. Sertifika geçerliliği sunucunun saatine göre kontrol edilir. Saati birkaç dakika ileride bir sunucu, yeni imzalanmış sertifikayı "henüz geçerli değil" diye reddeder. Başlangıcı geriye kaydırın ve sunucularda zaman senkronizasyonunu izleyin.

RSA CA ve SHA-1. Eski RSA CA anahtarıyla SHA-1 imzalı sertifikalar, yeni OpenSSH sürümlerinde varsayılan olarak kabul edilmez. Yeni kurulumda CA için ed25519 kullanın; RSA zorunluysa imza algoritmasını SHA-2 ailesinden seçin.

Uzun süreli sertifika vermek. "Ara sıra lazım oluyor" diye bir yıllık kullanıcı sertifikası üretirseniz, aslında süresi olmayan bir anahtara geri dönmüş olursunuz ve iptal sorununu yeniden yaşarsınız. Uzun süre gerekiyorsa iptal listesini kurun:

ssh-keygen -k -f /etc/ssh/revoked_keys -s user_ca.pub -z 1 iptal.txt

iptal.txt içinde serial: 1001 gibi satırlar bulunur; sshd tarafında RevokedKeys /etc/ssh/revoked_keys ile etkinleştirilir. Bu dosyanın bütün sunuculara ulaşması gerektiğini unutmayın: dağıtım sorunu geri gelir, bu yüzden kısa süre hâlâ birinci savunmadır.

İstemcinin sertifikayı bulamaması. Sertifika, anahtarla aynı ada -cert.pub eki alarak durduğunda otomatik kullanılır. Farklı bir ad ya da yer kullanıyorsanız ssh_config içinde CertificateFile belirtin. Ajan kullanıyorsanız sertifikayı yeniledikten sonra anahtarı ajana yeniden ekleyin, yoksa ajan eski sertifikayı sunmaya devam eder.

İmzalamayı kim yapacak

CA anahtarını bir kişinin dizüstüne koymak bütün kurguyu boşa çıkarır. Pratikte imzalama, kimlik doğrulamasını zaten yapan bir sistemin arkasına konur: kullanıcı tek oturum sağlayıcısıyla giriş yapar, imzalama servisi kimliğe ve gruplara bakarak principal listesini belirler, birkaç saatlik sertifika döner. HashiCorp Vault'un SSH motoru ve step-ca bu işi hazır yapar. Küçük bir ekipte, erişimi sınırlı bir makinede çalışan basit bir betik de başlangıç için yeterlidir; önemli olan CA anahtarının dağıtılmaması ve her imzanın kayda geçmesidir.

Ne zaman seçmemeli

Bir iki sunucunuz ve tek yöneticiniz varsa, sertifika altyapısı çözdüğünden fazla iş çıkarır; düzgün korunan anahtarlar ve iki faktörlü bir sıçrama sunucusu yeterlidir. Zaten oturum kaydı, onay akışı ve erişim isteği arayüzü sunan bir erişim aracı kullanıyorsanız, aynı işi elle kurmak yerine onun sertifika desteğini kullanın. İmzalamayı otomatikleştiremeyecekseniz de başlamayın: elle imzalanan sertifikalar kısa sürede uzun süreli verilmeye başlar ve yaklaşımın bütün avantajı kaybolur.

Doğru kurulduğunda sonuç şudur: sunucularda tutulan tek erişim bilgisi bir CA açık anahtarıdır, her giriş günlükte kişi adıyla görünür ve işten ayrılan birinin erişimi en geç sertifikasının süresi dolduğunda biter.