GitHub ने अचानक SSH key क्यों अस्वीकार की: गायब .pub फ़ाइल

• बिना बदले गए laptop पर GitHub का git pull अचानक fail हो गया, लेकिन private key से मेल खाने वाली .pub फ़ाइल generate करते ही authentication फिर से होने लगा
• .pub फ़ाइल मौजूद होने पर OpenSSH पहले public key पेश करता है, approval मिलने के बाद sign करता है; न होने पर signed authentication request तुरंत भेजता है
• दोनों flows RFC 4252 के अनुरूप हैं और सामान्य sshd भी इन्हें allow करता है, लेकिन उस समय GitHub SSH frontend सीधे signed request स्वीकार नहीं करता दिखा
• 12 controlled tests में जिन 6 बार .pub फ़ाइल नहीं थी वे सभी reject हुए, और जिन 6 बार फ़ाइल थी वे सभी सफल रहे
• server banner में बदलाव से server-side software change की संभावना का अनुमान लगाया जा सकता है, लेकिन सही कारण confirm नहीं हुआ; इसलिए corresponding public key file को साथ रखना सुरक्षित है

---

अचानक authentication failure और समाधान

• primary laptop पर git pull Permission denied (publickey) error के साथ रुक गया
  • वह key अब भी GitHub में registered थी
  • दूसरी key इस्तेमाल करने वाले laptop पर वही repository सामान्य रूप से fetch हो रही थी
• key और client settings में कोई समस्या नहीं मिली
  • openssl rsa -check ने RSA key ok return किया
  • नया signature algorithm rsa-sha2-512 इस्तेमाल हो रहा था
  • ~/.ssh/config में कोई समस्या नहीं थी और GitHub status page भी normal था
• reinstall के बाद ~/.ssh/github_rsa से मेल खाने वाली public key file गायब थी; नीचे दिए command से generate करने पर authentication सफल हो गया

ssh-keygen -y -f ~/.ssh/github_rsa > ~/.ssh/github_rsa.pub

• controlled test में .pub फ़ाइल न होने वाली सभी 6 कोशिशें fail हुईं, और फ़ाइल होने वाली सभी 6 कोशिशें सफल रहीं

.pub फ़ाइल के आधार पर बदलने वाला authentication flow

• OpenSSH .pub फ़ाइल की मौजूदगी के आधार पर अलग-अलग public key authentication flow इस्तेमाल करता है
  • फ़ाइल होने पर public key पहले पेश करता है और server के approval का इंतज़ार करने के बाद sign करता है
  • केवल private key होने पर pre-check छोड़कर पूरी तरह signed authentication request सीधे भेजता है
• दोनों तरीके RFC 4252 में allow हैं, और सामान्य sshd दोनों accept करता है
• उस समय GitHub पर directly signed public key request reject हुई, लेकिन GitHub side पर वास्तविक change हुआ था या नहीं, यह confirm नहीं हुआ
  • debug log में server banner पुराने babeld-<hash> format के बजाय 6a2c000 दिखा
  • नए server software ने directly signed request reject की हो सकती है, लेकिन यह सिर्फ अनुमान है
• ऐसी ही समस्या से बचने के लिए private key से मेल खाने वाली .pub फ़ाइल साथ बनाए रखनी चाहिए

[GN⁺]

Lobste.rs की राय

• पिछले 4 घंटों से यही समस्या झेल रहा/रही हूं, और यह पहले ही https://www.githubstatus.com/incidents/g40zcbvchny4 पर दर्ज है

• कुछ हफ्ते पहले SSH key बदलते समय Git द्वारा ignore की जा रही पुरानी .pub file नहीं हटाई थी, लेकिन नई key से कनेक्ट करने पर भी लगातार fail हो रहा था
  कई debug options चालू करने के बाद ही पता चला कि SSH client पुराना fingerprint भेज रहा था; मुझे यह पता ही नहीं था कि OpenSSH .pub file पढ़ता है, और अब तक मैं इसे पूरी तरह गैर-जरूरी file समझता/समझती था/थी

• आज CI server पर भी अचानक github.com से कनेक्ट न हो पाने जैसी वही outage दिखी
  key को सही ed25519 key से बदलने पर फिर से काम करने लगा, लेकिन इस key के साथ भी matching .pub file नहीं है, इसलिए समझ नहीं आया कि यह कैसे ठीक हुआ

  • key के अचानक काम न करने पर पहले compromise की चिंता हुई थी, लेकिन अब लगता है कि GitHub खुद इस पर कार्रवाई कर रहा है, यह राहत की बात है

• आज वही समस्या आई, और जहां तक मुझे पता है GitHub ने SSH authentication behavior में बदलाव की कोई घोषणा नहीं की थी

  • यह planned change रहा होगा, ऐसा नहीं लगता

• password और recovery key दोनों खो देने के बाद SSH key-based account recovery प्रक्रिया से गुजरा/गुजरी, लेकिन GitHub ने वही SSH key expire कर दी, जिससे account access पूरी तरह चला गया

• लगता है 7–8 साल से मैंने .pub file रखी ही नहीं है, उम्मीद है अगली बार GitHub इस्तेमाल करने से पहले समस्या ठीक हो जाएगी

  • public key file आसानी से फिर से बनाई जा सकती है, और उसका command भी मूल लेख में दिया है

• अगर दोनों authentication flows वैध हैं, तो key discovery flow मौजूद क्यों है, यह समझ नहीं आता
  इससे बस ऐसा अजीब behavior पैदा होता लगता है, और जब private key से public key बनाई जा सकती है, तो SSH को यह अपने-आप कर लेना चाहिए

  • यह उन स्थितियों के लिए feature है जहां private key encrypted हो या hardware security token में stored हो और तुरंत इस्तेमाल के लिए उपलब्ध न हो
    SSH पहले check करता है कि server पर कौन-सी key चलेगी, ताकि user को ऐसी key बेवजह decrypt न करनी पड़े जिससे authentication निश्चित रूप से fail होगा
    इस behavior के https://github.com/FiloSottile/whoami.filippo.io जैसे असामान्य side effects भी हैं, इसलिए अगर user गलती से गलत server से connect कर जाए, तो यह तरीका allow करना जरूरी है जिसमें server को client की public key पहले से पता हो तभी authentication try किया जा सके

• मेरा work Office 365 account भी 5 साल में पहली बार आज अचानक काम करना बंद कर गया
  सोच रहा/रही हूं कि क्या Microsoft में compromise हुआ और सभी values को फिर से salt किया गया, या हालिया Chat Control 1.0 vote की वजह से यह सिर्फ European users के साथ हुआ है

  • GitHub की connection termination service और M365 account authentication का आपस में कोई संबंध नहीं है, और मुझे 99.999% यकीन है कि यह महज संयोग है
    जिन दो लोगों को मैं जानता/जानती हूं जिन्होंने GitHub के Git Systems और Microsoft के Office/M365 product suite दोनों पर काम किया है, उनमें से एक होने के नाते मैं यह बात कहने के लिए पर्याप्त रूप से योग्य हूं
    भले ही वजह कोई policy या technical change हो जो दोनों services पर समान रूप से लागू होता हो, systems एक-दूसरे से अलग हैं, इसलिए उसी दिन deploy होने की संभावना बेहद कम है