Linux - Security - Install SentinelOne Agent

What the SentinelOne Linux deployer does

This Automox Worklet™ deploys the SentinelOne endpoint detection and response (EDR) agent to Linux endpoints, regardless of whether the host uses an RPM or DEB package manager. The Worklet checks for an existing sentinelctl binary, detects the installer family on the endpoint, and installs the .rpm or .deb package you staged on the policy. It then registers the running agent with your SentinelOne management console using a site token.

After the package install completes, the Worklet writes the site token through sentinelctl management token set and starts the agent service with sentinelctl control start, both called from /opt/sentinelone/bin/. The endpoint then registers as a managed asset, begins streaming telemetry, and starts enforcing the policy assigned to it in the SentinelOne console.

When sentinelctl version already exits 0, the Worklet treats the endpoint as compliant and skips remediation. The policy works as both initial deployment and continuous coverage check for hosts that get reimaged, restored from a snapshot, or rebuilt by a config-management tool, with no extra package downloads on endpoints that already pass.

Why deploy SentinelOne with a Worklet

Linux endpoints in most fleets host high-value workloads: web tier hosts, build servers, CI runners, Kubernetes nodes, jump hosts, and developer workstations. Every Linux host that is missing the SentinelOne agent represents a gap in EDR coverage that often goes undetected until an incident surfaces it. The standard manual workflow SSHs into the host, copies the installer, runs rpm -i or dpkg -i, pastes the site token, and starts the service. That workflow does not scale to a thousand-host fleet and does not survive reimage.

Apply this Worklet to your Linux server, container host, and developer workstation endpoint groups so the package install, the sentinelctl token registration, and the service start run as one policy. The Automox agent applies that policy on schedule across RHEL, CentOS, Rocky, Alma, Fedora, Debian, and Ubuntu hosts in a single deployment window.

How SentinelOne agent deployment works

1. Evaluation phase: The evaluation script runs sudo sentinelctl version and inspects the exit code. Exit 0 means the SentinelOne agent is installed and the sentinelctl binary is responsive, so the endpoint is reported compliant and remediation is skipped. A non-zero exit or a missing sentinelctl on PATH flags the endpoint for remediation. The check completes in under a second, so a recurring policy can sit alongside the rest of your EDR-coverage Worklets without operational cost.

2. Remediation phase: The remediation script re-checks sentinelctl version and exits early if the agent is already present. Otherwise it detects the package manager using command -v dpkg and command -v rpm. On Debian and Ubuntu hosts it runs sudo dpkg -i against the staged .deb file referenced by the deb_filename variable; on RHEL, CentOS, Rocky, Alma, and Fedora hosts it runs sudo rpm -i --nodigest against the .rpm referenced by the rpm_filename variable. After install, the script calls sudo /opt/sentinelone/bin/sentinelctl management token set <site_token> to register the agent with your SentinelOne console, then sudo /opt/sentinelone/bin/sentinelctl control start to bring the agent up. A non-zero exit anywhere in the chain surfaces in the Automox activity log so failures do not go silent.

SentinelOne Linux deployment requirements

• Linux endpoint running a SentinelOne-supported distribution: RHEL, CentOS, Rocky, Alma, Fedora, Debian, or Ubuntu, with either rpm or dpkg available on PATH

• Both installer packages staged with the Worklet: the SentinelAgent_linux_*.rpm file for RPM hosts and the SentinelAgent_linux_*.deb file for DEB hosts, downloaded from your SentinelOne console at the version that matches your site policy

• A valid site token from the SentinelOne console (Settings → Sites → your site → Site Token), pasted into the site_token variable in remediation.sh

• Root privileges for the Automox agent on the target endpoint (the default Automox agent context already runs as root on Linux, and the scripts call sudo for each privileged step)

• Network reachability from the endpoint to the SentinelOne management console URL so that sentinelctl can complete registration and begin reporting

• Confirm the deb_filename, rpm_filename, and site_token variables in remediation.sh before the first run; a missing or stale site token is the most common cause of a failed registration

Expected state after SentinelOne deployment

After successful remediation, sentinelctl version returns the installed agent build, the SentinelOne service runs under /opt/sentinelone/, and the endpoint appears in the SentinelOne management console under the site that issued the token. The agent begins reporting process telemetry, file events, and network connections to SentinelOne. Any policy assigned to the site – detection, prevention, or response – takes effect on the host within the SentinelOne console refresh interval.

You can confirm the deployment three ways. Re-run the Automox evaluation policy and watch the endpoint flip to compliant. Run sentinelctl version directly on the host over SSH. Or filter the SentinelOne console for the new hostname and check that the last-seen timestamp is current. Subsequent Automox runs find sentinelctl present and exit 0 without applying remediation again, so the policy is safe to leave on a recurring schedule as ongoing coverage for reimaged or restored hosts.