SSH & SCP

Iruka has a built-in SSH connection manager and supports SCP file transfers and SFTP remote browsing without leaving the app.

Adding a Connection

1. Click the SSH section in the sidebar
2. Press the + button to add a new connection
3. Fill in the connection details, then click Save

Connecting

Click a saved connection in the sidebar to open an SSH session in the terminal panel. Authentication is handled entirely by your local SSH stack — if you have a key loaded in ssh-agent, 1Password, or similar, it's picked up automatically. Password prompts appear in the terminal.

SCP File Transfer

Right-click any file or folder in the file list and choose Send via SCP… or Receive via SCP….

Send — uploads the selected file(s) to a remote server:

• Pick a saved connection from the dropdown
• Enter the remote destination path (e.g. ~/uploads/ or /var/www/)
• The command preview shows exactly what will run
• Click Send — the scp command runs in your terminal; password prompts (if any) appear there

Receive — downloads files from a remote server into the current folder:

• Pick a connection and enter the remote path (wildcards like ~/logs/*.log are supported)
• The destination is always the folder you're browsing
• Click Receive — runs in the terminal the same way

Browsing Remote Files (SFTP Mount)

To browse a remote server's filesystem directly in Iruka, use SFTP mount instead of SCP:

1. Right-click a saved connection in the sidebar and choose Mount as SFTP
2. Iruka mounts the remote filesystem locally (via rclone's SFTP backend + FUSE)
3. The mount appears in the sidebar under Connected — navigate it like any local folder
4. Right-click and choose Unmount SFTP when done

One-time setup: three steps, in this order

SFTP mounts go through the same machinery as FTP and cloud mounts — the official rclone plus a FUSE layer — so they need the same one-time setup. It is three steps, and the order matters: run step 2 before step 1 and the installer will appear to succeed while changing nothing.

Step 1 — Remove Homebrew's rclone. Skip this if you have never run brew install rclone.

brew uninstall rclone

Homebrew's macOS rclone is compiled without mount support and refuses to mount. Worse, leaving it in place breaks step 2: the official installer sees that same version already present and skips, so you end up exactly where you started. Check with brew list rclone if you are unsure.

Step 2 — Install the official rclone from rclone.org. Both lines.

curl https://rclone.org/install.sh | sudo bash
sudo chmod 755 /usr/local/bin/rclone

The chmod is not optional housekeeping: the installer occasionally leaves the binary readable only to root, which stops macOS from verifying its signature when Iruka launches it — you would see "Could not prepare credentials" with nothing else to go on.

Step 3 — Install fuse-t, the FUSE layer.

brew install --cask fuse-t

We recommend fuse-t over macFUSE: it runs in userspace, so it needs no kernel extension, no reboot, and no approval in System Settings, and it works on locked-down or company-managed (MDM) Macs. macFUSE is not required.

Confirm all three landed — the path must be /usr/local/bin/rclone, not a Homebrew Cellar path:

which rclone          # /usr/local/bin/rclone
rclone version        # prints a version, not a mount error
ls /usr/local/lib/libfuse-t.dylib

Iruka checks all three when you open the connection dialog and shows the steps still outstanding, so you never wait through a failed mount to find out. See FTP & Cloud Mounts → Requirements for the same setup in the context of the other remote protocols.

Why rclone and not sshfs? sshfs doesn't mount over fuse-t, so Iruka mounts SFTP through rclone's :sftp: backend. Key files, SSH agents and passwords all work — set the method in Edit Connection → Authentication.

Running commands on the server

The terminal is a local shell. When you browse a mounted volume it follows you into the mount point, so commands work — but each one travels over the network through the mount, and a stalled mount can leave ls hanging.

For real work on the server, press the network button in the terminal header while inside a mounted volume. Iruka opens an SSH session, lands in the folder you're viewing, and keeps it in step as you browse: each folder in the volume maps to its path on the server. Commands then run natively on the server. Type exit and the terminal returns to your Mac, resuming normal syncing.

This is the only case where syncing survives a nested shell. Ordinarily — ssh you typed yourself, su, tmux, an editor — Iruka stops sending cd, because it has no way to know what that shell is or where it is. A session Iruka opened itself is the exception, because it knows both.

Mounting as Root (sudo)

A normal mount can only touch files your own account can reach. Turn on Mount as root in Edit Connection to read and write anywhere on the server: Iruka runs the server's SFTP service under sudo, so every copy, move, rename and delete in that volume happens as root. The volume is labelled (root) wherever it appears.

There is no Trash and no undo on a server. A mistaken delete in a root volume is gone. Leave this off unless you need it.

Set it up (one line, on the server)

sudo normally asks for a password, and a mount cannot answer one — the SFTP protocol is already using the channel the prompt would appear on. So that single command must be allowed without a password.

Run sudo visudo and add this as the last line of the file, replacing the username and path:

youruser ALL=(root) NOPASSWD: /usr/lib/openssh/sftp-server

Then confirm it worked:

sudo -n -l /usr/lib/openssh/sftp-server    # prints the path = ready to mount

It must be the last line. sudo applies the last matching rule, so a group rule further down — Ubuntu ships %sudo ALL=(ALL:ALL) ALL — overrides the same rule placed above it, and your line does nothing at all. This is the usual reason a correct-looking rule has no effect.

Use your own sftp-server path. It follows Subsystem sftp in /etc/ssh/sshd_config:

If that line reads internal-sftp, the SFTP service is built into sshd and there is no program for sudo to elevate. Install the standalone one (openssh-sftp-server on Debian and Ubuntu), or connect as root instead.

Scoping the rule to one command leaves the rest of sudo password-protected as usual. All authentication methods work with it — key file, SSH agent and password.

Confirm a mount really is elevated

In the mounted volume, open /root or create a folder inside /etc. Both are refused for an ordinary account regardless of its groups: being in sudo or wheel grants the right to run sudo, not direct access to files.

Authentication Tips

• SSH keys — set the key path in the connection editor, or leave it blank and load your key into an SSH agent (ssh-add ~/.ssh/id_ed25519, or Passort / 1Password). Iruka uses the explicit key if set, otherwise the agent, otherwise a default ~/.ssh/id_* key
• Host keys — when the server already has an entry in your ~/.ssh/known_hosts, SFTP mounts verify against it and refuse a changed key; a server you have never connected to is trusted on first use, as ssh does. Reset a changed key with ssh-keygen -R hostname (use ssh-keygen -R "[host]:port" for a non-standard port)