LogRaker, swift-nio-ssh'i eski EC2 anahtarları için RSA desteği eklemek üzere fork'ladı

Makineler SSH üzerinden erişen bir günlük görüntüleme ürünü olan LogRaker, Apple'ın swift-nio-ssh kütüphanesine RSA anahtar desteği eklemek için neden fork aldığını belgeledi — bu yetenek upstream'de bilinçli olarak bulunmuyor; upstream, modern primitive'leri tercih ediyor ve yeni dağıtımlar için daha iyi varsayılan ed25519.

LogRaker'a göre kısıt şu: istemciler anahtar biçimlerini nadiren seçebiliyor. Amazon EC2, 2021'de ed25519 desteği gelene kadar yalnızca PKCS#1 RSA .pem anahtar çiftleri veriyordu; dolayısıyla tüm eski anahtar çiftleri RSA ve bu anahtarların açtığı instance'lar çoğu zaman hâlâ çalışıyor. Halihazırda ~/.ssh içinde duran anahtarla kimlik doğrulayamayan bir araç bu makinelere basitçe erişemiyor.

Genişletme noktası yok

Modül dışından bir anahtar türü eklemek mümkün değil. LogRaker, NIOSSHPrivateKey'ın anahtar malzemesini internal bir enum'da tuttuğunu, memberwise initializer'ın private olduğunu ve public initializer'ların her birinin yalnızca tek bir algoritmayı kapsadığını açıklıyor. Uyulacak bir protocol ve genişletilecek bir case olmadığından RSA desteği modülün kendisini düzenlemek anlamına geliyor — fiilen bir fork.

Değişiklik upstream 0.15.0'a karşı sekiz dosyaya dokundu: RSA imzalamayı swift-crypto'nun CryptoExtras ürününden çekmek için Package.swift; Sources/NIOSSH/ altında beş dosya; ve tanınmayan bir algoritmanın yerine geçecek şekilde ssh-rsa kullandığı için değişmesi gereken bir upstream testi.

Anlaşmak zorunda olan iki string

En ince kısım, bir public key blob'u ve bir algoritma adı taşıyan publickey userauth isteğini içeriyor. Ed25519 ve ECDSA eğrileri için bu stringler özdeş olduğundan upstream, algoritma alanına anahtarın kendi etiketini düşünmeden yazıyor. RSA istisna: anahtar blob'u ssh-rsa etiketini korurken algoritma alanı imza algoritmasını — RFC 8332 kapsamında rsa-sha2-256 veya rsa-sha2-512 — belirtmek zorunda. Çıplak ssh-rsa etiketi SHA-1'li RSA anlamına geliyor ve OpenSSH 8.8 bunu 2021'de varsayılan olarak devre dışı bıraktı; dolayısıyla güncel sunucular, anahtar ne kadar sağlam olursa olsun bunu kesinlikle reddediyor.

LogRaker'ın fork'u keyPrefix'in yanına bir signatureAlgorithmName property'si ekliyor, ama asıl zorluk algoritma adının iki yerde yazılması: wire mesajını oluşturan SSHMessages.swift ve imzalanan buffer'ı oluşturan UserAuthSignablePayload.swift. Stringlerden biri istemcinin iddia ettiği şey, diğeri imzaladığı şey. İkisi ayrışırsa mesaj her baytında iyi biçimlendirilmiş olabilir ve geçerli bir RSA imzası taşıyabilir; sunucu yine de reddeder — ve ret, sunucu tarafından yanlış anahtarla aynı göründüğünden, hatada uyumsuzluğa işaret eden hiçbir şey yoktur. Yeni bir test iki yazım noktasını birlikte sabitliyor, böylece herhangi birine yapılacak gelecekteki değişiklik bir debugging seansı değil bir test hatası üretiyor.

Tembel değil, sabit bir seçim

Fork her zaman rsa-sha2-512 sunuyor ve asla müzakere etmiyor. Bu kolay değil zorunlu: swift-nio-ssh SSH_MSG_EXT_INFO'yu parse etmiyor, dolayısıyla sunucunun server-sig-algs listesi üzerine hareket edebilecek koda hiç ulaşmıyor. Varsayılan zaten güvenli, diye savunuyor LogRaker; rsa-sha2-512, 2016'daki OpenSSH 7.2'den beri kabul ediliyor — bir günlük görüntüleyicinin gerçekçi olarak bağlanacağı her şeyden daha eski. İlgili bir pürüz daha: fork'un tanınan algoritmalar listesi, o liste gelen userauth istekleriyle ve PK_OK yanıtlarıyla eşleştirildiği için, iki imza algoritması adının yanına anahtar etiketini de içermek zorunda.

Vendoring'ın bedeli

LogRaker fork'u dürüst tutan üç alışkanlık sıralıyor. Her düzenleme LOGRAKER FORK yorumuyla işaretli; upstream'a karşı tam diff tek bir grep oluyor ve işaretçiler bir rebase kontrol listesine dönüşüyor. Bir serialization testi, üretilen public key blob'unu aynı anahtar için ssh-keygen çıktısıyla bayt bayt karşılaştırıyor — mantık şu: elle yazılmış wire encoding'teki hatalar makul görünebilir ve yine de incelemeden sıyrılabilir; tek geçerli hakem OpenSSH. Ve güvenlik duyuruları kendiliğinden gelmeyecek: yerel olarak pin'lenmiş bir Swift paketi upstream güncellemelerini hiç bildirmiyor, dolayısıyla swift-nio-ssh duyurularını kontrol etmek birinin gerçekten yaptığı bir rutin haline gelmek zorunda.

Fork, Apache 2.0 ile lograker/swift-nio-ssh adresinde herkese açık, ama README'si sınırlar hakkında açık sözlü: tek bir uygulamaya hizmet etmek için var, 0.15.0'a pin'lenmiş ve denetimden geçmemiş. Aynı yolu düşünen herkes için LogRaker'ın kendi hükmü muhtemelen "yapma" — erişmek zorunda olduğunuz makineleri koruyan RSA anahtarları alternatif bırakmıyorsa o başka. Upstream kendi RSA desteğini gönderdiği gün fork silinebilir.

Neden önemli

Küçük bir fork yinelenen bir sorunu özetliyor: güvenlik kütüphaneleri eski algoritmaları, dünyanın onlara bağımlı kimlik bilgilerini emekliye almasından daha hızlı emekliye alıyor. Bulut sağlayıcıları yıllarca RSA anahtarı verdi ve o anahtarlar hâlâ üretim makinelerini açıyor; dolayısıyla yalnızca modern primitive'leri destekleyen araçlar gerçek iş yüklerini çıkmazda bırakıyor. Yazı aynı zamanda güvenlik açısından kritik bir bağımlılığı fork'lamanın bedelinin — sessiz duyurular, kalıcı rebase görevi, denetlenmemiş kod — dürüst bir hesabı ve RSA'ya yeni yaklaşan herhangi bir uygulayıcının takılacağı bir SSH detayının, anahtar blob etiketleri ile RFC 8332 imza algoritma adları ve arkasındaki SHA-1 kullanımdan kaldırmasının, faydalı bir özeti.