Privileged Access Management for Linux server fleets — an agentless credential broker and bastion
Privileged SSH becomes a controlled, monitored, and interruptible channel.
The credential never reaches the user: a per-session certificate that lives for five minutes and never leaves the broker's memory. A denied command stops before the target host — it doesn't surface on a recording after the fact. The audit trail is written on the gateway, where the attacker cannot reach it.
The risk it closes
Privileged SSH is the highest-risk everyday operation in an enterprise Linux fleet. The conventional model — a key on the user's machine, sudoers on the target, logs in the same place — breaks at four points.
Standing credentials. The key lives on the user's workstation — it can be stolen, copied, shared. One compromised workstation means immediate root access.
No standing credential: a per-session, five-minute certificate that never leaves the broker's memory. Nothing to steal, nothing to forget to revoke.
No command-level control. Once on the host, the user does whatever sudo allows — there is no safety net against a mistyped or malicious command.
Every command is evaluated against policy before it reaches the target; a denied command never starts. The built-in deny rules cannot be bypassed.
The logs sit where the attacker is. They are written on the target host, where root can delete them — after an incident, the evidence is exactly what's missing.
The audit trail is written on the gateway, append-only, ready for SIEM ingestion. Root on a compromised target cannot reach the logs written about it.
Approval is a policy document, not an enforced control. The process describes it, but nothing enforces it — the auditor's question is answered with procedure, not proof.
An approval gate and a ticket anchor sit on the execution path: nothing runs without the decision, and the decision, the approver and the timestamp stay in the audit trail.
How it works — the broker model
The administrator doesn't log in to the target host, but to the ISG. There are two separate SSH connections, not a pass-through tunnel: the ISG takes the command, evaluates policy on it, and if it passes, executes it over its own client connection — on the user's behalf, with a short-lived certificate.
Operator
isg CLI or webUI — deliberately connects to the gateway
ISG gateway
MFA · directory authorization · policy engine · CA · approval · audit
Target host
CA trust only (TrustedUserCAKeys) — no agent, no PAM module
The firewall allows SSH to the targets exclusively from the gateway — this is the single funnel: one supervised entrance to the entire fleet. The certificate's principal is the real user's name, so on the target host utmp, journald and the sudo log all see the person, not a shared service account. The chain of trust runs both ways: the target proves its own identity with a host certificate — and a connection to an unverified host never falls back to password authentication.
The command is executed and logged together with its output — searchable, bound to the session ID.
The command waits on the gateway: nothing runs on the target until the approver decides — from the CLI or the browser, through the same server-side layer.
The command never reaches the target host. The user gets the rule name and the reason; the event stays in the audit trail.
Four layers of defense
Defense in depth: four layers built on each other, each answering a different question.
Identity
Who is logging in?
Directory authentication (LDAP / Active Directory) with enforced MFA. A wrong password ≠ a directory outage: failed passwords count toward lockout, infrastructure failures do not.
Authorization
Entitled to this host?
Group membership as the ticket in, within the ceiling of the issuance policy. Per-host group requirements make "team X reaches only the X machines" a technical constraint.
Command control
What is allowed?
A per-command policy engine, tuned to the target's lockdown level: allow, require approval, or deny — before execution.
Accountability
What actually happened?
Command transcript, session recording, ITSM ticket, SIEM export — all on the gateway, all retrievable.
Principle: no single layer is perfect. If one lets something through, the next one catches it. If all of them do, the log remains — written in a place the attacker cannot reach.
Key capabilities
Policy — customizable, never loosenable
The rule set is composed from two sources, and the two add up. The built-in deny rules — interactive root shell, destructive system deletion, password changes — always come first and are always active: customer rules cannot override them.
The built-in approval requirements, by contrast, sit at the end of the chain: they can be overridden with explicit intent. The effective rule list can be inspected with per-rule source labels.
Lockdown levels per host
Every target host gets a level, and the same rule set automatically tightens with the environment — from sandbox to critical, regulated scope.
The level can also come from the CMDB, based on labels: a new production host falls under the correct rules the moment it is enrolled, with no manual upkeep.
Approval and the ITSM anchor
A pending command waits on the gateway; the decision, the approver and the timestamp stay in the audit trail and bound to the ticket.
Every access above the threshold gets a JIRA ticket — even when no approval was required. The ticket intent is written to a persistent outbox: an ITSM outage doesn't paralyze troubleshooting, and no silent audit gap is created either.
Two complementary logs
The command transcript is structured: command, policy decision, result, timestamped — "who issued a permission-changing command in the last 30 days?" is a single query.
The session recording is the full screen stream of the interactive session, replayable — for review, accountability, and training.
Live sessions, immediate termination
A live list shows who is on which host and since when — and any session can be terminated from the outside with a single action.
Reaction time drops to minutes, and none of it requires anything on the target host.
Non-human identities (NHI)
Backup scripts, CI/CD jobs, scheduled tasks — an order of magnitude more machine identities than human accounts, often with secrets that never expire.
Here the ISG acts as a certificate issuer: a one-hour certificate with automatic renewal and immediate, serial-based revocation. A gateway outage doesn't stop the nightly backup — the control is issuance, fully audited.
Fits the systems you already run
No parallel user registry, no vendor transport layer — the ISG plugs into the enterprise systems already in place.
IAM / directory
LDAP / Active Directory — bind and group-based RBAC. Removal from the directory takes effect immediately: no issuance, no login.
ITSM / ticketing
JIRA — session anchoring: every access above the threshold gets a ticket. Fail-open, with a persistent outbox and a compensating alert.
CMDB / inventory
Label-based host classification — lockdown level and policy scope assigned automatically, with no manual upkeep.
Secrets management
HashiCorp Vault / OpenBao — in signer: vault mode the broker never even reads the SSH CA private key, signing happens inside the secrets manager; MFA secrets can live in the KV instead of on disk.
HA / load balancer
Active-active: N brokers behind a shared name, with a shared PostgreSQL record store and a brute-force budget common across brokers; session recordings archive to S3-compatible storage (RustFS / AWS S3). Every broker carries a CA-signed gateway host certificate for the shared name — switching brokers raises no host-key warning; an unhealthy broker drops out of the pool via /readyz.
Monitoring
/healthz and /readyz for the load balancer, Prometheus /metrics for Grafana and Alertmanager, isg system check with exit codes (Nagios / Zabbix / CI).
SIEM
Append-only JSON lines with a versioned schema — Splunk / Elastic / QRadar. The log file is the source of truth, and writes are fail-closed.
Supports meeting access-management and logging requirements: least privilege, enforced MFA, centralized and integrity-protected audit, an approver and a timestamp behind every privileged action.
Deployment — agentless, in reversible steps
No running component is installed on the target hosts. The footprint is purely static configuration: one line in the SSH service (CA trust), one host certificate, and the break-glass key set — all three reversible, version-controllable, and distributable with configuration management.
No kernel version dependency, no agent compatibility matrix, no performance risk across the fleet. Version upgrades happen at one point, on the gateway — not on N thousand machines.
The critical property is the measurement step: the system measures whether the cutover would lock anyone out, before the cutover happens. It's not caution that makes the rollout risk-free — it's measurement.
Observe
Controls log but don't block — you can see who the cutover would lock out by mistake.
Provision
Preparing the target hosts; the old access keeps working throughout.
Measure
A coverage indicator: how many hosts are ready for the cutover.
Enforce
The gates switch to blocking, host group by host group.
Close out
Retiring the old, direct access on the target hosts.
The full technical documentation is public.
Architecture and chain of trust, policy reference, installation and operations guide, command and configuration reference — version-controlled, released together with the product.