How to Mount a Remote SSHFS Directory Automatically at Boot in Debian

To mount a remote SSHFS directory automatically in Debian, configure noninteractive SSH authentication and add an SSHFS entry to /etc/fstab. With systemd, you can either connect during boot or activate an automount at boot and connect when the directory is first accessed. The second approach is useful when the remote server or network may be unavailable during startup.

This reference uses Debian 13 “trixie” documentation reviewed on October 9, 2026, including SSHFS 3.7.3 and systemd 257 documentation. The commands are configuration examples, not results from a tested deployment. Check your installed manuals if you use another release.

Choose when the SSHFS connection should start

The main example uses an on-demand mount. The distinction matters: an active automount does not mean an SSHFS connection already exists. See Debian’s systemd automount manual for the relationship between the automount and its matching mount unit.

Before you start

• The Debian client uses systemd and you have sudo access.
• The remote account supports SFTP and can access the intended directory.
• The client can reach the remote host, including any required VPN or jump host.
• You have a way to verify the remote server’s SSH host-key fingerprint.
• The local mount point is empty and is not a critical system directory.

Replace files@storage.example.net:/srv/data with your remote username, hostname, and directory. The hostname is a placeholder. The local mount point is /mnt/remote; the dedicated key is /root/.ssh/sshfs_boot.

This is an administrator-managed system mount. It runs locally as root but logs into the remote server as files, not remote root. The SSHFS project documentation generally recommends running ordinary interactive mounts as a regular user. A system boot mount requires deliberate credential and access management.

1. Install the client packages

sudo apt update
sudo apt install sshfs openssh-client
sshfs --version
systemctl --version

Install SSHFS on the Debian client. The remote system needs working SFTP service; it does not need an SSHFS installation just to serve files. If package installation fails, resolve the repository or connectivity issue before editing boot configuration.

2. Prepare the mount point and dedicated key

sudo install -d -m 0700 /root/.ssh
sudo mkdir -p /mnt/remote
sudo ssh-keygen -t ed25519 -f /root/.ssh/sshfs_boot -N ''
sudo chmod 0600 /root/.ssh/sshfs_boot

そのパスにある既存のキーを上書きしないでください。必要に応じて別の名前を選択し、以下で一貫して使用してください。この無人実行の例では、パスフレーズが空なのは意図的なものです。起動時にキーのロックを解除できる担当者がいないためです。クライアントを保護し、リモートアカウントには必要なディレクトリ権限のみを付与してください。ポリシーで暗号化されたキーが必要な場合は、代わりに管理された無人ロック解除メカニズムを設定してください。

鍵生成オプションについては、Debianのssh-keygenマニュアルに記載されています。デスクトップのSSHエージェントでロック解除された鍵は、システムマウントでは自動的に利用できません。

3. キーを認証し、無人SFTPを検証する

sudo ssh-copy-id -i /root/.ssh/sshfs_boot.pub files@storage.example.net

このセットアップ接続中は、表示されるホストキーのフィンガープリントを、信頼できるチャネルを通じてサーバー管理者から取得した値と比較してから承認してください。このコマンドはローカルのroot権限で実行されるため、通常のホストキーレコードはrootのSSHファイルに保存されます。サーバーでパスワードベースのセットアップが無効になっている場合は、管理者に公開鍵をインストールしてもらってください。

次に、ブートマウントで使用するのと同じIDとホストキーファイルを使用してSFTPをテストします。

sudo sftp -i /root/.ssh/sshfs_boot \
  -o IdentitiesOnly=yes -o BatchMode=yes \
  -o StrictHostKeyChecking=yes \
  -o UserKnownHostsFile=/root/.ssh/known_hosts \
  files@storage.example.net

SFTPプロンプトで、 を使用しls /srv/data、次に を使用しますbye。これは、パスワードや確認プロンプトなしで機能する必要があります。は対話型認証を防止します。明示的なホストキー設定は検証を保持します。これらのオプションは、OpenSSHクライアント設定マニュアルBatchMode=yesで定義されています。

デフォルト以外のポートを使用する場合は、-p 2222ssh-copy-id、-P 2222sftp、およびport=2222SSHFSオプションで指定してください。ジャンプホストが必要な場合は、rootユーザーのSSHコンテキストでもそのルートを設定してテストしてください。

4. 手動マウントが機能することを証明します

sudo sshfs files@storage.example.net:/srv/data /mnt/remote \
  -o IdentityFile=/root/.ssh/sshfs_boot,IdentitiesOnly=yes,BatchMode=yes \
  -o StrictHostKeyChecking=yes,UserKnownHostsFile=/root/.ssh/known_hosts
sudo ls /mnt/remote
sudo umount /mnt/remote

リストが意図したリモートディレクトリに属していることを確認してください。この例では、最初はローカルマウントの所有者であるrootのみにアクセスが許可されているため、確認にはsudoを使用してください。systemd管理の設定を開始する前に、アンマウントして完了です。ディレクトリがビジー状態の場合は、そのディレクトリを使用しているシェルやアプリケーションを閉じてください。

SSHFSはリモートアカウントの権限を使用します。クライアント側でroot権限を持っていても、サーバー側で追加の権限は付与されません。設定を永続化する前に、認証、SFTP、またはリモートパスのエラーをここで修正してください。

5. 永続的なfstabエントリを追加する

sudo cp -a /etc/fstab /etc/fstab.sshfs-backup
sudoedit /etc/fstab

バックアップファイルが既に存在する場合は、別のバックアップファイル名を選択してください。以下の内容を1行として追加し、例のサーバーとパスを置き換えてください。

files@storage.example.net:/srv/data /mnt/remote sshfs _netdev,nofail,x-systemd.automount,x-systemd.mount-timeout=30s,IdentityFile=/root/.ssh/sshfs_boot,IdentitiesOnly=yes,BatchMode=yes,StrictHostKeyChecking=yes,UserKnownHostsFile=/root/.ssh/known_hosts,ConnectTimeout=10,reconnect,ServerAliveInterval=15,ServerAliveCountMax=3 0 0

DebianのSSHFSマニュアルではsshfs、fstabファイルシステムタイプとして指定されており、fuse.sshfs互換性のために受け入れられます。最後のフィールドは、このエントリのダンプとファイルシステムチェックのスケジュールを無効にします。パスに空白が含まれている場合は、 fstabフォーマットのリファレンスを参照してください。

systemd固有のオプションについては、Debian systemd mountマニュアルに記載されています。マウントタイムアウトは、その後のすべてのファイル操作に期限を設けるものではありません。

6. systemdをリロードして自動マウントを有効にする

sudo findmnt --verify --verbose
sudo systemctl daemon-reload
sudo systemctl start mnt-remote.automount
systemctl status mnt-remote.automount
sudo ls /mnt/remote
findmnt -t fuse.sshfs

続行する前に、検証メッセージを確認してください。findmntマニュアルにはfstab の検証について記載されていますが、これは設定を確認するものであり、リモート認証情報が有効かどうかをチェックするものではありません。ディレクトリにアクセスすると、別途接続テストが実行されます。

上記のユニット名は に対応しています/mnt/remote。別のパスの場合は、 を使用してマウント名を導出してくださいsystemd-escape --path --suffix=mount /your/path。fstab から生成されたユニットには、別途コマンドは必要ありませんsystemctl enable。

起動時に接続を試行したい場合は、x-systemd.automountエントリから削除してください。ディレクトリのユーザーを解放した後、その自動マウントとマウントユニットを停止し、systemd をリロードして、対応するマウントユニットを開始します。nofailストレージをオプションのままにする場合は、そのままにしてください。

7. 再起動後の動作を確認する

適切なメンテナンス時間に再起動してください。オンデマンド構成の場合は、まず自動マウントを確認してから、ディレクトリにアクセスしてください。

systemctl status mnt-remote.automount
sudo ls /mnt/remote
systemctl status mnt-remote.mount
findmnt -t fuse.sshfs

起動後に自動マウントが有効になり、アクセス後に実際にSSHFSマウントが確立されることが期待されます。autofsエントリが存在するだけでは、リモートファイルが接続されていることを証明できません。ローカルのマウントポイントフォルダが存在するかどうかだけでなく、既知のリモートファイルまたはディレクトリが存在するかどうかを確認してください。

アプリケーションが起動前にこのストレージを必要とする場合は、以下の内容を含むドロップインをサービスに追加してください。

[Unit]
RequiresMountsFor=/mnt/remote

systemd.unitに記載されているこの依存関係は、必要なマウントポイントを取得して配置します。systemd をリロードし、アプリケーションの起動を個別にテストしてください。アプリケーションには、適切なローカルアクセス権限も必要です。

8. 障害の種類別にトラブルシューティングを行う

sudo journalctl -b -u mnt-remote.mount
sudo journalctl -b -u mnt-remote.automount

network-online.targetこれは起動時の同期ポイントであり、特定のサーバーやVPNに接続できることを保証するものではありません。systemdのnetwork-onlineの説明にその制限事項が記載されています。

ローカルユーザーによる意図的なアクセスには、allow_other,default_permissions,uid=1000,gid=1000実際のローカルIDに置き換えて を追加することを検討してください。これにより、マウント所有者以外のユーザーもアクセスできるようになりますが、カーネルのパーミッションチェックは引き続き適用されます。UID/GIDオプションは、サーバー側の所有権ではなく、表示される所有権を変更します。ルートマウントではuser_allow_other、fuse.confに は必要ありません。このポリシーにより、ルート以外のマウントがより広範なアクセスを要求できるようになります。FUSEパーミッションマニュアルを参照してください。これらのオプションを変更した後、意図したアプリケーションユーザーとして再テストしてください。

根本的な問題を解決した後、マウント失敗状態をクリアしてアクセスを再試行してください。

sudo systemctl reset-failed mnt-remote.mount
sudo ls /mnt/remote

再接続はすべてのアプリケーションに対して透過的な復旧手段ではありません。以前に開いたファイルが失敗し、再度開く必要がある場合があります。書き込みが中断されるとデータが失われる可能性があります。ワークロードでより高い耐障害性が必要な場合は、別のストレージ設計を選択してください。

運用チェックリストとロールバック

• 無人SFTPは、ブートIDと全く同じものを使用して動作します。
• ホストキーは検証され、指定されたファイルに保存されます。
• fstabエントリは解析され、パスワードや秘密鍵の内容は含まれていません。
• 再起動後にアクセスすると、意図したリモートリストが表示される。
• 実際のローカルユーザーまたはサービスは、必要なファイルを読み取ることができます。
• アプリケーションが利用できないストレージをどのように処理するかを理解している。

設定を無効にするには、ディレクトリを使用しているアプリケーションを停止し、mnt-remote.automountおよびを停止しmnt-remote.mount、fstab からこのエントリのみを削除して、を実行しますsudo systemctl daemon-reload。他の fstab エントリは保持してください。マウント設定を削除しても、リモート ファイルは削除されず、リモート認証キーも取り消されません。