Connection model

WingGate separates the service you connect to from the wing-connector you run inside your own network. This article describes the responsibility split, the transport between the two sides, and the connector's optional local SSH entry.

Two sides: the service and the wing-connector

WingGate is the service: it authenticates users, stores metadata, and enforces authorization. The wing-connector runs next to the target machines and is the only component that speaks SSH to them; it dials out to WingGate and never needs an inbound listener. The connector you run stays inside your trust boundary, close to the assets it serves.

Outbound-only, over mutual TLS

The wing-connector dials out to WingGate and establishes a mutually authenticated TLS channel. WingGate uses that reverse transport to reach your assets, so target machines never need an inbound listener or a public IP. MCP tool payloads, file bytes, and shell streams flow between your clients and the connector over the data plane and do not pass through the service; Web Terminal is the one exception, bridged through the service's session stream.

SSH Direct: the connector's own SSH entry

A wing-connector can expose a local SSH listener (SSH Direct). Your SSH client connects to that listener on the connector host directly, instead of to WingGate's SSH endpoint. The connector authenticates you through WingGate, then lists only the assets your grants authorize; the shell itself still runs through the same Session, grant and audit boundary as any other entrypoint.

SSH Direct has two flavours. A wing-connector's own listener is disabled by default and configured per connector; WingGate's SSH entry carries no local listener config at all — WingGate owns it centrally and supplies a default endpoint on first install. A wing-connector's listen address and accepted authentication methods (public key, password + OTP, web approval) are edited in the Web Console per connector; WingGate's entry endpoint is not a node-local setting and is not managed from the connector page. In both cases the node keeps only ssh_direct.allowNonLoopback as its local security intent. The listener is exposed on the connector host, so its network exposure follows the host's firewall. See Connectors for the setup.