Apple: SSH と FileVault

 (keith.github.io)
1 ポイント 投稿者 GN⁺ 2025-09-19 | 1件のコメント | WhatsAppで共有
  • FileVault を有効にすると、macOS の起動中はデータボリュームがロックされた状態になる
  • OpenSSH の設定ファイルはデータボリュームに保存されるため、ロック中は既存の認証方式やシェルアクセスを利用できない
  • Remote Login（SSH）が有効になっていれば、パスワード認証によってリモートネットワーク経由でデータボリュームのロックを解除できる
  • この方法では SSH セッションが即座に許可されるのではなく、ロック解除後に SSH 接続が一時的に切断される 現象が発生する
  • データボリュームがマウントされ、必要なサービスが起動した後に SSH でアクセスできるようになる

Apple の SSH と FileVault の連携概要

  • FileVault が有効な macOS では、データボリュームがロックされるため、起動後もそのボリュームにアクセスできない状況が発生する
  • OpenSSH のすべてのシステム設定ファイルおよびアカウントごとの設定ファイルはデータボリューム内に保存されているため、データボリュームがロックされた状態では、通常構成されている認証方式やシェルアクセスは無効になる

Remote Login（SSH）によるリモートロック解除

  • 起動後にデータボリュームがロックされた状態でも、Remote Login（SSH ログイン）が有効であれば、ネットワーク経由のパスワード認証の試行が許可される
  • ユーザーは SSH を利用して、リモートから パスワード認証 によって FileVault でロックされたボリュームを解除できる

ロック解除の制限事項とプロセス

  • この機能でデータボリュームのロックは解除できるが、SSH セッションがすぐに接続されるわけではない
  • データボリュームが ロック解除 されるとすぐに、macOS はボリュームのマウントと、それに依存する補助サービスの起動を完了するまでの間、SSH 接続が一時的に切断される 現象が発生する
  • この手順が完了した後に、SSH およびそのほか有効化されたサービスを正常に利用できる

macOS 26 Tahoe バージョンでの導入

  • SSH を通じたデータボリュームのリモートロック解除機能 は、macOS 26 Tahoe で初めて導入された

関連記事

1件のコメント

 
GN⁺ 2025-09-19
Hacker Newsのコメント

  • FileVaultを有効にするとデータボリュームがロックされ、アカウントのパスワードで認証するまで、起動中も起動後もアクセスできなくなることを経験した。macOS用のOpenSSHはシステム設定ファイルもアカウントごとの設定ファイルもすべてデータボリュームに保存する。そのため、FileVaultがかかっている間は、普段設定している認証方式やシェルアクセスが使えない。ところがRemote Loginを有効にしておくと、この状況でもSSH経由のパスワード認証が可能になる。これでネットワーク越しにリモートでデータボリュームのロックを解除できる。ただしSSHセッションがそのまま継続するわけではなく、SSHでボリュームを解除した後は、macOSがボリュームのマウントとサービスの再起動を終えるまで一時的に接続が切れ、その後からSSH（およびその他のサービス）が通常どおり利用可能になる。本当にうれしい変化だ

  • つまり停電後の自動再起動のあと、物理的にキーボードを接続しなくても完全なリモートMac miniサーバーを運用できるということなのか気になる。本当にすばらしい変化だ

    • 実際にテストしたところ、完全に動作することを確認した
      1. General > Sharing > Remote Management を有効化
      2. 再起動後にSSH接続すると、「このシステムはロックされています。ロック解除のためにアカウント名とパスワードを使用してください。解除後は通常どおり接続できます」というメッセージを確認
      3. SSHで正常に認証するとSSH接続が切れ、「システムのロック解除が完了しました。これでSSHで通常どおり認証できます」というメッセージが表示される
      4. もう一度SSH接続すると正常に入れる
    • 次のコマンドも使える 
      sudo fdesetup authrestart -delayminutes -1
      この方法では次回の再起動1回だけ、選択したアカウントで自動ログインされる。パスワード入力が不要なので便利だが、セキュリティ上のリスクはある。状況によっては許容できる
    • 純粋に気になるのだが、なぜサーバーOSとしてmacOSを選ぶのか聞いてみたい。自分もMac miniのハードウェアは本当に魅力的だと思って検討したことがある。ただ、macOSではなくLinuxを動かすことにはためらいがある
    • 以前、CIマシンで同僚が誤ってFileVaultを有効にしてしまい、サーバーをラックから引き出して、ほこりを払い、モニターとキーボードをつないでログインして解除する羽目になったことがある。これでSSHからロック解除できるので、また同じことが起きてもリモートですぐ解決できる
    • FileVaultが有効なリモートMacを停電後にオンラインへ戻すには物理ログインが必須だった不便さはよく分かる。再起動後にGUIまで完全にリモート接続できるのか気になる。ホームラボ用にMac miniの導入を考えているが、必要ならKVMのようなリモート機器が要るのかというところまで考えている

  • この変化は、企業などの非個人向けMac環境では非常に大きいと述べたい。Mac Miniのコストパフォーマンスと品質は自動化用途にかなり使いやすく、実際、会社でもこの問題さえなければ段階的に導入を増やしていたはずだ。FileVaultの問題が足かせになっていた大きな要因だった

    • Macを汎用サーバーとして使うことに関心があった。サーバーとして使いやすく管理しやすくするために追加で行っている設定や方法があるのか、またMac専用のワークロードを載せているのか、それともコンテナベースのLinuxワークロードも運用しているのか知りたい

  • macOS 26 TahoeでSSH経由のデータボリュームアンロック機能が追加されたのはうれしい。最近Tahoeにアップグレードした後、SSH接続が予想外に通ったのはこの変更によるものだと分かった。普段はMacの電源を切らないが、たまにリモートから接続しようとしたとき、前日に大規模アップデートを入れたことを忘れていて慌てることがあった。今回の変更で心配が減った

  • つまり今ではシステムボリュームにはFileVault暗号化が適用されていないということなのかと推測している。システムボリュームは読み取り専用で内容が固定されており、すべてのmacOSで同じだからだと思う。ネットワークまで起動してからデータボリュームの復号を求めるという理屈にも納得できる。FileVaultがあえてシステムボリュームの暗号化を省くなら、とても合理的な変更だと思う。オーバーレイ技術によってシステムパーティションに書き込んでいるように見せつつ、実際にはデータボリュームに記録されることが多い点にも触れている

    • WiFiパスワードのような情報もデータボリュームに保存されるので、ネットワークが常に使えるとは限らない点を指摘している

  • 興味深い変化ではあるが、データボリュームにシェルが保存されている場合のような、グラフィカルセッションで起きる「競合状態」の問題がSSHにも当てはまるのか気になる。たとえば再起動時にアプリの復元を選ぶと、すべてのボリュームがマウントされる前にアプリが先に起動してしまい、シェル実行に失敗することが実際にあった。Nixでシェルをインストールしたときによく起きる。SSHでも同じ問題が起きる可能性が高そうに見える。システムレベルでこの問題が解決されたのか気になる

    • SSHでアンロックする過程では、接続はデータボリュームのアンロック直後に終了される。ボリュームのマウント完了後に再接続すればシェルが起動するので、この問題はない。Nix storeを使う場合は、wait4path を使うshimで解決したことがある。shimをあらかじめデータボリューム上の既知のパスに設置し、ログインシェルとして指定すればよい
    • Appleはデバイスのアンロック後にすべてのプロセスを終了する（"userspace reboot"）ことで、この問題を根本的に回避している
    • 再接続で大半は解決する問題だと思う。特にSSHには一般的にネットワーク再試行の仕組みがあるので、大きな問題ではない
    • このケースはOSに以前から含まれている wait4path ユーティリティで解決できるはずだと考えている

  • 本当にうれしい変化だと思う。この機能がないせいでFileVaultを無効にしていた立場だ

  • Omarchy（方向性の強いArch構成）のフルディスク暗号化を試しつつ、メインVMとして使えるか考えている。物理的に操作できるときは、GPUアクセラレーション付きデスクトップとすべての長時間実行ジョブにアクセスできる。しかし数週間リモートにいて、その間にマシンが再起動すると、ディスクパスワードを物理的に入力しなければならない問題があるため、試すこと自体をためらっていた。ProxMox上で動かしているが、USBパススルーなどの設定のせいで標準のVNCビューアではアクセスできない。OmarchyもmacOSのようにリモートアンロックを試みるのか気になる

    • Linuxではかなり前から、initramfsにdropbearを入れてリモートアンロック機能を実現できていた

  • きっとどこかに脆弱性の攻撃経路があるはずだと思う

    • パスワードベースSSHの一般的なセキュリティリスク以外には、特に追加のリスクは思い浮かばない。心配ならWireguardのようなファイアウォールの内側に置けば十分改善できると思う。以前はMacサーバーでFileVaultを無効にしなければならなかったので、それに比べればはるかに歓迎できる変化だと思う
    • Blastdoorのようなセキュリティ問題の経験から、この手の変更にはいつも慎重になってしまう

  • この機能がないせいでホームラボ用として見送っていたMac miniがあったが、今ではすべてが変わったと感じる