Target Host Requirements

Before you add hosts to a cluster, make sure each Target Host meets the requirements below. IDSTower checks most of them itself when you submit the first step of the Cluster Setup Wizard, and tells you which host failed and why — but knowing them up front saves a round trip.

Operating system

CentOS Stream 9/10, RHEL 8/9/10, RockyLinux 8/9/10, AlmaLinux 8/9/10, Oracle Linux 8/9/10, Ubuntu 22/24/25/26, Debian 12/13, Kali Linux (rolling) and Raspberry Pi OS (64-bit).

Windows, macOS, Alpine Linux and MikroTik RouterOS are not supported as Target Hosts, and pfSense and OPNsense are not supported for a Fresh Installation. For a Fresh Installation with the Official Repository option, a Linux distribution derived from Debian or Red Hat that is not listed above may still work, because IDSTower falls back to a generic set of steps when it does not recognise the distribution, but it is not supported. To bring a host that already runs Suricata under IDSTower’s management instead, see Onboard Existing Suricata.

Python 3 must be present. Every supported distribution ships it in a default installation, so this is only a concern on a deliberately minimised image.

Network

  • IDSTower must be able to reach the host over SSH.

  • The host must be able to reach the IDSTower API URL over HTTP/HTTPS. Managed hosts pull their rules and indicators from IDSTower on a schedule and post their health heartbeat back, so this is a standing requirement, not just a setup-time one. If you use an FQDN, it must resolve from the Target Host.

  • The host must be able to reach whichever package repository you selected for Suricata and Filebeat, unless you are installing from the Built-In or a User-Custom repository.

SSH account

IDSTower needs an account that can install packages, write configuration under /etc and manage systemd services. Two kinds of account satisfy that:

root

Nothing else is required. A root login does not need sudo to be installed on the host.

A user with passwordless sudo

sudo must be installed, and the user must be able to run it without being prompted for a password.

Note

When you register a host using an SSH password, IDSTower sets the user up for you: it uses that password to answer sudo’s own prompt, and then adds a block to /etc/sudoers marked # BEGIN/END Section Automatically Added by IDSTower. From then on the per-cluster SSH key is used and no password is needed again. So a user whose sudo currently asks for a password is fine here.

When you supply your own SSH key, IDSTower has no password to answer that prompt with — and writing to /etc/sudoers itself requires elevation. It can therefore only elevate if the account can already run sudo without a password, in which case there is nothing left for it to add. A user whose sudo still asks for a password cannot be set up over key authentication: grant them passwordless sudo first, or register the host with a password.

If neither applies, the wizard stops at the verification step and tells you which of the two is missing: that sudo is not installed, or that the user is not allowed to run it.

Note

A stock Debian installation does not include sudo when you set a root password during setup — Debian’s default is the root + su model. On such a host, use the root account; installing sudo only to satisfy IDSTower is not necessary.

Granting passwordless sudo

Only needed when you register the host with your own SSH key and the account is not root — in every other case IDSTower either does not need sudo at all, or sets this up for you.

Run these on the target host as root. This is an account you already have — IDSTower does not create one, and the name does not matter to it. Replace [Username] below with that account’s name; the file name idstower is used as-is, so it is obvious later what the rule is for.

  1. Make sure sudo is installed:

    # Debian / Ubuntu
apt-get update && apt-get install -y sudo

# RHEL, Rocky, AlmaLinux, Oracle Linux, CentOS Stream
dnf install -y sudo

  2. Create a drop-in rule for the account. Use visudo rather than a text editor: it refuses to save a file with a syntax error, and a broken /etc/sudoers locks everyone out of sudo.

    visudo -f /etc/sudoers.d/idstower

    Put a single line in it:

    [Username] ALL=(ALL) NOPASSWD: ALL

  3. Fix the permissions — sudo ignores a drop-in file that is group- or world-writable:

    chmod 0440 /etc/sudoers.d/idstower

  4. Verify, as that user. sudo -n never prompts, so it fails rather than hanging if the rule did not take:

    sudo -n true && echo "passwordless sudo OK"

Note

Adding the account to the sudo group (Debian/Ubuntu) or wheel group (RHEL-family) is not enough on its own. Those groups grant the right to run sudo, but still prompt for the user’s password, which is exactly what IDSTower cannot answer when it authenticates with a key. The NOPASSWD rule above is what removes the prompt.

Warning

Name the drop-in file without a dot or a tilde in it — sudo silently skips files in /etc/sudoers.d whose names contain . or end in ~, so idstower.conf would be ignored and the grant would appear not to work.

Root logins and sshd

Debian and Ubuntu ship PermitRootLogin prohibit-password, which permits root over SSH by key but not by password. So:

  • root with an SSH key works against a stock sshd_config. Nothing to change.

  • root with a password requires PermitRootLogin yes in /etc/ssh/sshd_config on the target, followed by a restart of the SSH service.

Choosing SSH key authentication in the wizard is therefore the path of least resistance on those distributions.

What IDSTower installs on the host

Beyond the IDS software itself, IDSTower installs a small set of packages it needs to manage the host — curl, rsync, cron (crontabs/cronie on RHEL-family), lsof, iproute2, findutils and util-linux. These are pulled from the host’s own package manager, so the host needs access to its distribution repositories the first time a cluster is deployed to it.

It also adds its own SSH key to the account’s authorized_keys. IDSTower generates a unique key pair per cluster and uses it for all later management tasks, so the credentials you type into the wizard are used once and never stored.