SSH, Inbound, WebSocket, Windows, and Ephemeral Agents: Connectivity, Remoting, and Agent Lifecycle: Configuration, Design Choices, and Tradeoffs

1. There is no universally best launcher

Launcher choice follows topology. Ask who can initiate a connection, where identity is anchored, what firewall/proxy path exists, who owns the agent process, how often workers are replaced and which failure evidence operators can actually observe.

2. SSH vs inbound TCP vs WebSocket

Do not translate this table into a ranking. The useful evidence is whether the selected path matches actual network direction, identity policy and operator support model.

3. SSH host trust is separate from SSH user authentication

An SSH private key proves which client identity is being presented. Host-key verification proves which server Jenkins reached. Both are required. If a host is rebuilt and its key legitimately changes, review the infrastructure change and update the known fingerprint; do not suppress verification to “make it connect.”

Scope the SSH credential to the lab/folder where feasible and run the remote process under a dedicated account. The account needs a writable agent root and build tools; it should not need root/admin or access to the controller filesystem.

4. Inbound secret is node bootstrap identity

Inbound connection material is generated for a configured node. Treat it like a credential. The command can read the secret from a file using the @ form so it is not a literal process argument.

Remoting documentation warns that a compromised secret should not be “rotated” by blindly reusing the same affected node name. In a disposable environment, retire that node identity and create a replacement name/material.

5. WebSocket moves firewall complexity into the HTTP path

WebSocket often reduces open ports, but it increases reliance on the reverse proxy/load balancer path. Preserve:

• controller URL actually used by the agent;
• TLS hostname/certificate validity;
• proxy WebSocket Upgrade handling;
• idle/read timeout behavior;
• agent and controller timestamps around disconnects.

Do not change low-level ping or Remoting tuning properties until ordinary proxy/network evidence demonstrates a need.

6. Service vs interactive process

7. Static vs ephemeral lifecycle

Static agent: you patch Java/tools/OS in place, monitor disk/workspace drift and preserve stable host identity. Ephemeral agent: you rebuild from an image/template, treat the workspace as disposable, and rely on archived/external evidence. The latter reduces persistent drift but moves trust to the image supply chain and provisioning definition.

A hybrid fleet is normal: stable hardware workers for specialized devices plus ephemeral general-purpose CI. Keep trust labels and credentials aligned with the lifecycle.

8. Windows choices

Windows can use inbound TCP/WebSocket with agent.jar like other platforms. Run persistent agents under a dedicated Windows account and a managed startup mechanism. If builds require interactive GUI behavior, isolate that into a specialized agent pool and document the session dependency; do not turn every Windows agent into a logged-in administrator.

The official inbound-agent image also publishes Windows variants for supported Windows container environments, but those are optional. A Windows host/VM is not required to learn the process/identity/lifecycle model.

9. Controller-supplied agent.jar vs pinned image

For a directly launched JVM, controller-supplied agent.jar is the simplest compatibility anchor. For container fleets, pin a reviewed official image tag/digest and include its Remoting/Java identity in your evidence. Avoid mutable image tags for reproducibility.

10. Design each transport change with rollback

11. Worked scenario

A company has Linux build workers in a private subnet, Windows UI-test workers behind an outbound-only firewall, and short-lived generic CI containers. A reasonable design can use SSH for stable Linux hosts where controller-to-worker SSH is permitted and host keys are managed; WebSocket inbound for Windows workers that can only reach HTTPS; and ephemeral inbound containers for burst CI. The protected Windows/SSH pools remain separate from untrusted pull-request agents.

Evidence must show endpoint direction, agent/Java/Remoting identity, OS account, labels/trust classification, workspace root and teardown behavior for each pool.

Knowledge check

Answer before revealing the explanation.

Official references and version notes

• Jenkins LTS changelog and Java support policy — lab baseline Jenkins 2.568.3 LTS; Jenkins system components, including agents, require Java 21 or 25 on this baseline.
• Using Jenkins agents and Managing Nodes — distributed execution, node configuration, Windows agent examples, and lifecycle concepts.
• Jenkins Remoting and Launching inbound agents — obtain agent.jar from the controller; inbound command, -webSocket, work directory, and direct TCP guidance.
• SSH Build Agents plugin — baseline 3.1097.v868116049892; SSH launch requires verified server identity and least-privilege agent credentials.
• Official Jenkins inbound-agent images — reviewed lab image line jenkins/inbound-agent:3391.va_37fa_a_305d6d-2-jdk21. Pin a reviewed tag/digest for repeatable labs rather than using latest.
• Controller Isolation — keep the built-in node at zero executors and do not use controller-local builds as a connectivity workaround.
• Installing Jenkins — standalone Jenkins uses the supported Jetty/Winstone stack; WebSocket-agent support depends on a compatible servlet/proxy path.