Connectors

A connector lets Kutrion reach SSH and SFTP hosts on a private network without opening an inbound port. It runs on a machine you control inside that network and holds one outbound tunnel to Kutrion. The broker still originates the session: the credential stays on the Kutrion server, and once a host’s key is pinned the connector is never given a stored credential.

Be clear about the data path. Credentials are decrypted in memory on the Kutrion server, terminal output passes through hosted Kutrion, and open sessions end if the tunnel drops. Ranges a connector may dial limit what it connects to, not what a pinned host can reach onward.

Availability

Connectors are off unless the deployment enables them (the server setting CONNECTOR_TUNNEL_ENABLED=1); with it off, the Connectors page says connectors are not enabled. The connector program itself is currently a development build for Linux, unsigned and not distributed from Downloads; signed packaging is still to come. The number of connectors you can hold depends on your plan, and revoked connectors do not count.

Set up

You need an organization owner or admin role.

1. Open Connectors and choose Create. Name it.
2. Kutrion shows a single-use enrolment token once, with an install command that includes the server’s tunnel key fingerprint. Copy it before you leave; if you do not, issue a new token from the row menu.
3. On the machine that will host the connector, run the install command. It enrols against only the server whose key matches the fingerprint in the command. The token is read from the environment or stdin, not from the command line arguments.
4. Start the connector with the ranges it may dial, for example kutrion-connector run --allow 192.0.2.0/24:22. The connector refuses to start without an allowlist, refuses a wildcard or anything wider than /8 (IPv4) or /32 (IPv6), and always refuses loopback, link-local, multicast, broadcast and its own interface addresses.
5. The row shows Connected once the tunnel is up.

Main tasks

Pin host keys

Before connecting, pin each host’s key for the connector from the row menu, Pin host keys. You review the supplied keys first and confirm the pin with a step-up check.

Send a connection through a connector

When you add or edit an SSH connection, open the advanced options and choose the connector under Reach via (visible to owners and admins). The connection is then reached through the tunnel.

Review and revoke

View audit trail lists the connector’s events. Revoke ends the tunnel immediately; connections that used it refuse to connect, and nothing falls back to a direct dial. Revocation cannot be undone for the key the connector holds; re-enrol with a new token.

Connector program options and records

These apply to the connector program on its host. They are in the development build described under Availability.

Check the connector key at enrolment

At the end of enrol the connector prints its own key fingerprint, in the SHA256: form that ssh-keygen -lf prints. Compare it with the fingerprint your administrator sees for this connector in the Kutrion console. If they differ, do not use the connector: remove it and enrol again. This is the check that catches a middlebox that substituted a key during enrolment.

Behind a TLS-intercepting proxy

If a corporate proxy re-signs HTTPS traffic, the connector cannot verify the server’s own certificate. Two options, on both enrol and run, let it trust the proxy instead:

• --tls-proxy-spki takes the base64 SHA-256 of the proxy’s leaf certificate public key (its SubjectPublicKeyInfo).
• --tls-proxy-ca takes a PEM file holding the proxy’s CA certificate. A certificate is accepted when it chains to the system roots plus that CA and its name matches the host or IP address in --origin, so a CA file does not waive the name check.

Either option, or both, replaces the server certificate pin recorded at enrolment, because a re-signing proxy never presents the server’s own key. The connector logs a warning each time it starts with an override on.

Be plain about what this means. The override trusts the proxy for the TLS leg to Kutrion. A proxy you trust this way could present its own connector key at enrolment, which is why the fingerprint comparison above matters more, not less, when you use it. The override covers the TLS leg only: the tunnel’s SSH host-key pin, taken from the fingerprint in the install command, still applies and is not relaxed.

Records on the connector host

• Egress address. On enrol and run the connector logs the local address its traffic to Kutrion leaves from, so you can match it against firewall and proxy logs.
• Channel-open log. Every channel the server asks the connector to open is appended to channel-open.log in the connector’s state directory (/var/lib/kutrion-connector unless you pass --state), or to the file named by --channel-log. A line holds the time, the outcome (accepted, refused or failed), the requested target, the address dialled and a reason. It holds no credentials and no session traffic. The connector logs the path at start.
• Rotation. The file is capped at 10 MiB. At the cap it is renamed to the same name with .1 added and a new file starts, so one earlier generation is kept and the next rotation replaces it. Copy the file elsewhere if you need a longer history.

Routes editor

Open a connector’s row menu and choose Edit routes. The editor lists the connector’s routes, lets you add and remove them, and saves the whole set at once. A revoked connector cannot be edited.

A route is a rule on the server that says which targets a connector may be asked to reach. It is a second control on top of the connector’s own allowlist, and both must allow a connection. A connector with no routes reaches nothing.

• CIDR route - an IP range. It admits only a target given as an IP address inside it.
• DNS-suffix route - a domain suffix such as corp.example.com. It admits a hostname equal to the suffix or ending in it. A hostname needs a DNS-suffix route. Kutrion never resolves a name on a connector route, so a CIDR route does not admit a hostname, and a suffix route does not admit an IP address.
• Ports - each route lists ports, defaulting to 22.

Rules the server enforces when you save:

• Saving replaces the whole set of routes for the connector, under a lock.
• Ranges wider than /8 (IPv4) or /32 (IPv6), and loopback, link-local, unspecified, multicast, broadcast and IPv4-mapped ranges are refused, as is a localhost suffix.
• A newly added range wider than /16 (IPv4) or /64 (IPv6), or a one-label DNS suffix, needs you to acknowledge it explicitly. The editor shows a confirmation listing those ranges before it saves.
• Every save is audited with the before and after sets. Every connection the routes refuse is audited as well.
• Removing a route does not end a stream that is already open; the next open is refused.

Routes cover SSH and SFTP connections. Connections for FTP, FTPS, WebDAV, S3, Azure Blob and Swift cannot be assigned to a connector; the server refuses it.

Where to go next

• Connecting to hosts
• SSH broker overview
• Audit logs