Apple: SSH और FileVault

 (keith.github.io)
1 पॉइंट द्वारा GN⁺ 2025-09-19 | 1 टिप्पणियां | WhatsApp पर शेयर करें
  • FileVault सक्रिय होने पर macOS बूट के दौरान डेटा वॉल्यूम लॉक स्थिति में रहता है
  • OpenSSH configuration files डेटा वॉल्यूम में संग्रहीत होती हैं, इसलिए लॉक रहने के दौरान मौजूदा authentication methods या shell access उपलब्ध नहीं होते
  • अगर Remote Login (SSH) सक्रिय है, तो password authentication के ज़रिए remote network से डेटा वॉल्यूम अनलॉक किया जा सकता है
  • यह तरीका SSH session को तुरंत अनुमति नहीं देता, बल्कि अनलॉक होने के बाद SSH connection अस्थायी रूप से टूट जाता है
  • डेटा वॉल्यूम mount होने और ज़रूरी services शुरू होने के बाद SSH access उपलब्ध हो जाता है

Apple के SSH और FileVault इंटीग्रेशन का अवलोकन

  • FileVault सक्रिय macOS में डेटा वॉल्यूम लॉक रहता है, इसलिए बूट के बाद भी उस वॉल्यूम तक पहुंच संभव नहीं होती
  • OpenSSH की सभी system और account-स्तरीय configuration files डेटा वॉल्यूम के भीतर संग्रहीत होती हैं, इसलिए डेटा वॉल्यूम लॉक रहने पर सामान्य रूप से configured authentication methods या shell access निष्क्रिय हो जाते हैं

Remote Login (SSH) से remote unlock

  • बूट के बाद डेटा वॉल्यूम लॉक रहने पर भी, अगर Remote Login (SSH login) सक्रिय है, तो network के माध्यम से password authentication प्रयास की अनुमति मिलती है
  • उपयोगकर्ता SSH का इस्तेमाल करके remote रूप से password authentication के ज़रिए FileVault से लॉक वॉल्यूम को अनलॉक कर सकते हैं

अनलॉक प्रक्रिया की सीमाएँ और प्रोसेस

  • इस सुविधा से डेटा वॉल्यूम का लॉक हट जाता है, लेकिन SSH session तुरंत connect नहीं होता
  • डेटा वॉल्यूम अनलॉक होते ही, macOS वॉल्यूम mount करने और उस पर निर्भर supporting services शुरू करने की प्रक्रिया पूरी होने तक SSH connection थोड़ी देर के लिए टूट जाता है
  • यह प्रक्रिया पूरी होने के बाद SSH और अन्य सक्रिय सेवाओं का सामान्य उपयोग संभव हो जाता है

macOS 26 Tahoe संस्करण में शुरुआत

  • SSH के माध्यम से डेटा वॉल्यूम को remote रूप से अनलॉक करने की सुविधा पहली बार macOS 26 Tahoe में पेश की गई

संबंधित पढ़ाई

1 टिप्पणियां

 
GN⁺ 2025-09-19
Hacker News की राय

  • FileVault को सक्षम करने पर data volume लॉक हो जाता है, और account password से authentication होने तक boot के दौरान या boot के बाद उस तक पहुंच संभव नहीं होती; macOS के लिए OpenSSH system और per-account config files दोनों को data volume पर स्टोर करता है। इसलिए जब FileVault लगा हो, तब सामान्यतः सेट की गई authentication method या shell access उपलब्ध नहीं होती। लेकिन यदि Remote Login सक्षम हो, तो SSH के जरिए password authentication इस स्थिति में भी संभव हो जाती है। इससे network पर remotely data volume unlock किया जा सकता है। हालांकि SSH session तुरंत जारी नहीं रहता; SSH के जरिए volume unlock करने के बाद macOS volume mount और services restart पूरा करने तक थोड़ी देर connection टूट जाता है, और उसके बाद SSH (और अन्य services) सामान्य रूप से उपलब्ध हो जाते हैं। यह वास्तव में बहुत स्वागतयोग्य बदलाव है

  • क्या अब इसका मतलब है कि power outage के बाद auto reboot होने पर physical keyboard जोड़े बिना पूरी तरह remote Mac mini server चलाया जा सकता है? यह सचमुच शानदार बदलाव है

    • सीधे test करके पुष्टि हुई कि यह पूरी तरह काम करता है
      1. General > Sharing > Remote Management सक्षम करें
      2. reboot के बाद SSH से connect करने पर यह संदेश दिखता है: "यह system locked है। unlock करने के लिए account name और password का उपयोग करें। unlock होने पर सामान्य connection संभव होगा"
      3. SSH से सफल authentication होने पर SSH connection टूट जाता है, और "system unlock हो गया। अब SSH से सामान्य authentication संभव है" संदेश दिखता है
      4. दोबारा SSH से connect करने पर सामान्य रूप से login किया जा सकता है
    • नीचे दिया गया command भी उपयोग किया जा सकता है 
      sudo fdesetup authrestart -delayminutes -1
      यह तरीका अगली reboot के लिए केवल एक बार चुने गए account से auto login की अनुमति देता है। password input की जरूरत नहीं पड़ती, इसलिए सुविधाजनक है, लेकिन security risk है। परिस्थिति के अनुसार इसे स्वीकार किया जा सकता है
    • सच में जिज्ञासा है कि server OS के रूप में macOS क्यों चुना जाता है। मुझे भी Mac mini hardware बहुत आकर्षक लगता है, इसलिए इस पर विचार किया है। लेकिन macOS की जगह Linux चलाने में हिचकिचाहट होती है
    • पहले CI machine पर एक सहकर्मी ने गलती से FileVault सक्षम कर दिया था, और मुझे खुद server को rack से निकालना पड़ा, धूल साफ करनी पड़ी, monitor/keyboard लगाकर login और unlock करना पड़ा। अब SSH से unlock संभव होने के कारण, अगर फिर ऐसा हो तो remote से ही तुरंत हल किया जा सकता है
    • अच्छी तरह पता है कि FileVault सक्षम remote Mac को power outage के बाद online लाने के लिए physical login की अनिवार्यता कितनी असुविधाजनक थी। reboot के बाद क्या GUI तक भी पूरी remote access संभव है, यह जानना चाहता हूँ। home lab के लिए Mac mini लेने पर विचार कर रहा हूँ, और सोच रहा हूँ कि जरूरत पड़े तो KVM जैसी remote device लेनी होगी या नहीं

  • यह बदलाव कंपनी आदि non-personal Mac environments के लिए बहुत बड़ा परिवर्तन है। Mac Mini का price-performance और quality automation workloads के लिए काफ़ी उपयोगी है, और हमारी कंपनी में भी अगर यह issue न होता तो adoption धीरे-धीरे बढ़ रहा होता। FileVault issue ही एक बड़ा अवरोध था

    • Mac को general-purpose server की तरह इस्तेमाल करने में रुचि रही है। इसे server की तरह आसानी से manage करने के लिए क्या अतिरिक्त settings या तरीके हैं, यह जानना चाहता हूँ, और यह भी पूछता हूँ कि क्या लोग Mac-specific workloads चलाते हैं, या container-based Linux workloads भी operate करते हैं

  • macOS 26 Tahoe में SSH के जरिए data volume unlock feature जोड़ा गया है, यह देखकर खुशी हुई। हाल में Tahoe upgrade के बाद SSH connection उम्मीद से अलग तरह से काम कर रहा था; अब समझ आया कि यह उसी बदलाव की वजह से था। आमतौर पर मैं Mac बंद नहीं करता, लेकिन कभी-कभी remote से connect करना होता है और भूल जाता हूँ कि पिछली रात कोई बड़ा update install किया गया था, तब घबराहट होती थी। इस बदलाव से चिंता कम हुई है

  • क्या अब इसका मतलब है कि system volume पर FileVault encryption लागू नहीं होती? ऐसा अनुमान है। system volume read-only है, उसकी contents स्थिर हैं, और सभी macOS systems में समान होती हैं। networking तक boot हो जाना और फिर data volume decryption मांगा जाना तर्कसंगत लगता है। यदि FileVault वास्तव में system volume encryption को छोड़ रहा है, तो यह बहुत तार्किक बदलाव है। यह भी कहा गया कि overlay तकनीक के जरिए system partition पर लिखने जैसा दिखता है, लेकिन वास्तव में अक्सर data volume पर लिखा जाता है

    • WiFi password जैसी जानकारी भी data volume पर स्टोर होती है, इसलिए networking हमेशा उपलब्ध हो ऐसा जरूरी नहीं है

  • यह दिलचस्प बदलाव है, लेकिन जिज्ञासा है कि क्या graphical session में दिखने वाले "race condition" issues SSH पर भी लागू होंगे, जैसे जब shell data volume पर स्टोर हो। उदाहरण के लिए, restart करते समय app restore चुना जाए और सारे volumes mount होने से पहले app शुरू हो जाए, तो shell launch fail हो सकता है। ऐसा वास्तव में हुआ है। Nix से shell install करने पर यह अक्सर होता है। SSH में भी वही समस्या आने की संभावना लगती है। क्या system स्तर पर यह issue हल कर दिया गया है?

    • SSH से unlock की प्रक्रिया में connection को data volume unlock होते ही बंद कर दिया जाता है। volume mount पूरा होने के बाद दोबारा connect करने पर shell चलता है, इसलिए यह समस्या नहीं होती। Nix store इस्तेमाल करते समय मैंने wait4path का उपयोग करने वाले shim से इसका समाधान किया है। shim को पहले से data volume के किसी ज्ञात path पर install करके login shell के रूप में सेट किया जा सकता है
    • Apple इस समस्या को device unlock के बाद सभी processes terminate करके ("userspace reboot") मूल रूप से रोकता है
    • लगता है कि reconnect से अधिकांश मामलों में समस्या हल हो जाएगी। खासकर SSH में network retry mechanism सामान्यतः होता है, इसलिए यह बड़ा मुद्दा नहीं है
    • यह case OS में लंबे समय से शामिल wait4path utility से हल किया जा सकता है

  • यह सचमुच बहुत स्वागतयोग्य बदलाव है। इसी feature के कारण मैं FileVault बंद रखता था

  • Omarchy (एक opinionated Arch setup) की Full Disk Encryption के साथ प्रयोग कर रहा हूँ और सोच रहा हूँ कि क्या इसे main VM के रूप में इस्तेमाल किया जा सकता है। जब physical access हो तो GPU-accelerated desktop और सभी long-running computation workloads तक पहुंच संभव है। लेकिन यदि कुछ हफ्तों तक remote रहूँ और machine reboot हो जाए, तो disk password physical रूप से डालना अनिवार्य होने के कारण इसे आज़माने में हिचकिचाहट रही है। यह ProxMox पर चल रहा है, लेकिन USB passthrough जैसी settings के कारण standard VNC viewer से access संभव नहीं है। सोच रहा हूँ कि क्या Omarchy भी macOS की तरह remote unlock का प्रयास करेगा

    • Linux में बहुत पहले से initramfs में dropbear जोड़कर remote unlock feature लागू किया जा सकता था

  • निश्चित ही कहीं न कहीं कोई exploit path मौजूद होगा, ऐसा लगता है

    • password-based SSH के सामान्य security risks के अलावा कोई अतिरिक्त जोखिम तुरंत ध्यान में नहीं आता। यदि चिंता हो तो Wireguard जैसे firewall के पीछे रखना काफी सुधार देगा। पहले Mac server पर FileVault बंद रखना पड़ता था, इसलिए तुलना में यह कहीं बेहतर बदलाव है
    • Blastdoor जैसी security issues के अनुभव के कारण ऐसे बदलावों को लेकर हमेशा सावधानी रहती है

  • home lab के लिए जिस Mac mini को इस feature के अभाव में छोड़ दिया था, अब लगता है कि सब कुछ बदल गया है