世界を動かす技術を、日本語で。

Apple: SSHとFileVault

概要

FileVault 有効時、データボリュームは認証されるまでロック状態。 macOSの OpenSSH構成ファイル もデータボリューム内に保存。 通常のSSH認証やシェルアクセスは起動直後は利用不可。 Remote Login 有効時、SSH経由でパスワード認証しリモート解除が可能。 解除後、SSH接続が一時切断されるが、その後サービスが利用可能。

apple_ssh_and_filevault — SSHとFileVaultの連携

  • FileVault有効時、起動後や再起動直後は データボリュームがロック されている状態
  • データボリュームの解除には アカウントのパスワード認証 が必要
  • OpenSSHの設定ファイル (システム全体・ユーザーごと)はデータボリューム内に格納
  • そのため、通常のSSH認証方法やシェルアクセスは データボリューム解除前は利用不可
  • Remote Login(リモートログイン) を有効化している場合、SSH経由で パスワード認証による解除 が可能
  • この手法により、 ネットワーク経由でリモートからデータボリュームのロック解除 が実現
  • ただし、解除直後は SSHセッションが一時的に切断
    • データボリュームのマウントや依存サービスの起動が完了するまで一時的に接続不可
  • その後、 SSHや他のサービスが完全に利用可能 となる

歴史

  • SSH経由でデータボリュームを解除する機能macOS 26 Tahoe で導入

関連情報

  • 詳細は sshd(8) を参照

Hackerたちの意見

FileVaultが有効になっていると、データボリュームはロックされていて、ブート中やその後も、アカウントがパスワードで認証されるまで利用できないんだ。macOS版のOpenSSHは、すべての設定ファイルをデータボリュームに保存しているから、通常の認証方法やシェルアクセスはこの間使えないんだよ。でも、リモートログインが有効になっていれば、SSHを使ってパスワード認証を行うことができるんだ。これを使えば、ネットワーク越しにデータボリュームをリモートで解除できる。ただし、すぐにSSHセッションが許可されるわけではなくて、この方法でデータボリュームが解除された後、macOSはデータボリュームのマウントとそれに依存する残りのサービスの起動を完了するまで、SSHを一時的に切断するんだ。その後はSSH(と他の有効なサービス)が完全に利用可能になる。これは本当に嬉しい変更だね!

つまり、電源が落ちたときに自動再起動する完全リモートのMac miniサーバーが、キーボードを接続して物理的にログインする必要なしに持てるってこと?すごいね!

こんなこともできるよ:sudo fdesetup authrestart -delayminutes -1。これを使うと、次回の再起動時に選択したアカウントに自動ログインできて、パスワードを入力する必要がなくなる。ただし、一度だけの効果しかない。明らかにセキュリティ上の欠点があるけど、それが問題ない場合もあるかもね。

これまでもできたけど、FileVaultとの組み合わせでは無理だったんだよね。

sshで自動ログインするにはどうすればいいの?

そうであってほしい!停電後にFileVaultが有効なリモートMacに物理的にログインしないとオンラインにできないのは理想的じゃないからね!再起動後にGUIにリモートでアクセスできるようになるのかな?また自宅のラボ用にMac miniを買おうと思ってるけど、リモート対応のKVMデバイスが必要になるかも!

テストしてみたら、完璧に動いたよ!1. 有効化: 一般 > 共有 > リモート管理 2. 再起動後、SSHしようとするとこのメッセージが表示される: 「このシステムはロックされています。解除するには、ローカルアカウント名とパスワードを使用してください。成功裏に解除されると、通常通り接続できるようになります。」 3. SSHに成功すると、接続が切れて、次のメッセージが表示される: 「システムが正常に解除されました。SSHを使って通常通り認証できます。」 4. 再度SSHして、入れた!

SSHでデータボリュームを解除する機能は、macOS 26 Tahoeで登場したんだ。面白いね!この前、Tahoeにアップグレードした後に自分のMacにSSHできたのが不思議だったんだ。実際に「アップグレード」ボタンを押したのか疑問に思ったくらい。でも、これは嬉しい変更だね。普段はMacをシャットダウンしないけど、家から離れて作業しているときに、前の晩に大きなアップデートをインストールしたことを思い出してSSHに入れないことがあったから。

面白いね。ただ、データボリュームにシェルが保存されているときに、グラフィカルセッションと同じレースコンディションに悩まされるんじゃないかと心配だな。具体的には、再起動してアプリを再起動するオプションを選ぶと、すべてのボリュームが復号化されてマウントされる前にアプリが立ち上がることがあるんだ。もしシェルがそのボリュームにあると、ターミナルエミュレーターが起動しないかもしれない。例えば、Nixを使ってシェルをインストールしているときにこれが起こることがあるんだ。根本的な問題が解決されない限り、SSHでもこれに遭遇しやすいんじゃないかな。

これは本当に面白い失敗モードだね。こんな問題があるなんて思いもしなかったよ。でもSSHの場合、1秒くらい待ってから再試行すれば大丈夫だと思う。ネットワーク障害に対処するための再試行メカニズムがあるだろうしね。

Appleはデバイスのロック解除後に「ユーザースペース再起動」(すべてのプロセスを終了させる)を行って、この問題を根本的に解決してるんだ。

SSHでのアンロックは、データボリュームのロックを解除した後に接続が切れちゃうから、完全に起動するまでシェルを立ち上げようともしないんだよね。ちなみに、シェルの問題は、実際のシェルを実行する前にnixストアでwait4pathを実行するようなシムでシェルをラップすることで解決できるよ。俺は、そのシムバイナリをデータボリュームの既知のパスに直接インストールするように環境を整えたから、それをログインシェルとして使えるんだ。

それはOSに何十年も前から付いてるwait4pathユーティリティの完璧な使い道だね。

本当に嬉しい変更だよ。特にその目的のためにFileVaultを無効にしてるからね。

企業での非個人用Mac利用にとって、最大の変更だね。Mac Miniは実際、雑多な自動化目的にはかなりコスパが良くて質もいいんだ。職場で切り替え始めたんだけど、ここで説明されているFileVaultの問題が実際に私たちを引き止めていた大きな要因の一つだったんだ。

一般的なサーバーとしてMacを使うことに興味があるんだけど、サーバーとして管理しやすくするために他に何かやってることある?Mac特有のものを動かしてるのか、それとももっと一般的なLinuxのコンテナを使ってるの?

ってことは、システムボリュームはFileVaultで暗号化されてないってことかな?それも納得だよね。システムボリュームは密封された読み取り専用データで、macOSのインストールごとに同じだもん。データボリュームを暗号解除する前に、ネットワークも含めて完全にブートできるのは理にかなってる。オーバーレイを使って、実際にはデータパーティションに書き込んでるのに、システムパーティションに書き込んでるように見せる賢い方法もあるし。FileVaultが密封されたシステムボリュームの暗号化を完全にスキップできるなら、かなり嬉しい変更だね。

常時接続ではないから、WiFiのパスワードもデータボリュームにあるよ。

Omarchy(「強い意見を持った」Archの設定)で遊んでるんだけど、フルディスク暗号化があるから、これをプライマリVMとして使えるか考えてたんだ。実際に使うと、フルGPUアクセラレーションのデスクトップが得られて、長時間の計算ジョブにもアクセスできるんだけど、唯一の障害が新しいMacOSで解決されたことなんだ。数週間離れていて、マシンが電源サイクルした場合、フルディスク暗号化のパスワードを直接入力しないといけないみたい。ProxMoxで動かしていて、GPUのUSBデバイスをVMに渡してるから、標準のVNCビューワーはこの設定では使えない。Omarchyが似たようなことを試すかどうか、興味深いね。

Linuxでは、ずっと前からinitramfsにdropbearを組み込むことができたよ。

残念ながら、これを使うにはmacOS 26という忌まわしいものにアップグレードしなきゃいけないんだよね…多分、最新のXcodeがmacOS 15のサポートを切るまでやらないと思う。

この変更は歓迎するけど、まだ自分に問いかけてるんだ。MacはJetKVMやNanoKVMをサポートしてなかったの?これによってSSHを使わずにもっと柔軟なリモートアクセスソリューションが可能になるはずだよ。