Per-Host Overrides

Once ZestSSH knows which Network you’re on, the last step is resolving the connection: it takes the host’s base config and layers that network’s overrides on top. This page is about those overrides — what a network can change for a host, how inheritance works, and the security note you should not skip.

Create the network first

Per-host overrides live in the connection editor, not on the Networks page, and a host only shows override rows for networks that already exist. If you have not created a network yet, add one first (Settings -> Networks on Android and iOS; the Networks entry in the left sidebar on desktop), give it at least one trigger, then come back to the host. Jump to How to set one up for the walkthrough.

An override is defined per (host, network) pair. It always starts from the host’s base config and changes only the fields you fill in. Everything you leave blank is inherited from the base. That is the whole model: a network profile is a thin diff over the base, never a full second copy of the connection.

Think of it like a document with tracked changes. The base config is the original text. A network’s override is a set of edits marked on top. Where there’s no edit, the original shows through. ZestSSH “accepts all changes” at connect time to produce the final connection.

---

What a network can override

Field	Override effect	If left blank
Address	Reach the host at a different hostname or IP on this network	Inherits the base address
Port	Use a different SSH port on this network	Inherits the base port
Username	Log in as a different user on this network	Inherits from the host’s identity
Identity (key)	Authenticate with a different saved key/credential	Inherits the base identity
Jump-host chain	Change the route: add hops, swap the bastion, or go direct	Inherits the base jump route
Port-forward rules	Turn each saved forward on or off for this network	Each forward keeps its own default
Skip / unreachable	Mark the host as not reachable on this network at all	Host is reachable, using the resolved config

All of these come together in the connection editor’s Networks section. See How to set one up below for the step-by-step.

Address and port

The most common override. At home your NAS is 192.168.1.10:22; from anywhere else it’s nas.example.com reached through a bastion. You set an address (and, if needed, port) override on the Home network and leave the base pointing at the away route. Blank means inherit — so if only the address differs, override the address and leave the port empty.

Username and identity (key)

A network can change who you log in as and which key proves it. This is useful when the same box is reached as admin over the trusted LAN but as a restricted deploy user through a public jump host, or when different networks require different keys.

One subtlety worth knowing: the username comes from the identity, not from the connection record itself. So when a network override doesn’t set a username, ZestSSH reads it from whichever identity is in effect (the override’s identity if you set one, otherwise the base host’s). Override the username directly only when you want a name that differs from the identity’s own.

The jump-host chain

A network can completely rewrite how you route to a host — this is where Networks and jump hosts meet. Three distinct outcomes are possible:

• Add or change hops. Give the override a chain of jump hosts (up to three hops in the editor). On this network the connection routes through them instead of the base route.
• Go direct — “no jump on this network.” This is the important one. On your home LAN the box is reachable directly, so the away bastion is not just unnecessary, it’s wrong. Setting the route to direct on the Home network overrides the base’s jump host and connects straight through. (Under the hood, an explicit empty chain beats the base’s jump setting — the override is actively saying “no hops here,” which is different from “inherit.”)
• Inherit. Leave the route untouched and the host uses whatever jump route its base config defines.

The resolver picks the route with this precedence: the override’s chain (even when it’s explicitly empty) wins first; then the base host’s own jump host; otherwise a direct connection.

Per-network port-forward rules

Your host’s saved port forwards can be enabled or disabled per network with a three-state control — Inherit / On / Off — for each rule:

State	Behavior on this network
Inherit	The forward follows its own default (its normal auto-start behavior)
On	Force the forward on when connecting on this network
Off	Force the forward off on this network

So a database tunnel that should auto-start at the office can be forced Off on cellular, and a home-only forward can be pinned On at home. This control appears inside a network row only for hosts that actually have saved forwards, and changes here save immediately — they don’t wait for the host’s Save button.

Skip / mark unreachable

Sometimes the right answer on a given network is “don’t even try.” Marking a host unreachable on a network means an attempt to connect there is refused up front with a clear message rather than hanging on a timeout. Use it for a home-lab machine that should never be dialed over cellular, or a box that genuinely has no route from a particular environment. On other networks the host connects normally.

---

How inheritance resolves (the merge)

When you connect, the resolver merges base and override field by field. The rule is uniform: the override wins where it sets a value; otherwise the base shows through. The result is the effective connection — the address, port, username, key, and route that actually get used.

Consider a host NAS with this base config:

address:   nas.example.com
port:       22
username:   deploy           (from its identity)
route:      via "Bastion"

…and a Home network override that sets only:

address:   192.168.1.10
route:     (direct — no jump on this network)

On Home, the effective connection resolves to:

address:   192.168.1.10      ← override
port:       22               ← inherited from base
username:   deploy           ← inherited from base identity
route:     direct            ← override (explicit "no jump")

Everywhere Home doesn’t match, no override applies and NAS connects exactly as its base config says — nas.example.com:22 through Bastion.

In the host editor, each network row shows this resolved result at a glance, along with a status chip:

Chip	Meaning
Inherits base	No override — this network uses the base config as-is
Overridden	At least one field is changed on this network
Skipped on this network	The host is marked unreachable here

---

Security: a rerouted endpoint gets a fresh host-key prompt

ZestSSH verifies host keys on a trust-on-first-use basis, and it remembers a trusted key per endpoint — keyed by the host address, port, and key type. That has a direct, deliberate consequence for overrides:

When a network override changes the address or port, you are pointing at a different endpoint — so ZestSSH will prompt you to verify its host key the first time, exactly as it does for any new server.

This is a safety feature, not a bug. 192.168.1.10 and nas.example.com are, as far as key verification is concerned, two different destinations that must each earn your trust. Don’t reflexively accept the new key: confirm the fingerprint belongs to the machine you expect, the same way you would for a brand-new connection. A network override quietly sending you to an attacker-controlled address would still have to get past this prompt.

The flip side: once you’ve trusted the LAN endpoint and the public endpoint, each is remembered independently, and switching networks won’t nag you again unless a key actually changes — which is precisely when you want to be warned.

---

How to set one up

Per-host overrides live in the connection editor, not in the Networks list. (Define your networks first — see Triggers & Matching — so there’s something to override for.)

1. Open the host you want to configure and edit it. Scroll to the Networks section.
2. At the top you’ll see a read-only Base config card — the address, port, username, key, and route every network inherits unless it overrides them. Use it as your reference point.
3. Below it is one row per network you’ve defined (plus Default). The network that matches right now is highlighted and labelled, with a short note on why it matched (for example, “on subnet 10.20.0.0/24”).
4. On the network you want to customize, open its mode selector and choose:
   • Use base config — inherit everything (the default; nothing is stored).
   • Override — expand the row and fill in only the fields that differ: address, port, username, identity, jump chain, and any per-network port-forward states.
   • Mark unreachable from this network — refuse connections to this host on this network.
5. For a jump route, add hops with the jump-host picker (up to three); to force a direct connection where the base uses a bastion, clear the route so the row shows (direct).
6. Use Test as this network on the row to probe the resolved config — reachability only, or a full authenticated connection — before you rely on it.
7. Save the host. (Port-forward on/off states save immediately and don’t need the Save button.)

If you have no custom networks yet, the section shows only the Default row and a gentle pointer to the Networks page — there’s nothing meaningful to override until at least one custom network exists.

---

---

Common mistakes

Leaving the base jump host in place when overriding the address for a LAN. If Home overrides the address to 192.168.1.10 but doesn’t clear the route, ZestSSH still tries to reach 192.168.1.10 through the bastion — which usually can’t see your home LAN. When you go direct, set the route to direct too.

Confusing “inherit” with “clear.” Leaving a field blank means inherit the base value, not remove it. To actively remove the base’s jump host on a network, use the direct route option — an explicit “no hops” — rather than expecting a blank field to strip it.

Accepting the new host-key prompt without looking. Rerouting to a different address is exactly the situation where a host-key prompt is protecting you. Verify the fingerprint; don’t rubber-stamp it.

Overriding the username when you meant the identity. Because the username is normally derived from the identity, switching the key is often all you need. Set an explicit username only when it must differ from the identity’s own user.

Expecting an empty “Override” row to do something. An override with no fields filled in is treated as “use base” and isn’t stored — it would be identical to inheriting. Fill in at least one field, choose Mark unreachable, or leave the row on Use base config.

Marking a host unreachable and forgetting. A skipped host refuses to connect on that network by design. If a host won’t connect from one place but works everywhere else, check whether that network’s row is set to unreachable.

---

Free tier vs. Pro

The Networks feature itself — profiles, triggers, per-host overrides, skip, and per-network port-forward toggles — is available on every tier. Two things a network override can compose follow their own tier rules:

Capability	Free	Squeezed (Pro)
Networks, triggers, address/port/username/key overrides	Yes	Yes
Per-network port-forward on/off	Yes	Yes
Mark host unreachable per network	Yes	Yes
Jump host in a route (Connect Via)	Locked	Yes
Concurrent active port forwards	Locked	Unlimited

In other words: you can define and override networks freely, but a route that uses a jump host relies on the Connect Via feature, which is a Squeezed capability. See Jump Hosts and Port Forwarding for the details of each.

---

Next steps

• Triggers & Matching — how the network that drives these overrides is chosen, and how to preview with “Test as this network.”
• Networks Overview — the detect -> match -> resolve model these overrides complete.
• Jump Hosts — building the routes a network override can add, swap, or clear.
• Port Forwarding — the forwards a network can turn on or off per environment.