Debianで起動時にリモートSSHFSディレクトリを自動的にマウントする方法

SSHFSマウントを設定し、動作を確認してからDebianを再起動すると、リモートディレクトリが再び空になってしまうことがあります。手動コマンドが機能したのは、ログイン済みでネットワークが既にオンラインであり、SSHがパスワードやホストキーの確認が必要な場合に質問できたためです。起動時のマウントには、こうした利便性はありません。

確実な解決策は、SSH認証を非対話型にし、永続的なエントリを作成し/etc/fstab、ファイルシステムがネットワークに依存していることをsystemdに伝えることです。このガイドでは、最もシンプルな動作設定から始め、低速ネットワークや切断されたSSHセッションに対するオプションを追加します。例では、user@server.example.com:/srv/dataリモートディレクトリとして、/mnt/remoteローカルマウントポイントとしてを使用します。

Debianのパッケージページには現在、Debian 12 (Bookworm) 用のSSHFS 3.7.3が掲載されており、SSHFSはSSHが提供するSFTPサブシステムを使用します。DebianのSSHFSパッケージページとアップストリームのSSHFSマニュアルを参照してください。パッケージのリビジョンはDebianのリリースによって異なりますが、以下のブートマウント方法は標準的なfstabとsystemdの動作に基づいています。

SSHFSマウントは手動では正常に動作するのに、起動時には失敗するのはなぜですか？

ほとんどの失敗は、主に3つの原因で発生します。まず、SSH接続時にパスワード、キーパスフレーズ、または初回ホストキー確認が必要になる場合があります。ブートジョブには、これらのプロンプトに応答できる端末がありません。次に、ネットワークやDNSが完全に利用可能になる前にマウントが開始されることがあります。最後に、長期間継続していたSSH接続が、ネットワークの中断後に無効になることがあります。

Debian の systemd ドキュメントでは、この_netdevオプションによってマウントがネットワーク マウントとして扱われることが説明されています。ネットワーク マウントは の後に順序付けられますnetwork-online.target。同じドキュメントには、/etc/fstabエントリが起動時にネイティブ systemd マウント ユニットに変換されることが記されています。Debianの systemd.mount(5)を参照してください。

1. SSHFSをインストールし、マウントポイントを作成します。

パッケージ化されたSSHFSクライアントをインストールし、リモートファイルを公開するローカルディレクトリを作成します。

sudo apt update
sudo apt install sshfs
sudo mkdir -p /mnt/remote

SSHFSは、Linuxのユーザー空間ファイルシステムインターフェースであるFUSEをベースに構築されています。Debian 12では、このsshfsパッケージはFUSE 3とOpenSSHクライアントに依存しています。

2. プロンプトなしで実行できるSSH認証を設定する。

systemdによって開始されるシステム全体のマウントの場合、マウントヘルパーはroot権限で実行されるため、rootが所有する専用キーを作成するのは簡単です。パスフレーズなしでキーを生成するのは、マシン自体が信頼されており、キーがこの目的に限定されている場合に限ります。

sudo ssh-keygen -t ed25519 -f /root/.ssh/sshfs_remote
sudo ssh-copy-id -i /root/.ssh/sshfs_remote.pub user@server.example.com

2番目のコマンドは通常、リモートアカウントのパスワードを一度だけ要求します。その後、非対話的に正確なIDをテストします。

sudo ssh -i /root/.ssh/sshfs_remote -o BatchMode=yes user@server.example.com true

このコマンドがプロンプトを表示せずに正常に終了した場合、認証は起動準備完了です。サーバーのフィンガープリントの確認を求められた場合は、rootユーザーとして対話的に接続し、信頼できるソースと照合してフィンガープリントを検証し、承認してください。ホストキーのエラーを回避するために、ホスト検証を無効にしないでください。

OpenSSH はBatchMode=yes、パスワードと確認プロンプトを無効にするため、スクリプトやバッチ ジョブ専用のドキュメントを作成します。ホスト キーはユーザーのknown_hostsファイルと照合されます。Debianの ssh(1) マニュアルとssh_config(5)を参照してください。

3. fstabを編集する前に、SSHFSマウントを手動で確認してください。

基本的な SSHFS コマンドが正常に動作するまで、ブート順序のデバッグは行わないでください。同じキーを使用してディレクトリを一度マウントしてください。

sudo sshfs user@server.example.com:/srv/data /mnt/remote   -o IdentityFile=/root/.ssh/sshfs_remote   -o reconnect   -o ServerAliveInterval=15   -o ServerAliveCountMax=3

リモートファイルの一覧表示が可能であることを確認してから、fstabをテストする前にアンマウントしてください。

ls -la /mnt/remote
sudo fusermount3 -u /mnt/remote

上流の SSHFS マニュアルでは、reconnect中断された接続を再確立するための推奨事項が示されています。また、ServerAliveIntervalアイドル状態の SSH 接続がサイレントに切断された場合に、マウントがフリーズしたように見えるのを防ぐことができることも説明されています。15 秒の間隔と OpenSSH のデフォルトの応答なしプローブのカウントが 3 回の場合、切断された接続は約 45 秒で検出されます。ここでは動作が明確になるようにカウントを明示的に記述しています。

4. /etc/fstab に永続的な SSHFS エントリを追加する

編集する前にファイルをバックアップしてください。

sudo cp /etc/fstab /etc/fstab.backup
sudo nano /etc/fstab

1行追加してください：

user@server.example.com:/srv/data /mnt/remote fuse.sshfs _netdev,IdentityFile=/root/.ssh/sshfs_remote,BatchMode=yes,reconnect,ServerAliveInterval=15,ServerAliveCountMax=3,default_permissions 0 0

このfuse.sshfsサブタイプは、Debian のマウントツールで認識されます。アップストリームの SSHFS マニュアルでも、sshfsfstab ファイルシステムタイプとして文書化されており、fuse.sshfs互換性に関する注記があります。Debian のfstab(5) マニュアルでは、 6 つの fstab フィールドについて説明し、 などのファイルシステムサブタイプの表記を推奨していますfuse.sshfs。

5. 再起動する前にfstabエントリをテストする

再起動前にタイプミスを/etc/fstab修正する方がはるかに簡単です。systemdに生成されたマウントユニットを再読み込みするように指示し、エントリをテストしてください。

sudo systemctl daemon-reload
sudo mount -a
findmnt -T /mnt/remote
ls -la /mnt/remote

mount -aエラーが返されず、findmntが報告された場合fuse.sshfs、fstab構文は受け入れられ、ファイルシステムがマウントされます。Debianのmount(8)マニュアルではmount -a、がマークされたエントリを除くfstabファイルシステムをマウントすることが確認されていますnoauto。

ネットワークの準備が間に合わなかった場合はどうなるでしょうか？

_netdevsystemdに正しい順序付けセマンティクスを提供しますが、そのnetwork-online.target精度はそれを提供するネットワーク管理サービスの精度に依存します。Wi-Fi、VPN、DHCPの遅延、DNSの遅延、および特殊なネットワークスタックによって、即時ブートマウントが不安定になる場合があります。

その場合は、systemdの自動マウント機能を使用して、起動プロセスが自動マウントポイントを作成し、SSHFSへの最初のアクセス時にのみ接続を確立します/mnt/remote。x-systemd.automountオプションに以下を追加してください。

user@server.example.com:/srv/data /mnt/remote fuse.sshfs _netdev,x-systemd.automount,IdentityFile=/root/.ssh/sshfs_remote,BatchMode=yes,reconnect,ServerAliveInterval=15,ServerAliveCountMax=3,default_permissions 0 0

これは、リモートホストが一時的に利用できなくなる可能性があるノートパソコン、Wi-Fiシステム、サーバーなどでは、多くの場合より良い選択肢となります。動作原理が若干変更され、自動マウントは起動時に準備されますが、実際のSSH接続は初回アクセス時に行われます。アプリケーションが起動前にリモートディレクトリへの接続を必須とする場合は、通常のネットワークマウントを維持し、そのアプリケーションのsystemdユニットをマウントユニットに依存するようにしてください。

allow_otherは必要ですか？

デフォルトでは、FUSEマウントはマウントコンテキストに関連付けられた権限でのみアクセス可能です。SSHFSマニュアルにallow_otherは、他のローカルユーザーによるアクセスを許可する方法が記載されています。サービスまたは他のアカウントがマウントされたファイルを本当に必要とする場合を除き、アクセス権限を追加しないでください。

を使用する場合はallow_other、/etc/fuse.confまず FUSE のセキュリティ上の影響を確認してください。 と組み合わせるのがdefault_permissions一般的に適切です。そうすることで、ローカルの Unix 権限チェックがスキップされなくなります。リモート SSH アカウントが、最終的にサーバーが許可する操作を決定します。

ブート時のSSHFS障害のトラブルシューティング

マウントはパスワードを待っています

と全く同じ非対話型テストを繰り返してくださいsudo ssh ... -o BatchMode=yes。テストが失敗した場合は、systemd を変更する前に公開鍵認証を修正してください。パスフレーズで保護された鍵には、エージェントまたは別の起動時秘密鍵メカニズムも必要になります。単純な fstab マウントではパスフレーズを入力できません。

ホストキーの検証に失敗しました

包括的な解決策として設定しないでくださいStrictHostKeyChecking=no。サーバーが再構築されたか、ホストキーが正当な方法で変更されたかを確認してください。SSHホストキーのチェックは、なりすましや中間者攻撃に対するセキュリティ対策です。

ログイン後はマウントが機能するが、起動中は機能しない。

生成されたユニット名とそのジャーナルを確認してください。 の場合/mnt/remote、systemd は通常、次のパスをエスケープしますmnt-remote.mount。

systemctl status mnt-remote.mount
journalctl -b -u mnt-remote.mount

追加した場合はx-systemd.automount、以下も確認してください。

systemctl status mnt-remote.automount

サーバーまたはネットワークが消失した後、アクセスが停止する

キープreconnectとSSHキープアライブを有効にしてください。アップストリームのSSHFSマニュアルでは、接続の切断が検出されない場合、ファイルシステム操作が永久にブロックされる可能性があると警告しています。キープアライブによって障害検出のタイミングは制限されますが、接続が切断された時点で進行中だったI/Oは依然として失敗する可能性があり、アプリケーションによる再試行が必要になる場合があります。

マウントが再起動後も維持されることを確認する方法

成功したらmount -a、マシンを再起動してください。

sudo reboot

再接続後、以下のチェックを実行してください。

findmnt -T /mnt/remote
systemctl is-active mnt-remote.mount
ls -la /mnt/remote

を選択した場合x-systemd.automount、マウントユニットは最初のアクセスまで非アクティブになる可能性があります。まず自動マウントを確認し、次に で起動してくださいls。

systemctl is-active mnt-remote.automount
ls -la /mnt/remote
findmnt -T /mnt/remote

設定が成功した場合、確認できる特性は4つあります。SSH認証が操作なしで完了すること、fstabエントリが合格することmount -a、systemdがマウントをネットワーク依存として認識すること、そしてクリーンな再起動後にリモートファイルにアクセスできることです。これらのチェックのいずれかが失敗した場合は、マウントオプションを無作為に追加するのではなく、該当するレイヤーを直接トラブルシューティングしてください。