Flagship features · SSH · SFTP native russh
SSH · SFTP
A MobaXterm-style client that stacks a terminal, remote file browsing (SFTP), extra shells, and port forwarding on top of a single authenticated SSH connection. Register a host → connect in-tab → edit and transfer remotely, all without leaving the app.
Connecting
The entry point for connecting is the SSH icon on the right rail. Click it and the connection manager opens as a right-hand panel, showing your saved hosts (groups · search) and current sessions in one place. Clicking outside or pressing Escape does not close it (always open).
-
Open the connection manager from the rail
Click a host and a tab opens in the current Space and starts connecting (saved profiles come pre-filled; double-click to reconnect immediately). The header's New host, Vault, and Port forwarding open from here too.
SSH connection manager — right-docked panel2 connectedSSH hosts▾Work3🖥web-prod-01×2🖥web-prod-02×1🗄db-02▾Personal2🖥home-nas🍓raspberrypi▸Cloud1① Entry is the icon at the right of the title bar · green dot = connected,×N= session count (click to jump). ② Secrets are never stored — only host info is kept. -
In-tab connect form
A connect form appears inside a new tab. Fill in host, user, and port, then pick an auth method — Password / Public key (key path + optional passphrase) / SSH Agent. On success the tab becomes the SSH terminal itself. If a connection fails, the app tells you the specific reason — key file not found / passphrase required / other authentication failure. Private-key paths may start with
~(e.g.~/.ssh/id_rsa), which expands to your home directory.New SSH connection — auth: public keySSH connection
e.g. deploy@web-prod-01.example.comAuthentication① Switch among the three auth methods (password · public key · SSH Agent) with the segmented control. ② Even on failure, host and user are preserved and the form reappears — and it tells you why it failed (key missing, passphrase required, etc.) so you can retry right away.
Host-key trust (TOFU)
For a server you've never seen, or when its host key changes, the connection pauses and a fingerprint confirmation dialog appears. Accept it and it's remembered in known_hosts so future connections are automatic (TOFU = trust on first use).
Trust this host key?
Seeing web-prod-01.example.com:22 for the first time. Confirm with the server's admin that the fingerprint matches.
known_hosts and connects. ② If the key changes, a red warning appears in the same spot.Export · import profiles
In the connection manager you add and edit hosts and use groups, search, and double-click reconnect. Secrets are never stored — only info like host, user, port, auth method, and key path is kept (a key path is just a location reference, not the key contents).
- Own JSON — share a bundle of profiles as a file. With no secrets, there's no leak risk.
- Import
~/.ssh/config— read hosts straight from your existing OpenSSH config. - Imported profiles appear in the list by group, and you connect with a click or double-click.
SFTP remote explorer
When you connect over SSH, the left file explorer switches automatically to that server's remote tree (MobaXterm-style). It expands the remote home over the same connection, no extra login.
- Double-click to edit — open a remote file, edit it, and saving writes straight to the server. If the file changes on the server, it's re-read automatically within about 3 seconds (a confirmation dialog if you're mid-edit).
- Auto-refreshing tree — creations and deletions in expanded folders are reflected every 3 seconds.
- Open a terminal from a remote folder — the context menu opens a new SSH shell on the same session, with no re-auth, and cd's into that folder.
- Remotes in the project switcher — the header dropdown shows local projects alongside connected SSH (
user@host), and picking a remote keeps the remote tree even when you switch to a local terminal tab.
user@host = remote origin (switch local↔remote in the switcher). ② Double-click to edit remotely.Files over 5MB or binary won't open in the editor, just as locally. Remote paths are always /-style (POSIX).
Create · rename · delete remote files
Right-click or use to create, rename, and delete files and folders in the remote tree — the same flow as the local explorer.
- Auto-create parent folders — name a new item like
a/band any missing parent folders are created too. - Delete a whole folder — a folder is removed along with its contents in one go.
- Permanent delete — there's no recycle bin on the remote, so it can't be undone; a stronger confirmation than local is shown.
File transfer (upload · download)
Transfer files and folders local↔remote. Download via right-click on the remote tree → "Download"; upload via dual-pane drag (below). Even large files transfer directly without passing through app memory.
- Transfer a whole folder — move a folder and its descendant files transfer along with it.
- Four-way conflict choice — if a name already exists, you're asked: overwrite / skip / overwrite all / skip all.
- Progress bar + cancel — the current file, count, and % progress bar are shown inside the explorer, and you can cancel.
Dual-pane SFTP (drag to transfer)
The "Open SFTP" button on an SSH terminal tab opens the same connection's remote tree as a separate tab, and you drag files between the left explorer ↔ the SFTP tab to transfer (MobaXterm dual-panel style). With multiple connections, a picker asks which one to attach to.
Dragging from the OS desktop or file manager isn't supported — transfers are done by dragging between the two panels inside the app.
Follow the shell (cd → tree sync)
When you cd in the SSH shell, the remote pane and the left remote explorer follow to that path automatically (shell→tree, one-way). It's off by default and only works once you flip the toggle on.
- The moment you turn it on, one setup line is sent to the shell once (seeing one line in the scrollback is the expected result of turning it on).
- It works in bash · zsh without touching your existing shell config (no-op in fish and the like).
- The remote pane's "Follow CWD" toggle and the left explorer toggle share the same state.
cd makes the tree follow to the same path.Credential vault
An optional vault that stores SSH secrets (passwords · key passphrases) encrypted and uses them automatically when you connect to a saved profile (no need to type them each time). Open it with the vault icon in the connection manager header.
- Encryption — all secrets are stored in a vault (AES-256-GCM) locked by a single master password. The vault file is kept separate from the settings DB.
- Kept inside the app only — a stored secret's plaintext is never surfaced back to the screen (app UI); it's used only inside the app at connect time.
- Connect integration — use the form's USE toggle to apply stored credentials (entering the master password if needed), and the SAVE checkbox to store them after a successful connect.
Credential vault
lockedTo use stored secrets, unlock the vault with your master password.
Port-forwarding tunnel
Create local (-L) and dynamic SOCKS5 (-D) port-forwarding tunnels on top of an SSH connection. The config is saved in the profile (host:port only, not a secret) and established automatically on a successful connect. It binds to 127.0.0.1 only, so it isn't exposed to the LAN.
- Local (-L) — connects a port on your PC to a
host:portbeyond the remote (e.g.127.0.0.1:5432 → db-02:5432). - Dynamic (-D) — acts as a SOCKS5 proxy, routing browser and tool traffic beyond the server.
- Management — from the connection manager's "Port forwarding" button, view and stop active tunnels or add one on the fly.
Port forwarding — web-prod-01
tmux session persistence — remote sessions that survive disconnects
Turn on "tmux session persistence" in a profile and, on connect, a profile-specific tmux session is created on the remote and attached to. Even if the network drops or you close the window or tab, the remote session keeps running — builds, dev servers, log tails, and long-running work don't die. Reconnect and you're re-attached to the same session automatically, picking up right where the screen was.
- Stable session name — the session name is fixed per profile (
orchterm-<profile>), so reconnecting finds and attaches to exactly the same session. - Create if missing · attach if present — a single
tmux new -A -s …on connect creates the session on first connect and attaches (-A) to it on reconnect. - Graceful fallback — if the remote has no tmux, it falls back to a normal login shell automatically (
|| exec "$SHELL" -l). In short, connecting always works even without tmux.
tmux new -A -s orchterm-<profile>.⚠️ The remote host must have tmux installed for sessions to persist (otherwise it connects with a normal shell automatically). This setting is preserved across profile export/import too.
To many servers at once — MultiExec broadcast
When two or more SSH sessions are live, a Broadcast section appears in the connection manager. Pick the sessions to add to the group with the member checkboxes and press On — a command typed into one terminal in the group is sent to every member at once. You can run the same command (deploy · patch · restart · check logs) across many servers in one go.
- Input-only fan-out — only the command (input) goes to every member; output is received by each session on its own (check per-server results separately).
- Loop prevention — input received via broadcast isn't re-propagated, so there's no infinite fan-out among members.
- Member indication — terminals that are broadcasting members are highlighted with an outline (layout unchanged).
- Hidden with one session — it's meaningless alone, so the section appears only when two or more are live.
Cross-platform · security
- No stored secrets — SFTP, extra shells, and tunnels reuse the already-authenticated connection, so there's no new secret. On restart, remote connection state isn't restored and you return to local.
- Cross-platform — supports Windows · macOS · Linux (macOS is under additional verification in some environments).