GitHub'ın bir anda SSH anahtarını reddetmesinin nedeni: Kaybolan `.pub` dosyası

 (thorsell.io)
1 puan yazan GN⁺ 4 시간 전 | 1 yorum | WhatsApp'ta paylaş
  • Hiçbir değişiklik yapılmamış dizüstü bilgisayarda GitHub için git pull bir anda başarısız oldu; ancak özel anahtara karşılık gelen .pub dosyası oluşturulunca kimlik doğrulama yeniden çalıştı
  • .pub dosyası varsa OpenSSH önce açık anahtarı sunup onay alıyor, ardından imzalıyor; yoksa imzalı kimlik doğrulama isteğini doğrudan gönderiyor
  • Her iki akış da RFC 4252 ile uyumlu ve normal sshd tarafından kabul ediliyor; ancak o sırada GitHub SSH frontend'inin doğrudan imzalı istekleri kabul etmediği görülüyordu
  • 12 kontrollü testte .pub dosyasının olmadığı 6 denemenin tamamı reddedildi, dosyanın bulunduğu 6 denemenin tamamı ise başarılı oldu
  • Sunucu banner'ındaki değişim, sunucu tarafı yazılımında bir değişiklik olasılığına işaret ediyor; ancak kesin neden doğrulanamadığı için eşleşen açık anahtar dosyasını da birlikte tutmak güvenli

Ani kimlik doğrulama hatası ve çözümü

  • Ana dizüstü bilgisayarda git pull, Permission denied (publickey) hatasıyla durdu
    • İlgili anahtar hâlâ GitHub'a kayıtlıydı
    • Başka bir anahtar kullanan dizüstü bilgisayarda aynı depo normal şekilde çekilebiliyordu
  • Anahtar ve istemci yapılandırmasında bir sorun bulunamadı
    • openssl rsa -check, RSA key ok döndürdü
    • En güncel imza algoritmalarından rsa-sha2-512 kullanılıyordu
    • ~/.ssh/config içinde bir sorun yoktu ve GitHub durum sayfası da normaldi
  • Yeniden kurulumdan sonra ~/.ssh/github_rsa için karşılık gelen açık anahtar dosyasının kaybolduğu görüldü; aşağıdaki komutla yeniden oluşturulunca kimlik doğrulama başarılı oldu
ssh-keygen -y -f ~/.ssh/github_rsa > ~/.ssh/github_rsa.pub
  • Kontrollü testlerde .pub dosyasının olmadığı 6 denemenin tamamı başarısız oldu, dosyanın bulunduğu 6 denemenin tamamı ise başarılı oldu

.pub dosyasına göre değişen kimlik doğrulama akışı

  • OpenSSH, .pub dosyasının varlığına göre iki farklı açık anahtar kimlik doğrulama akışı kullanıyor
    • Dosya varsa önce açık anahtarı sunuyor, sunucunun onayını bekliyor ve ardından imzalıyor
    • Yalnızca özel anahtar varsa ön kontrolü atlayıp tamamen imzalanmış kimlik doğrulama isteğini doğrudan gönderiyor
  • Her iki yöntem de RFC 4252 tarafından izin veriliyor ve tipik sshd ikisini de kabul ediyor
  • O sırada GitHub'da doğrudan imzalı açık anahtar istekleri reddediliyordu; ancak GitHub tarafında gerçekten bir değişiklik yapılıp yapılmadığı doğrulanamadı
    • Hata ayıklama günlüklerindeki sunucu banner'ı geçmişteki babeld-<hash> biçimi yerine 6a2c000 olarak görünüyordu
    • Yeni sunucu yazılımının doğrudan imzalı istekleri reddetmiş olabileceği yalnızca bir tahmin olarak kaldı
  • Aynı sorundan kaçınmak için özel anahtara karşılık gelen .pub dosyasını da birlikte tutmak gerekiyor

İlgili okumalar

1 yorum

 
GN⁺ 4 시간 전
Lobste.rs görüşleri

  • Son 4 saattir aynı sorunu yaşıyorum; durum zaten https://www.githubstatus.com/incidents/g40zcbvchny4 üzerinde kayıtlı

  • Birkaç hafta önce SSH anahtarını değiştirirken Git tarafından yok sayılan eski .pub dosyasını silmemiştim; yeni anahtarla bağlansam da başarısız olmaya devam etti
    Ancak bir sürü debug seçeneğini açtıktan sonra SSH istemcisinin eski parmak izini gönderdiğini fark ettim; OpenSSH'nin .pub dosyasını okuduğunu bilmiyordum ve onu hep tamamen gereksiz bir dosya sanıyordum

  • Bugün CI sunucum da aniden github.com'a bağlanamama şeklinde aynı kesintiyi yaşadı
    Anahtarı doğru ed25519 anahtarıyla değiştirince yeniden çalıştı, ama bu anahtarın da eşleşen bir .pub dosyası yok, bu yüzden neden düzeldiğini bilmiyorum

    • Anahtar birden çalışmayınca önce bir ihlal yaşandığından endişelendim, ama şimdi GitHub'ın doğrudan müdahale ediyor gibi görünmesi sevindirici

  • Bugün aynı sorunu yaşadım; bildiğim kadarıyla GitHub'ın SSH kimlik doğrulama davranışını değiştireceğine dair bir duyuru yoktu

    • Planlı bir değişiklik gibi görünmüyor

  • Hem parolayı hem de kurtarma anahtarını kaybettiğim için SSH anahtarı tabanlı hesap kurtarma sürecinden geçtim, ama GitHub o SSH anahtarını süresi dolmuş olarak işaretlediği için hesaba erişimimi tamamen kaybettim

  • 7-8 yıldır hiç .pub dosyası bulundurmadığımı sanıyorum; GitHub'ı bir dahaki kullanışımdan önce sorunun çözülmesini umuyorum

    • Genel anahtar dosyası kolayca yeniden oluşturulabilir; ilgili komut da orijinal yazıda var

  • İki kimlik doğrulama akışı da geçerliyse neden bir anahtar keşif akışı olduğunu merak ediyorum
    Sanki sadece böyle garip davranışlara yol açıyor; zaten özel anahtardan genel anahtar üretilebiliyorsa SSH bunu otomatik halledebilir gibi görünüyor

    • Bu, özel anahtarın şifreli olduğu veya donanım güvenlik token'ında saklandığı ve anında kullanılamadığı durumlar için olan bir özellik
      SSH önce sunucuda hangi anahtarın işe yarayacağını kontrol eder; böylece kullanıcı, kimlik doğrulamada kesin başarısız olacak bir anahtarı gereksiz yere çözmek zorunda kalmaz
      Bu davranışın https://github.com/FiloSottile/whoami.filippo.io gibi tuhaf yan etkileri de var; bu yüzden kullanıcı yanlışlıkla yanlış sunucuya bağlandığında, sunucunun istemcinin genel anahtarını önceden bilmesi halinde kimlik doğrulamayı denemeye izin veren bir yönteme de ihtiyaç var

  • İş için kullandığım Office 365 hesabı da 5 yıl sonra ilk kez bugün aniden çalışmayı bıraktı
    Microsoft'ta bir ihlal yaşanıp tüm değerler yeniden salt'landı mı, yoksa son Chat Control 1.0 oylaması nedeniyle bu sadece Avrupalı kullanıcıları mı etkiliyor diye merak ediyorum

    • GitHub'ın bağlantı sonlandırma hizmeti ile M365 hesap kimlik doğrulamasının hiçbir ilgisi yok; bunun tesadüf olduğuna %99.999 eminim
      GitHub'ın Git Systems tarafında da Microsoft'un Office/M365 ürün grubunda da çalışmış, bunu bilen iki kişiden biri olarak bunu söylemeye fazlasıyla hakkım var
      Neden iki hizmete de aynı şekilde uygulanan bir politika ya da teknik değişiklik olsa bile, bunlar birbirinden kopuk sistemler olduğu için aynı gün dağıtıma çıkmaları son derece düşük bir ihtimal