0 Secure SSHFS mounts (read-only, fstab, pitfalls) - kevwells.com

Secure SSHFS mounts (read-only, fstab, pitfalls)

by

Short version: Use SSHFS for occasional admin access, not as a core storage layer. Mount over SSH with per-user keys, prefer read-only, and avoid backup loops.

1) Install (client)

# Debian/Ubuntu
sudo apt update && sudo apt install -y sshfs
# RHEL/Rocky/Alma
sudo dnf install -y fuse-sshfs

2) One safe pattern (read-only)

sudo mkdir -p /mnt/remote-logs
sudo sshfs -o ro,Compression=yes,ServerAliveInterval=30,ServerAliveCountMax=3 \
admin@server.example.com:/var/log /mnt/remote-logs

Why ro? Avoid accidental edits and ransomware blast-radius.

3) Persist with /etc/fstab

# /etc/fstab
admin@server.example.com:/var/log /mnt/remote-logs fuse.sshfs \
_netdev,ro,IdentityFile=/home/admin/.ssh/id_ed25519,Compression=yes,allow_other,uid=0,gid=adm 0 0

Uncomment user_allow_other in /etc/fuse.conf if you need allow_other. Otherwise omit it.

4) Rollback

sudo umount /mnt/remote-logs
sudo sed -i '\|server.example.com:/var/log|d' /etc/fstab

5) Pitfalls

  • Performance: latency hurts. Don’t run apps over SSHFS.
  • Backups: exclude the mount or you’ll recurse remote trees.
  • Keys: per-user keys only; no shared logins.

Security gaps in Linux and cloud systems risk downtime, data compromise, lost business — and compliance failures.

With 20+ years’ experience and active UK Security Check (SC) clearance, I harden Linux and cloud platforms for government, corporate, and academic sectors — ensuring secure, compliant, and resilient infrastructure.

Contact for Contract Assignments

Related posts:

  1. SSH reverse tunnels: a safe baseline (with rollback)