SSH sertifikaları: daha iyi bir SSH deneyimi

 (jpmens.net)
6 puan yazan GN⁺ 27 일 전 | 1 yorum | WhatsApp'ta paylaş
  • SSH sertifikaları, geleneksel açık anahtar tabanlı SSH kimlik doğrulamasının zahmetini ortadan kaldırır ve istemci ile sunucu arasında otomatik güven sağlar
  • OpenSSH 5.4’ten beri desteklenir; CA (sertifika otoritesi) kullanıcı ve host anahtarlarını imzalayarak authorized_keys dosyasını değiştirmeden kimlik doğrulamayı mümkün kılar
  • Sertifikalar; geçerlilik süresi, izin verilen kullanıcı (principal), erişim IP’si, zorunlu komut (force-command) gibi bilgileri içererek ayrıntılı erişim kontrolü sağlar
  • TOFU (Trust on First Use) süreci ortadan kalkar ve host anahtarı değiştiğinde uyarı olmadan güvenli bağlantı kurulabilir
  • Otomatik imzalama sunucuları veya araçları kullanıldığında büyük ölçekli sunucu ortamlarında SSH yönetimi otomasyonu ve güvenlik iyileştirmesi sağlanabilir

SSH sertifikalarına genel bakış ve mevcut SSH anahtar tabanlı kimlik doğrulamanın sınırları

  • SSH bağlantısında ilk kez bağlanılan sunucunun host anahtarı parmak izinin (fingerprint) doğrulanması gerekir; ancak çoğu kullanıcı bunu kontrol etmeden “yes” yazarak TOFU (Trust on First Use) yöntemini kullanır
    • Yöneticiler sunucunun parmak izini doğrudan kontrol edebilir veya ssh-keygen -l -f /etc/ssh/ssh_host_ed25519_key komutuyla doğrulayabilir
  • Açık anahtar tabanlı kimlik doğrulama, parola olmadan erişim sağlar; ancak her sunucunun authorized_keys dosyasına açık anahtarların dağıtılması gerekir
  • SSH agent (ssh-agent) kullanıldığında özel anahtar bellekte tutulur ve tekrar tekrar giriş yapmadan kimlik doğrulama yapılabilir
  • Mevcut yöntemin sınırlamaları
    • Her kullanıcı için açık anahtarın sunucuya kopyalanması gerekir
    • Host anahtarı değiştiğinde istemcide uyarı mesajı oluşur
    • TOFU nedeniyle güven yönetimi zahmetlidir

SSH sertifikaları ve sertifika otoritesi (CA)

  • SSH sertifikaları (Certificate) OpenSSH 5.4’ten (Mart 2010) beri desteklenir ve mevcut SSH anahtar biçimini genişleten bir yapıdır
  • SSH CA, bir SSH anahtar çiftinden oluşur ve açık anahtar güven kökü görevi görür
  • Başlıca avantajlar
    • Sunucudaki authorized_keys dosyasını değiştirmeye gerek yoktur
    • Host anahtarı değiştirildiğinde uyarı çıkmaz
    • TOFU sürecinin kaldırılmasıyla otomatik güven sağlanır
    • Sertifikaya izin verilen kullanıcı (principal), izin verilen IP, geçerlilik süresi, zorunlu komut (force-command) gibi bilgiler eklenebilir
    • Sertifika süresi dolduğunda erişim otomatik olarak engellenir

SSH CA kurulumu ve imzalama süreci

  • CA sisteminde ECDSA algoritmasıyla CA anahtar çifti oluşturma
    • ssh-keygen -t ecdsa -C "SSH CA" -f CA/ssh-ca
  • Kullanıcı kendi açık anahtarını (*.pub) CA’ye iletir; CA bunu imzalar (sign) ve bir sertifika (*-cert.pub) üretir
    • Örnek: ssh-keygen -s CA/ssh-ca -I "Jane Jolie" -n jane -z 001 -V +1w jane.pub
  • Sunucu yapılandırması
    • CA açık anahtarını /etc/ssh/ssh-ca.pub içine kaydedin ve TrustedUserCAKeys ayarını ekleyin
    • Sunucunun host anahtarını CA ile imzalayın (ssh-keygen -h -s CA/ssh-ca ...) ve HostCertificate alanına kaydedin
  • İstemci yapılandırması
    • known_hosts dosyasına bir @cert-authority satırı ekleyin
    • Örnek: @cert-authority *.example.com $(cat CA/ssh-ca.pub)

SSH sertifikası tabanlı bağlantı ve doğrulama

  • Kullanıcı, imzalanmış sertifika ile özel anahtarı birlikte kullanarak bağlanır (ssh -i jane -l jane alice.example.com)
  • Sunucu günlüklerinde sertifikanın ID’si, seri numarası (serial), CA parmak izi kaydedilir
  • Birden fazla host adı veya IP, sertifikadaki principal olarak eklenebilir
  • Sertifikada tanımlı principal dışında bir kullanıcıyla oturum açılmaya çalışıldığında “Certificate invalid: name is not a listed principal” hatası oluşur
  • Sertifikaya zorunlu komut (force-command) veya izin verilen IP (source-address) ayarı eklenerek ayrıntılı erişim kontrolü yapılabilir

Kontrol ve sorun giderme kontrol listesi

  • Sunucu tarafında kontrol edilecekler

    • TrustedUserCAKeys ayarının ve CA açık anahtarının mevcut olması
    • Host anahtarının imzalanmış olması ve HostCertificate değerinin tanımlanması
    • sshd yeniden başlatılmalıdır

  • İstemci tarafında kontrol edilecekler

    • Kullanıcı anahtarı CA tarafından imzalanmış olmalıdır
    • known_hosts içindeki @cert-authority kaydı ile principal eşleşmelidir
    • Sertifika süresi dolduğunda “Certificate invalid: expired” mesajı gösterilir
    • Sertifika kısıtları uyuşmazsa parola istenir
    • SSH agent’a sertifika eklendiğinde hem anahtar hem sertifika kaydedilir (ssh-add jane)
    • İmzalama sırasında seçeneklerle (-O) işlevler kontrol edilebilir
    • Örnek: -O clear ile tüm izinleri kaldırıp yalnızca permit-agent-forwarding, permit-port-forwarding izinlerini vermek mümkündür

Host anahtarı sertifikası otomasyonu

  • Python modülü sshkey-tools ve BottlePy kullanılarak otomatik imzalama sunucusu (hkbot) kurulabilir
    • CA sunucusunda hkbot.py çalıştırıldıktan sonra host açık anahtarı HTTP isteğiyle yüklendiğinde otomatik olarak imzalanır
    • İstemcide curl -F hostkey=@/etc/ssh/ssh_host_ed25519_key.pub http://CA:8870 | sh komutuyla otomatik kurulum yapılabilir
    • /etc/ssh/sshd_config dosyası düzenlenip doğrulandıktan sonra systemctl restart sshd ile uygulanır
  • Sonrasında SSH bağlantılarında sertifika tabanlı otomatik güven ve oturum açma kullanılabilir

SSH sertifikalarının avantajlarının özeti

  • TOFU gerekmez, istemci ve sunucu arasında otomatik güven sağlanır
  • Kısa ömürlü sertifikalar verilerek geçici erişim kontrolü yapılabilir
  • Sertifika süresi dolduğunda erişim otomatik engellenir, authorized_keys temizliği gerekmez
  • Zorunlu komut, PTY kısıtlaması, erişim IP kontrolü gibi ayrıntılı politika ayarları yapılabilir
  • Otomasyon araçlarıyla büyük ölçekli sunucu ortamı yönetimi sadeleştirilebilir
  • İlgili bir proje olarak Smallstep SSH tanıtılıyor

Ek başvuru kaynakları

Güncelleme

  • SSH CA, özellikle kendi sunucularını işleten ve root yetkisine sahip olunan ortamlarda yararlıdır
  • Çok kullanıcılı sistemlerde mevcut known_hosts ve authorized_keys yöntemi hâlâ gereklidir
  • SSH sertifika biçimi için standardizasyon taslağı: draft-miller-ssh-cert-06

İlgili okumalar

1 yorum

 
GN⁺ 27 일 전
Hacker News yorumları

  • İnsanların hâlâ SSH parolaları kullanmasına şaşırıyorum
    Özellikle büyük şirket ortamlarında, birden fazla parola politikası iç içe geçtiği için sadece bir sunucuya bağlanmak bile uzun sürebiliyor
    Bu yüzden onlara ssh-keygen ile anahtar kullanmalarını söyleseniz de çoğu “bir ara denerim” deyip sonunda hiç yapmıyor

    • Anahtarlar, kişisel ya da kurumsal ölçekte merkezi bir yönetim sistemi olduğunda faydalıdır
      Ama pratikte tek bir ortak anahtarın birden çok sunucuda kullanılması ya da anahtarların paylaşılması gibi nedenlerle yönetim kolayca dağılabiliyor
      Parolaların en azından basit olma avantajı var
    • Ben birkaç yıldır SSH anahtarlarımı Yubikey tabanlı HSM ile yönetiyorum
      Parola yok ama giriş yaparken fiziksel olarak Yubikey’e dokunmanız gerekiyor
    • ssh-copy-id gibi dağıtık anahtar kullanımı, saldırganların ağ içinde yatay hareket etmesini kolaylaştırdığı için birçok kuruluş bunu engelliyor

  • Birkaç ayda bir birileri yeniden SSH sertifikalarını keşfedip blog yazısı yazıyor
    Ben de 15 yıl önce ilgili bir yazı yazmıştım ama bugün bakınca eksik kalmış

    • Birçok kişi anahtarlar ile sertifikaları karıştırıyor
      Güvenlik mühendisleri bile bazen SSH sertifikası değil, anahtar kimlik doğrulaması kullandıklarını unutuyor
    • SSH sertifikaları, belirli bir kullanıcıya sınırlı süre ve yetkilerle erişim vermeye yaradığı için faydalı
    • Ben de SSH sertifikalarını biliyordum ama anahtar tabanlı yapıdan geçemedim
      Birden çok sunucunun anahtarlarını elle yönetmek fazla zahmetli
      Yine de artık geçiş yapmaya değip değmeyeceğini düşünüyorum
    • 10 yıl önce iş yerimde bir SSH CA kurarken yukarıdaki blog yazısından yararlanmıştık

  • TOFU (Trust On First Use) yaklaşımı basit ama oldukça ileri götürülebilir
    Kendi sunucularımda host anahtarını doğrudan doğruladıktan sonra bu benim için yeterli oluyor
    Büyük kurumsal ortamlarda, iç sunucuların açık anahtar listesini SSL ile imzalanmış dahili bir web sitesinde yayımlayabilirsiniz
    Ama sunucu sayısı fazlaysa veya sık değişiyorsa sertifikalar çok daha iyidir ve TOFU’nun birçok açıdan sınırları vardır
    Keşke tarayıcılarda da sunucunun TLS anahtarı değiştiğinde haber veren bir özellik olsa

    • 1996’dan beri SSH kullanıyorum ama açık anahtarı elle doğrulayan birini gerçekten hiç görmedim
      Çoğu kişi sadece “yes” yazıp geçiyor

  • Şirkette Zscaler’ın SSL incelemesi yüzünden çok zaman ve para kaybettik
    “self-signed certificate in certificate chain” hatası çıktığında iş her zaman sıkıntılı oluyor

    • Bir arkadaşımın şirketindeki Windows 11’e kurulu Zscaler’ı inceledim, neredeyse kötü amaçlı yazılım seviyesindeydi
      Kendi kök sertifikasını yerleştiriyor ve tarayıcı ayarlarını kilitleyerek proxy kullanımını engelliyor
      Firefox ya da Chrome ayar dosyalarını değiştirseniz bile anında üstüne yazıyor
      Hatta GUI üzerinden kapatmak için bile IT parolası gerekiyor
      Cybereason antivirüsünden sadece biraz daha iyi
    • Bizim şirketteki Cisco Umbrella da aynı
      HTTP tabanlı protokollerin hepsini bozuyor
      Git, RubyGems, go mod, Nix ve daha birçok araç çalışmaz hale geliyor
      Satıcı “şeffaf” diyor ama gerçekte hiç de öyle değil
      Sorunu teşhis etmek saatler alıyor ve çoğu yönetici bunun ne kadar yıkıcı olduğunun farkında değil
    • Bu arada SSH sertifikaları X.509 sertifikalarından farklıdır

  • Yazıda CA sertifikalarının sadece avantajlarından bahsedilmiş ama dezavantajları da açıkça var
    TOFU kaynaklı bir güvenlik sorunu yaşadığım hiç olmadı

    • “Bir olay yaşanmadıysa güvenlidir” demek, emniyet kemeri takmaya gerek yok demekle aynı mantık
      SSH sertifikalarının dezavantajları varsa bunun somut olarak ne olduğunu merak ediyorum
    • TOFU kullanışlıdır ama zorunlu değildir
      Güvenliği artırmak istiyorsanız açık anahtarları USB gibi güvenli bir kanal üzerinden değiş tokuş edebilirsiniz
      Sertifika kullansanız bile sonunda aynı süreci izlemek gerekir; sadece yönetim yükü kullanıcıdan yöneticiye kayar
      Büyük ölçekli kuruluşlarda sertifikalar faydalı olabilir ama genel güvenlik seviyesi aynıdır
    • CA yapılandırmasını önceden ayarlayabiliyorsanız TOFU’dan kaçınabilirsiniz
      Bunu kurulum betiğine ya da dağıtım imajına eklemek yeterlidir
      TOFU sadece zaten kurulmuş bir kutuya erişirken anlamlıdır
    • “TOFU nedeniyle henüz güvenlik olayı yaşanmadı” demek, henüz yaşanmadı demektir

  • Bizim dev/stg ortamımızda her gün makinelerin yarısını yeniden kuruyoruz
    SSH host sertifikaları sayesinde known_hosts dosyasını silmek ya da anahtarları korumak gerekmiyor; bu da işi çok kolaylaştırıyor

  • Kişisel bir proje olarak Sshifu adlı bir araç geliştiriyorum
    SSH sertifikası tabanlı oturum açmayı ve SSO’yu kolaylaştıran bir araç
    Sunucuya sshifu-server kurup bunu CA olarak kullanıyorsunuz, her SSH sunucusu da bu CA’ya güvenecek şekilde yapılandırılıyor
    Kullanıcının tek yapması gereken npx sshifu komutuyla giriş yapmak
    Ayrıntılar için GitHub deposuna bakabilirsiniz

  • Gerçek üretim ortamlarında sertifika tabanlı erişim, karmaşık yönetim sorunlarına yol açıyor
    Sertifika süresinin dolması, kullanıcı kaldırma, sunucu arızasında giriş yapma gibi çeşitli meseleler ortaya çıkıyor
    Userify olarak 15 yıldır bu sorunlarla uğraşıyoruz; sağlam bir SSH kimlik doğrulama altyapısı kurmak hiç de kolay değil

    • Ama SaaS yaklaşımının en kötü seçenek olduğunu düşünüyorum

  • pico.sh’ye SSH sertifikası desteği ekledim ve RBAC tarzı erişim denetimi uygulayabildiğim için bu çok yararlı oldu
    Ayrıntılar için dokümantasyona bakın

  • Üretimde SSH sertifikaları aslında karmaşıklığı merkezileştirerek sorunu büyütüyor
    Tek bir CA’nın her zaman erişilebilir olması gerekiyor ve arıza durumunda tüm erişim kesiliyor
    TTL ayarlama, güven kökü yönetimi, zor hata ayıklama gibi pratik sorunlar da çok
    Sonunda insanlar yine önbellek ya da ajan kullanmaya dönüyor
    Biz bunun yerine her düğümün HTTPS üzerinden kullanıcı bilgilerini yerel authorized_keys içine eşitlemesini sağlıyoruz
    Böylece merkezi denetim korunurken arızalar yerel kalıyor
    Userify bu yöntemi kullanıyor; yalnızca kimlik doğrulamayı değil, yetki yönetimini de ele alıyor
    Sertifikalar tek başına kullanıcı oluşturma, sudo rolleri, home dizini temizliği gibi sorunları çözmüyor

    • TOFU’yu nasıl çözdükleri soruluyor