Connect an on-premises server

Put an agent inside your network, verify a restricted SSH account and investigate host evidence.

How-to · Updated 2026-10-17 · Describes release 0.1.164

Before you start

This example uses a Linux server with OpenSSH and a private agent that can reach it over TCP 22. You need an AIOps owner or operator account, Docker or Kubernetes for the agent, and a server administrator to create the SSH account. Use your chosen SSH port if it differs.

Install and verify the private network agent first. A token alone does not install the container or give it host access.

1. Prepare the SSH identity

On your secure workstation, create a dedicated key. The command prompts for a new filename and refuses to overwrite one. Use an unencrypted key only because this connector cannot answer a passphrase prompt; protect it as a credential.

bash <<'BASH'
set -euo pipefail
umask 077
read -r -p 'New private-key filename (for example aiops-host-read): ' AIOPS_KEY_FILE </dev/tty
: "${AIOPS_KEY_FILE:?A new filename is required}"
test ! -e "$AIOPS_KEY_FILE" && test ! -e "$AIOPS_KEY_FILE.pub" || { printf 'Choose an unused filename.\n' >&2; exit 1; }
ssh-keygen -t ed25519 -N '' -C aiops-host-read -f "$AIOPS_KEY_FILE"
printf 'Give only %s.pub to the server administrator. Keep %s private.\n' "$AIOPS_KEY_FILE" "$AIOPS_KEY_FILE"
BASH

The server administrator creates a dedicated account, for example aiops-reader, and installs only the public key. The account should have no sudo, no application write permission and access only to the logs and host facts you intend to share. Follow your distribution's account-provisioning policy.

For a tightly limited first test, your administrator can use a forced-command wrapper that allows only uptime, df -h, free -m and uname -a. They must install the wrapper as root-owned and non-writable by the SSH account, and attach it to the public-key entry with restrict,command="/usr/local/bin/aiops-readonly-command". This is a server-side boundary; a username containing “read” is not one. OpenSSH authorized-key restrictions.

#!/bin/sh
case "$SSH_ORIGINAL_COMMAND" in
  uptime) exec /usr/bin/uptime ;;
  'df -h') exec /usr/bin/df -h ;;
  'free -m') exec /usr/bin/free -m ;;
  'uname -a') exec /usr/bin/uname -a ;;
  *) printf 'This SSH key allows only uptime, df -h, free -m and uname -a.\n' >&2; exit 1 ;;
esac

The wrapper intentionally limits discovery. Add reviewed, fixed read commands when needed, or use an existing read-only metrics/log API for richer evidence. Do not allow arbitrary shell text or add broad sudo rights.

2. Verify from the agent's network

From a machine on the same network path as the private agent, verify the host's SSH fingerprint with its administrator, then test uptime using the dedicated key. Fill the prompted values with your server details.

bash <<'BASH'
set -euo pipefail
read -r -p 'Host IP or DNS: ' AIOPS_HOST </dev/tty
read -r -p 'SSH port: ' AIOPS_PORT </dev/tty
read -r -p 'Dedicated SSH user: ' AIOPS_USER </dev/tty
read -r -p 'Private-key path on this machine: ' AIOPS_KEY_FILE </dev/tty
ssh -i "$AIOPS_KEY_FILE" -p "$AIOPS_PORT" -o BatchMode=yes -o ConnectTimeout=5 "$AIOPS_USER@$AIOPS_HOST" uptime
BASH

Expected result: the remote host's uptime and load. Fix network reachability, account authorization or the server's command restriction before continuing.

3. Connect and verify in AIOps

Open Data sources (in the product: /portal/datasources) → Connect datasource → SSH (remote host, read-only). Choose Investigate only. Enter the host, port, username and private-key contents. Add notes describing the allowed commands and the application on that host.

Select Connect and verify. Expected result: the private agent runs uptime successfully on that host. Its heartbeat alone does not prove the SSH connection works.

4. Follow the first incident

Run Estate x-ray (in the product: /portal/xray) within the available read permissions, use the reviewed context, then send a test alert. Open the incident: in this release an investigation, a chat turn and an estate x-ray refuse every SSH command, read commands included, so the host's measurements reach the agent through a metrics or log backend the host reports to (SSH → Read surface).

For network appliances, choose Network device instead of this Linux SSH recipe. Use the device's read-only privilege profile and SSH transport; Cisco and pfSense command privileges are managed on the appliance. For approved repairs, create a separate write connection and configure its exact action and target. Network-device actions use the Advanced configuration; keep that credential out of investigation access.

Compliance on premises: an SSH or network-device connection adds no compliance coverage. The cloud checks EST-01 to EST-06 and the scanner intake read cloud accounts only.

Next steps