Inventory Linux servers and appliances over SSH

Linux servers, hypervisor hosts and many appliances do not speak Windows management, but they do speak SSH. With one ordinary account, NetBlade logs in, reads what the machine is and which packages it runs, and remembers the server’s identity so a swapped machine cannot silently collect your password. This article covers what is read, the account to create, and the one safety mechanism you need to understand.

Before you start

• The Linux machines in Devices after a scan, with port 22 open (the port scanner or Identify will show it).
• Administrative access to each server, to create an account.
• The server’s SSH daemon listening on port 22: that is the port NetBlade connects to.

1. Know what NetBlade reads over SSH

From a Linux server or appliance, NetBlade reads:

• the host name;
• the operating system, from /etc/os-release, or the kernel name when that file is missing;
• the kernel version;
• the processor model and number of cores;
• total memory;
• installed packages, from dpkg (Debian, Ubuntu and derivatives) or rpm (Red Hat, Rocky, AlmaLinux, SUSE and derivatives);
• the server’s host key, which it remembers.

Over SSH nothing comes back about disks, users or defences. That is a limit of what NetBlade asks over this protocol, not of the device, and the card says so: «Read over SSH. A Linux or appliance host answers with its name, its kernel and its packages, and nothing about disks, users or defences.»

2. Create an ordinary account, no sudo

Every command NetBlade runs reads files and tools that any user can read: hostname, /etc/os-release, uname, /proc/cpuinfo, nproc, /proc/meminfo, and the package list with dpkg-query or rpm -qa. It never uses sudo and never needs root. Give it an account that cannot do more.

On a typical Linux server, as root or with sudo (general Linux administration, adapt to your distribution):

sudo useradd -m -s /bin/bash netblade
sudo passwd netblade

Do not add this user to sudo, wheel or any administrative group.

Note: NetBlade authenticates over SSH with a password. Key-based login is not supported. If your servers accept keys only, you must allow password login for this one account in the SSH daemon configuration. Weigh that against your policy, use a long unique password, and restrict the account as your standards require.

3. File the SSH credential

1. Open Credentials and press Add….
2. Set Protocol to Linux / SSH.
3. Type the user and the password.
4. In Where it applies, choose One site, or These scan scopes if your servers live in a range you saved with Keep this scope.
5. Label it, for example “Office A - Linux read-only”, and press File.
6. Type a server’s address in Machine to try and press Test. LAST TEST should say «Works».

SSH credentials are tried where port 22 has been seen open (or where no ports are known yet), after any Windows and SNMP credentials that apply.

4. Read the servers

1. Open Devices and press Deep inventory, or open one server’s card and press Deep scan.
2. The read status says «Read … via …».
3. The Software tab lists the installed packages with their versions.
4. Inventory, then Software, now includes those packages alongside Windows programs, so “who still runs this version?” works across both.

Tip: Packages count for vulnerability checks only when NetBlade’s dictionary can name them. On the Software page, Only what the dictionary can name shows which ones. A program the dictionary cannot name gets no vulnerability verdict anywhere in the app: silence is not safety.

5. Understand the host key check

The first time NetBlade connects to a server, it remembers the SHA-256 fingerprint of the server’s host key. On every later connection, if the key is different, NetBlade stops before sending the password and shows:

«The host key is not the one this device showed last time. Nothing was sent: either this machine was reinstalled, or something else is answering at its address.»

This protects your credential from a device that has taken over the server’s address, whether it was plugged into the network by mistake or put there on purpose.

When you see it:

1. Find out why. Was the server reinstalled, replaced, or its address given to another machine?
2. If you cannot explain it, treat it as a security incident, not a glitch.
3. If the change is legitimate, clear the old reading so the new key can be accepted. In this version, the way to do that is to delete the device: in Devices, press Select, tick it, and press Delete. It leaves the catalog with everything read from it and its history, and comes back as new at the next scan. Then read it again.

6. Appliances with their own shell

Many appliances (firewalls, some switches, NAS menus) accept an SSH login but answer with their own command-line interface rather than a Linux shell. NetBlade bounds every command with a timeout, so the read does not hang, but little or nothing comes back. For those devices, SNMP is the better protocol: see SNMP.

Check that it worked

• The server’s card says «Read … via …» and shows system, kernel, processor, cores and memory.
• The Software tab lists packages.
• On the Dashboard, Machines read includes the servers.

If something goes wrong

• «SSH refused the connection or the credentials». Wrong user or password, the account is locked, or the server does not accept password login for it. Try the same login from a terminal to see which.
• No packages listed. NetBlade reads only dpkg and rpm. Distributions with other package managers get the system details but no package list.
• The server listens on a port other than 22. NetBlade connects on port 22 only.
• The host key message appears after a planned reinstall. Expected. Follow step 5.
• Nothing about disks or users. Not read over SSH, by design.

Next

With PCs, network gear and servers read, draw how they are wired: Build the network map.

← All how-to guides Feature guide → The product: NetBlade Windows →