Inshipia Security Gateway

First SSH session

From a running gateway with a first identity (getting started) to a first brokered SSH session: prepare one target host, connect, and find the session in the record. The full preparation of a production server is target host preparation; what the gateway lets an operator do there is SSH policy and approval.

First target

A target host is not ready simply because the gateway can reach it. Two things have to be true, and they are two different directions of trust:

Both require the CA to exist, so run isg ca init first — it is idempotent, and the SSH and X.509 halves are independent of each other.

A NEW X.509 CA needs the names it may certify, named explicitly:

isg ca init --permitted-dns isg.example.local --permitted-ip 192.168.57.0/24

Those two flags become the CA certificate's nameConstraints, and with neither of them the command creates nothing at all and says why. The reason is the admin UI: its serving certificate is signed by this CA, so a browser that should open it without a warning has to trust the CA — and an unconstrained CA key could impersonate any website on the machine that imported it. A --permitted-dns entry permits the domain and its subdomains; --permitted-ip takes CIDRs (/32 for a single address). --no-name-constraints is the deliberate way out, and the command states in one line that the CA it created is unconstrained.

The constraint can only be set on a NEW certificate, so on a gateway whose X.509 CA already exists the flags change nothing — the output says which constraints that CA actually carries. isg system check's x509_ca_name_constraints row reports the same thing at any time.

Neither step is something to improvise: the exact sshd configuration on the target, the order to apply it in, and how to verify it without locking yourself out are covered by the target-host preparation guide.

First connect

With the daemon running, the CA initialized and one target prepared:

isg connect <target> --as <user>

--as is required and names the OS user to become on the target. The daemon tells you who it thinks you are, runs the access gates, challenges you for a second factor, mints the certificate, dials the target and hands you a prompt. Every line you type there is one policy decision and one audit entry. exit, quit or logout ends the session.

Two variants are worth knowing early. --command <command> runs a single command and exits with that command's own exit code, which is what makes the gateway scriptable. --change <id> attaches a change-management reference to the session record.

If mfa.yaml sets mfa_mode: totp, each operator enrols once with isg mfa enroll before their first connect. Enrolment is self-service and goes through the running daemon, so isg serve has to be up for it.

Two doors, one session. isg connect runs on a broker itself: the daemon identifies the caller from the unix socket (session.sock), so the operator needs a shell on the broker and membership of the isg-operators group. Everyone else comes in from their own machine through the gateway login — over SSH as the isg-login user, with the target as the command (deployment) — and answers the username, password and MFA prompts. Both doors lead to the same access gates and the same session record, and both print the session ID when the session opens.

Connect to the gateway by its shared name, not by an address: the brokers' host certificates name the shared name, so a single @cert-authority line in known_hosts accepts whichever broker currently holds it.

The session in the record

The session is in the admin view at https://<gateway>:8765/ (Sessions), with its transcript and its recording, and in audit.log as a line per event. The checks of the installation itself are on getting started.