<< Click to Display Table of Contents >> Raynet One > 2026.2 > User Guide > Technical overview  Agentless Inventory Methods: Unix Zero Touch

Unix Zero Touch is an agentless, least-invasive inventory method in Raynet One Scan Engine for remote data collection from supported Unix platforms without installing any persistent agent on the target.

 

Supported Unix Operating Systems

 

The Unix Zero Touch inventory method is technically compatible with a wide range of Unix like operating systems as long as an OpenSSH server is available and reachable. However, Raynet One officially supports and recommends the use of currently maintained releases from major vendors. This ensures optimal compatibility and reliable inventory results in enterprise environments.

 

 

Older or non-listed versions may still provide functional inventory results via SSH; however, they are not part of the official support scope.

 

The Remote Inventory for Unix (RIU) component orchestrates the entire process via SSH:

•Initial platform fingerprinting and privilege probing

•Adaptive command execution based on detected OS and available privileges (Principle of Least Privilege)

•Application of defined Execution Contexts (No-Elevation, Elevated-First, etc.)

•Collection and return of normalized inventory data (hardware, software, configuration)

 

Key technical requirements:

•OpenSSH server running and reachable (port 22/TCP by default; custom ports configurable)

•Valid SSH login credentials (password or - recommended - SSH key authentication)

•For full inventory results (hardware, storage, services, containers, etc. ): the scan account must be allowed to run sudo commands without being prompted for a password.

•Without password-less sudo: automatic fallback to non-privileged commands (limited results).

 

The scan uses only native, universally available utilities and leaves no files or persistent changes on the target system.

 

 

Understanding Pseudo-Terminal (PTY) Allocation and PermitTTY Handling

 

All commands are executed over an SSH session. A Pseudo Terminal (PTY) is a virtual terminal device created by the target kernel under /etc/ssh/sshd_config to emulate a real physical terminal.

The Zero-Touch Unix scanner requests a PTY from the remote SSH server for reliable command execution (e.g. sudo password prompts). The remote SSH server decides whether or not to allocate a pseudo-terminal (PTY). When a PTY is granted, the scanner operates under optimal conditions. If the server refuses the PTY request, the scanner automatically continues in terminal-less NoVirtualTerminal mode through graceful degradation.

 

When PermitTTY is set to yes in /etc/ssh/sshd_config, the target server grants the requested PTY.

The kernel dynamically creates a virtual terminal device (e.g. /dev/pts/23 ) and the remote session receives a fully-featured terminal environment ($TERM = xterm-256color or similar). This is the intended and optimal state for Zero-Touch Unix scans.

 

The following live examples were executed on an internal test system (Ubuntu 24.4). The exact output (especially the PTY device number '/dev/pts/XX' and the concrete 'TERM' may vary depending on the target operating system, SSH server configuration, and currently active sessions. These examples are for illustration purposes only and do not guarantee identical results on scanned systems.

 

 

The optional instrument setting UseNoVirtualTerminal (default: disabled) is available in Raynet One at Configuration, Plugins, Unix Zero Touch Inventory, Instruments, Zero Touch Unix Device Scan, Settings. When the Use no virtual terminal checkbox is selected, the scanner forces terminal-less NoVirtualTerminal mode operation from the start, even when then target server would permit a PTY.

 

 

After changing the setting if desired, click Save to apply the configuration.

 

By default the setting is disabled, so the scanner first attempts a normal PTY connection and automatically falls back to NoVirtualTerminal mode through graceful degradation only if PTY allocation is refused (e.g. PermitTTY no in /etc/ssh/sshd_config). In this fallback case the scan continues with only minor limitations.

 

 

Regardless of whether a full PTY or terminal-less mode is used, the Zero-Touch Unix scan always relies exclusively on native, universally available system utilities and leaves no files or persistent changes on the target system.

This documentation reflects Raynet One Scan Engine 12.6+ behaviour (Dezember 2025). Individual environments (restricted shells etc.) may require adjustments.

 

Execution Context Overview

The scanner uses an intelligent Execution Context system to run every command with the minimum required privileges (Principle of Least Privilege). Each command is classified into an Execution Context.

The classification decides:

 

•Access Method: How the command reaches the target (always SSH command execution or script upload).

•Execution Method: How the command determines privilege elevation strategy (QuickRun, Run, RunTryElevatedFirst, RunTryElevatedLast, RunScript).

•Privilege Elevation: How elevated privileges (sudo) are attempted during execution (Without elevation/ Tried with elevation first/ Tried with elevation last).

 

The table below defines the Execution Contexts used throughout this documentation:

 

 

Important: Full inventory depth requires the scan account to have password-less sudo (NOPASSWD) for optimal hardware, storage, service, and container data collection. 

Without password-less sudo, the scanner automatically falls back to non-privileged execution using graceful degradation:

 

•RunTryElevatedFirst commands are executed without sudo - available data is collected with reduced detail

•RunTryElevatedLast commands attempt non-privileged execution first

•QuickRun and No-Elevation commands function normally (they never require elevation)

•The scan process continues uninterrupted, ensuring baseline inventory data is always collected even in highly restricted environments

 

File-Read is a behavioural flag applied only to No-Elevation (and very rarely Script-Execution) commands that access system files or directories. 

It never applies to Elevated-First or Elevated-Last contexts.

 

 

How the Scan Works

 

The Zero-Touch Unix scanner connects to each target system individually via SSH and executes the phases 0 through 8 in strict sequence on that system.

 

•Phase 0 determines the exact platform, architecture, and available privileges (sudo NOPASSWD or not).

•Phases 1-8 are executed adaptively: only commands that are applicable to the detected OS and permitted by the current privileges are run. Commands requiring unavailable privileges or non-existent binaries are silently skipped (Principle of Least Privilege).

•When Phase 8 is complete, results are returned, the SSH session is closed, and the scanner proceeds to the next target.

•Multiple targets are processed in parallel, with each scan instance executing its own independent Phase 0-8 sequence.

 

This fully automated, adaptive behaviour is the reason the solution is called Zero-Touch.

The phases described below are executed adaptively; commands are skipped or reordered when required by the target environment or available privileges.

 

Phase 0: Pre-Check & Capability Validation

Phase 0 is the mandatory, non-privileged first step of every Zero-Touch Unix scan. With one exception (uname -o on AIX/HP-UX, which is attempted with elevation when required ), all commands run under 

No-Elevation/ QuickRun.

In a few seconds it reliably determines:

 

•Exact OS family, version and architecture (uname flags)

•Current user identity and group membership (whoami, id)

•Whether password-less sudo elevation is available and whether the shell is restricted

 

The separate hostname command is not used; uname -n is preferred because it is universally available, strictly read-only and can be combined with the other uname flags in one call.

By the end of Phase 0, all information required for the adaptive, privilege-aware execution of Phases 1-8 is already available. All commands in Phase 0 run under No-Elevation context (QuickRun). The single exception

is uname -o on AIX/HP-UX when required (Elevated-First).

 

 

Phase 1: System Information

Phase 1 establishes the unambiguous identity of the target system and builds the foundation for all subsequent phases. All commands in this phase use No-Elevation (QuickRun or Standard-Execution) because the required information is publicly readable on every supported Unix platform, no sudo is ever requested.

 

The phase is divided into two logical parts:

Core System Identification:

The scanner determines the exact operating system family, release, architecture, hostname, domain, and virtualization context (zone/LPAR) using uname variants, normalized pipelines, platform-specific identifiers (zonename, lparstat -i, model, hostid), and the standard release files under /etc (/etc/os-release, /etc/redhat-release, etc. ).

 

Binary & Path Inventory:

The scanner enumerates all executable files in the standard system paths (/bin, /sbin, /usr/bin, /usr/sbin) and verifies their location, permissions, symlinks, and checksums using find, which, ls, readlink, md5sum, grep, awk, and sed.

This early inventory is critical: the scan process must know which tools are actually available before attempting hardware, storage, or container commands in later sections.

 

By the end of Phase 1, the scanner has a complete, reliable picture of who the system is and what standard tools it provides, all without requesting elevated privileges. All commands in Phase 1 run under No-Elevation

context.

 

 

Phase 2: Package Management

Only one package manager block is executed, the scan process automatically selects the appropriate one based on the normalized OS identifier determined in Phase 0/1 (e.g.,rpm on RHEL/CentOS/SUSE,  

dpkg on Debian/Ubuntu, swlist on HP-UX, pkginfo on Solaris, odmget on AIX, and snap/flatpak  where present). All package manager queries run under No-Elevation context.

 

 

Phase 3: Hardware Information

This is the first phase where Elevated-First (RunTryElevatedFirst) is used extensively, because tools such as dmidecode, lspci, smbios, prtdiag, and parts of prtconf require root-level access to 

low-level system information that is protected by the kernel.

If password-less sudo is unavailable, these commands are silently skipped and the scanner automatically falls back to non-privileged alternatives (lscpu, free -m, cat /proc/cpuinfo, etc.). Only 

cat /proc/cpuinfo and cat /etc/filesystems (AIX) explicitly access regular files [File-Read]. By the end of Phase 3, the scanner possesses a complete hardware fingerprint suitable for asset tracking, capacity 

planning, and warranty management.                                          

 

 

Phase 4: Storage Management

This phase enumerates mounted filesystems, block devices, physical volumes, logical volumes, and platform-specific disk structures using commands such as df, mount, lsblk, fdisk, lspv, zpool list, zfs list, ioscan, format, prtvtoc, diskutil, smartctl and udevadm. Most commands require Elevated-First due to restricted access to device nodes and raw disk information.    File-reading operations (e.g. cat /etc/filesystems on AIX) are marked [File-Read].

 

Phase 5: Network Configuration

This phase collects network interface configuration and routing information through the commands ifconfig, netstat -rn and ip addr show. All network commands run under Elevated-First context.

 

Phase 6: Process Management

This phase lists running processes and their arguments on all supported Unix platforms using the platform-specific ps variants, pargs and osacript.

 

Phase 7: Service Management

The scan identifies configured and active system services across all supported Unix platforms using the native service management frameworks (systemd, SysVInit, SMF, SRC and launchd). All service management commands run under Elevated-First context.

 

 

Phase 8: Container and Virtualization Inventory

The scan detects running containers, images, Kubernetes workloads, Solaris zones and Microsoft SQL Server instances through their respective management utilities.