# SSHFS: Mount Remote Filesystems Over SSH

> A filesystem client that mounts remote directories using SFTP (the SSH file transfer protocol), giving SSH servers full filesystem access through your local mount point. No server-side setup required since most SSH servers enable SFTP by default. Supports direct port connections and VM socket access for performance optimization.

**libfuse/sshfs** — A network filesystem client to connect to SSH servers

- Repository: https://github.com/libfuse/sshfs
- Stars: 7,687 · Forks: 548
- Language: C
- License: GPL-2.0
- Published: 2026-09-22 · Updated: 2026-09-22 · Language: en
- Canonical page: https://hysenlabs.com/projects/libfuse-sshfs

## Mounting remote filesystems with SFTP, no server-side setup needed

SSHFS allows you to mount a remote filesystem using SFTP, the SSH file transfer protocol. Because most SSH servers support and enable SFTP by default, SSHFS requires no server-side setup, additional daemons, or special configuration on the server. You mount a remote directory locally and access it like any other filesystem on your machine. This transforms SSH access into filesystem-level access, letting applications read and write files on the remote system transparently. File operations through SSHFS are encrypted end-to-end since they ride on top of the SSH protocol.

The design is simple by intent. Run `sshfs user@hostname:directory mountpoint` and the remote directory appears under your local mount point. If you omit the directory, SSHFS mounts the remote home directory. If you omit the username, SSHFS uses your local username. You can specify SSH options like port number using flags like `-o port=PORT`. SSHFS also inherits all SSH features: public key authentication, SSH config files, password prompts when needed, and per-host SSH settings from ~/.ssh/config. The README documents that many SSH options from sftp(1) and ssh_config(5) can be passed through SSHFS flags.

SSHFS is useful for system administrators who manage files on many servers, developers who edit files on remote machines, and researchers who need to process data on a login node. It is also popular on Steam Deck for accessing game files on a network share and in VM environments where direct filesystem access is not possible. It is a zero-configuration solution compared to setting up NFS or SMB, making it ideal for temporary, per-user mounts.

## Installation and basic usage

SSHFS depends on libfuse 3.1.0 or newer and the Glib library with development headers. Download the latest release from https://github.com/libfuse/sshfs/releases. The repository contains the source in sshfs.c and related files. Build with Meson (version 0.38 or newer) and Ninja:

```bash
mkdir build; cd build
meson ..
```

Then build, test, and install:

```bash
ninja
python3 -m pytest test/
sudo ninja install
```

The build system uses Meson, which is language-agnostic and integrates well with C projects. By default, Meson uses sensible configuration options appropriate for most systems. If you need to adjust build settings (such as enabling or disabling features, setting compiler flags, or enabling stripping), use mesonconf:

```bash
mesonconf
mesonconf -D strip=true
```

Running `python3 -m pytest test/` runs the test suite, which requires the pytest Python module. Tests are optional but recommended to verify the build works on your system. Once installed, mount a filesystem:

```bash
sshfs [user@]hostname:[directory] mountpoint
```

The mount point must already exist and be owned by the user running SSHFS. SSHFS runs as a regular user, not root, to avoid permission escalation; this requires the mount point to be writable by that user. SSHFS will prompt for a password if the SSH connection requires one, delegating the request to SSH directly. SSH key authentication (with or without a passphrase) is also supported. Once mounted, the filesystem is readable and writable according to the file permissions on the remote system.

To unmount on Linux, use `fusermount -u mountpoint`. On BSD and macOS, use `umount mountpoint`. The mount remains until you explicitly unmount it or reboot. The unmount command is different between Linux and BSD-like systems due to differences in how FUSE is integrated into the kernel.

## Direct connections and performance options

For performance-sensitive cases, SSHFS can bypass SSH entirely and connect directly to sftp-server using the `-o directport=PORT` option. This removes SSH protocol overhead, including the key exchange and encryption/decryption cycles. The README shows starting sftp-server on a network port with socat:

```bash
socat tcp-listen:1234,reuseaddr,fork  exec:/usr/lib/openssh/sftp-server
```

Then connect with the directport option:

```bash
sshfs -o directport=1234 127.0.0.1:/tmp /tmp/mnt
```

Direct connections are unencrypted. The README explicitly warns to use this only on localhost or trusted networks where eavesdropping is not a concern. This option is sometimes used by other projects to mount folders inside virtual machines, where network isolation and the trust boundary of a VM provide sufficient security. IPv6 is also possible, allowing you to connect to [::1] directly.

Linux systems can use vsock to connect directly to sftp-server inside virtual machines. Vsock (virtual sockets) provide isolation between the host and VM at the kernel level. On the host (if running an sftp-server), start it on a vsock port:

```bash
socat VSOCK-LISTEN:12345 EXEC:"/usr/lib/openssh/sftp-server",nofork
```

On the client side (inside the VM), use the vsock option:

```bash
sshfs -o vsock=2:12345 unused_host: ./tmp
```

The format is `vsock=CID:PORT` where CID identifies the virtual machine context. Again, this is suitable only for trusted environments and is primarily used for VM-to-host or VM-to-VM communication where encryption is less critical than performance.

## Maintenance status and release cadence

SSHFS is shipped by all major Linux distributions and has been in production use across diverse systems for many years. However, the README is explicit about a constraint: SSHFS has no active, regular contributors. The current maintainer applies pull requests and makes regular releases, but has no capacity for new development beyond addressing high-impact issues. The development model is maintenance mode.

The README instructs bug reporters that unless they include a pull request or report a critical issue, they should not expect a response. This is a deliberate, transparent communication of limits rather than a sign of abandonment or hostility. The maintainer publishes releases consistently. SSHFS 3.7.6 was released on 2026-05-29 with recent fixes. Previous releases were 3.7.5 (2025-11-11) and 3.7.3 (2022-05-26). The gap between 3.7.3 and 3.7.5 is three years, reflecting the light maintenance load, but the recent cadence has accelerated. The last commit to the repository was on 2026-09-16, just two weeks ago. The project hosts a mailing list at fuse-sshfs@lists.sourceforge.net for support questions and uses GitHub for issue tracking. The license is GPL-2.0, which means derivative works and modifications must also be open-source. The repository is at https://github.com/libfuse/sshfs and the source code lives primarily in sshfs.c and related C files in the compat/ directory.

## SSHFS does not solve network performance problems

SSHFS runs over SSH, so it cannot match the performance of NFS or SMB, which are optimized for local area networks and use more efficient protocols. SFTP is fundamentally a file-by-file request-response protocol, not a block-level protocol. Each filesystem operation (opening a file, reading a block, writing data) carries SSH overhead, including encryption and decryption of every request and response. The round-trip latency of SSH is also higher than that of protocols designed for local networks.

The README does not document performance numbers or benchmarks, so you cannot rely on the documentation to determine whether SSHFS meets your throughput requirements for a specific use case. If performance is critical, benchmark it on your actual network first with your actual file access patterns. For high-performance scenarios where many files are accessed in sequence or where you need to transfer gigabytes of data, NFS or SMB on a local network will be significantly faster. The tradeoff is that NFS and SMB require server configuration, administrator privileges to set up shares, and opening additional network ports; SSHFS requires only SSH access, which is often already available. For temporary, ad-hoc access to remote files, SSHFS is usually preferable despite the performance penalty.

## Conclusion

SSHFS is for system administrators, developers, and researchers who need on-demand access to remote files over SSH without configuring NFS or SMB. Use it when you already have SSH access to a server and want temporary, per-user mounts. Skip it if you need high performance, must support many concurrent connections, or if your SSH server disables SFTP. Verify that the remote user account has SFTP access enabled and that the file permissions allow the operations you need before committing to SSHFS for production workflows.

## FAQ

### Is SSHFS the same as SFTP?

SFTP is the protocol. SSHFS is a client tool that uses SFTP to mount a remote directory as a local filesystem. SFTP is file-transfer focused; SSHFS gives full filesystem semantics like a local drive.

### How do I use SSHFS on Linux?

Install SSHFS from your package manager or from source using Meson and Ninja. Run sshfs user@host:directory mountpoint to mount the remote filesystem.

### How do I unmount SSHFS?

On Linux, run fusermount -u mountpoint. On BSD and macOS, run umount mountpoint.

### Is SSHFS still actively maintained?

The maintainer applies pull requests and makes releases, but there are no active contributors. Expect fixes for critical issues and regular updates, but not new feature development.

### Can I use SSHFS on Windows?

SSHFS is native to Linux, macOS, and BSD. Windows users can use subsystems like WSL2 to run SSHFS, or look for Windows ports of the project.

## Sources

- [Issues](https://github.com/libfuse/sshfs/issues)
- [libfuse/sshfs on GitHub](https://github.com/libfuse/sshfs)
- [License: GPL-2.0](https://github.com/libfuse/sshfs/blob/master/LICENSE)
- [README](https://github.com/libfuse/sshfs/blob/master/README.md)
- [Releases](https://github.com/libfuse/sshfs/releases)

---

Hysen Labs editorial analysis, written from the project's own repository and release notes. Cite the canonical page: https://hysenlabs.com/projects/libfuse-sshfs