How to bring a SpartanX Connector Node online: import the OVA, put it on the right network, log in, and pair it with the SpartanX platform. After pairing, the node exposes its local network segment to the platform for scanning.

You need two things from whoever built the image:

1. The OVA file (Ask AI for updated download link)

2. The first-login credentials for the spartanx user (see callout below).

Credentials, read before you start

Only used for the initial setup of a new internal node. Once the node is provisioned and you log in for the first time, change the password on the installed machine and use that new password from then on.

The default user and first-login password are rotated on every build and are not embedded in the OVA.
Always ask the AI agent inside the SpartanX platform for the current default user and password before you start a new setup.
If you download a new OVA, ask the AI agent again — credentials from a previous build will not work on a freshly built image.

1. Import the OVA

VirtualBox — File ▸ Import Appliance…, select the .ova, accept the baked defaults (4 vCPU / 8 GB RAM; raise them if you plan heavy scans), and import.

VMware (Workstation / ESXi) — File ▸ Open, select the .ova, and follow the import wizard.

2. Set the network mode

A connector node must reach two networks at once:

Outbound internet — to reach the SpartanX platform (pairing, heartbeat, tunnel).

The private segment you want to scan — e.g. 192.168.0.0/24.

Use a Bridged Adapter, not NAT. Bridged puts the VM directly on your physical LAN, so it gets an IP on the target segment and routes to the internet through your LAN gateway. NAT would give internet access but hide the node behind the host, so it could not reach the local segment as a peer.

VirtualBox — Settings ▸ Network ▸ Adapter 1 ▸ Attached to: Bridged Adapter, then pick the physical NIC that sits on the segment to scan.
VMware — set the adapter to Bridged (replicate physical network state).

Outbound endpoints

Allow these through any corporate firewall — HTTPS/TLS on 443, tunnel on 443/8443:

Host	Purpose
api.spartanx.ai	Pairing handshake
nodes.spartanx.ai	Heartbeat + node control plane (mTLS)
relay.spartanx.ai	Tunnel transport (WSS)

3. Boot and log in

Boot the VM. On first boot a one-shot service locks the public Kali account, so the only way in is the spartanx user.

Remember: Get the latest credentials

Before logging in, request the current default user and first-login password from the AI agent inside the SpartanX platform. These credentials are for the initial setup of a new internal node only and rotate on every build, so always ask for the latest values rather than reusing credentials from a previous node. If you downloaded a new OVA, ask the AI agent again — older credentials will not work.

After your first successful login, change the password on the installed machine and use that new password for all subsequent access to this node.

ssh <default-user>@<node-ip>

Use the first-login password provided by the AI agent.
The first login forces a password change (PAM). Enter the build password, then set a new one. This is expected.

Find <node-ip> from your DHCP server, your router's client list, or by running ip a on the console.

4. Get a pairing code from the dashboard

In the SpartanX platform:

1. Go to Red Teaming ▸ Connector Nodes ▸ Add Node.

2. Fill the form:

Node Name — a descriptive label (e.g. HQ_DataCenter_Segment).
Description — optional.
Network Segments (CIDR) — the segment this node provides access to (e.g. 192.168.0.0/24). Press Enter or click + to add each one.

3. Click Register Node. The node appears as Pairing in Progress.

4. In the Pairing Token panel, enter a reason for revealing the token (min 10 chars — recorded for audit), then click Reveal pairing token.

5. Copy the token now — it looks like sxn_pair_…. It is single-use by the agent: once the node finishes pairing it cannot be revealed again. While the node is still pairing you can re-reveal it with a new justification.

5. Run the pairing command on the node

The pairing command must run as root. On the node:

sudo -i     # root shell (you'll be prompted for the spartanx password)
spartanx-pair sxn_pair_<your_token>

On a production node against api.spartanx.ai the defaults are correct — no environment variables are needed. The control-plane endpoint is learned automatically from the pairing response.

A successful run prints all seven steps and ends with:

Pairing complete!  
Node ID:  <uuid>  
Proxy:    Phalanx transparent proxy active  
Status:   Connecting to relay...

It enables and starts three services: phalanx, jupyter-kg, and spartanx-agent.

6. Verify

On the node:

systemctl status spartanx-agent phalanx
journalctl -u spartanx-agent -f

A healthy agent logs tunnel connected to relay and a heartbeat every 30 s with no rejections.

In the dashboard the node flips from Pairing in Progress to Connected, shows a recent Last seen, and reports its agent version as Up to date.

Troubleshooting

Symptom	Likely cause / fix
First-login password rejected	The credentials rotate on every build and are only valid for the initial setup. Ask the AI agent inside the SpartanX platform for the latest default user and password and try again. If you already changed the password on the installed machine, use that one.
Dashboard stays Pairing in Progress	The pairing command was not run, or it errored before completing. Re-check the node console output.
spartanx-pair: must run as root	Run it under sudo -i (or sudo -E with the env vars inline).
[4/7] … Error: pairing failed	The platform rejected the handshake. Confirm the token is correct and still Awaiting agent pairing (not already consumed), and that the node can reach api.spartanx.ai.
Agent up, but heartbeat rejected by server status=403	The agent is hitting the public API endpoint instead of the mTLS control-plane gateway. Production learns the control-plane endpoint automatically from the pairing response — re-pair to refresh it.
Heartbeat tls: certificate signed by unknown authority	Outdated agent — the control-plane gateway serves a public (Let's Encrypt) cert. Rebuild the node from a current image.
Node version shows Blocked	The agent build is too old / not advertising a version the platform accepts. Rebuild from a current image.
Can't reach the target segment	Network adapter is on NAT or the wrong physical NIC. Switch to Bridged on the NIC that sits on the segment (step 2).

Internal Connector Node(s) - Setup & Pairing Guide