Iruka iconIrukaIruka home

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 details:

| Field | Notes | |---|---| | Name | Optional display label | | Host | Hostname or IP address | | Port | Defaults to 22 | | Username | Optional — leave blank to defer to ~/.ssh/config | | SSH Key | Optional — leave blank to use your default key or agent |

  1. 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

Requires the same tools as FTP/cloud mounts: the official rclone (from rclone.org — the Homebrew build can't mount) and a FUSE layer, with fuse-t recommended:

curl https://rclone.org/install.sh | sudo bash
sudo chmod 755 /usr/local/bin/rclone   # the installer occasionally leaves it root-only
brew install --cask fuse-t

The chmod matters: the rclone installer sometimes leaves the binary readable only to root, which stops macOS from verifying its signature when Iruka launches it (you'd see "Could not prepare credentials"). fuse-t needs no kernel extension, reboot, or approval — macFUSE is not required (see FTP & Cloud Mounts → Requirements for the full setup). SFTP mounts through rclone rather than sshfs because sshfs doesn't mount over fuse-t. 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:

| Distribution | Path | | --- | --- | | Debian, Ubuntu | /usr/lib/openssh/sftp-server | | RHEL, Fedora, Alma | /usr/libexec/openssh/sftp-server | | Alpine, Arch | /usr/lib/ssh/sftp-server |

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)