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

Apple: SSHとFileVault

2025年9月19日原文(keith.github.io)

概要

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を実行するようなシムでシェルをラップすることで解決できるよ。俺は、そのシムバイナリをデータボリュームの既知のパスに直接インストールするように環境を整えたから、それをログインシェルとして使えるんだ。

Hacker Newsで議論の続きを見る