Remote execution, without handing out shell access

What the usual answers cost

Scheduled work rarely stays on one host. A backup has to be quiesced on the database server, a file has to be collected from the transfer host, a service has to be restarted in another data centre.

The usual arrangements are all variations on one theme: give something the ability to run arbitrary commands somewhere else.

None of these is negligent. They are what you build when the requirement is real and the alternatives are expensive.

What it should look like instead

The remote host decides what may run. Not the caller, and not whoever holds a credential. Each agent defines the exact set of scripts it will run, and nothing outside that set can be invoked regardless of credentials. No shell is exposed.

Both ends authenticate cryptographically. Mutual TLS, certificates managed automatically, no shared passwords and no key distribution problem.

Authorisation is evaluated per request, centrally. Not just 'is this caller known' but 'may this caller run this script, with these arguments, at this time of day, inside this change window'. Integrating with the identity infrastructure you already have - LDAP, OIDC - rather than a second set of accounts.

Every operation is logged on both sides. A correlated request ID, the script name, the arguments, the caller's identity and the exit code - recorded on the controller and on the agent, and not clearable by the operator who ran it.

One command reaches many hosts. Dispatch to a fleet simultaneously and collect structured results, so routine operations and incident response do not become a loop over hostnames.

Small enough to install everywhere. Minimal dependencies, no external package registries required at install or at runtime.

What a controlled execution layer has to do

The other two comparisons in this section set the standard tool against the product feature by feature. The same table for remote execution, taking ssh with a shared key as the baseline because it is what most sites are actually running.

Capability	ssh and a shared key	Xi-Exec
Run a named script on a remote host	Yes	Yes
Run across many hosts in parallel	Scripted by hand	Yes
Restrict the callable surface to a fixed set	ForceCommand, per key	Yes, an allowlist on the agent
Decided by the target host rather than the caller	No	Yes
No shell exposed on the target	No	Yes
Arguments constrained and validated	No	Yes, per-script argument schemas
Per-operation authorisation policy	No	Yes, an auth hook at dispatcher and agent
Identity carried cryptographically	Key, not identity	Yes, mutual TLS
Central access control	No	Yes
LDAP or OIDC integration	No	Yes
Structured audit log with a correlated request id	Session logs only	Yes
Audit trail the caller cannot alter	No	Yes
Credential rotation	Key distribution across every host	Certificate renewal, per agent
Runs with no agent on the target	Yes	No, an agent is required
REST API	No	Yes

Two rows are worth reading together. ssh needs nothing installed on the target and Xi-Exec needs an agent: that is a real cost, and it is what buys every row above it. The invariant the agent enforces is that a holder of a valid dispatcher certificate can invoke the approved actions and nothing else, and cannot alter the allowlist, the policy or the audit trail - even with full control of the dispatcher.

The alternatives, side by side

These are the options a team actually weighs, and what each one costs in practice. Everything here is a real evaluation rather than a competitor scorecard: several of these are perfectly good tools being asked to do a job they were not designed for.

Approach	What it gives you	What it costs
Shared SSH key and service account	Works immediately, nothing to install	Anyone who can read the key runs anything that account can. Rotation is a project nobody schedules.
Service account with a shell	Flexible, familiar	Blast radius is everything the account can do. "Who ran that, and when" has no good answer.
SSH with ForceCommand	Restricts a session to one command, which is the right instinct	Per key, not per operation, so per-script granularity is awkward. Key management remains. No structured logging.
Fabric, Paramiko and similar wrappers	Scriptable, familiar to developers	SSH underneath, so key management and access control are inherited. Adds a language runtime to every host.
Configuration management (Ansible, Salt, Puppet)	Excellent at what it is for	Designed for convergence, not task execution. Control-plane and dependency footprint out of proportion to running a script.
A management API per service	Precise for that service	Per service rather than general, with no consistent authorisation or logging model across them.
Xi-Exec	A named operation, on a known host, by a known identity, logged	Requires an agent on each target host and a one-time pairing step per host.

The distinction that decides it: none of the first six gives you remote procedure call. They give you remote shell, and then ask you to fence it in afterwards. Xi-Exec starts from the operation.

Where this sits in the cycle

Xi-Exec is the layer between scheduling and output.

Xi-Batch schedules the work and decides when it should run. Xi-Exec carries it to the hosts where it has to happen, without handing out shell access. Xi-Text takes the output and delivers it.

Each is useful alone. Together they are the whole of the nightly run, from one supplier, with one support contract.

Next

About Xi-Exec · About Xi-Batch · Talk to us