Netshot on Ubuntu 24.04 on Azure User Guide

Overview

Netshot is an open-source network configuration, inventory and compliance-management platform by NetFishers. It periodically connects to your network devices to back up their running configurations, keeps a full change history so you can diff and audit every modification, maintains a live inventory of hardware and software, and continuously checks each device against configuration and software-version compliance rules. It ships more than a hundred device drivers covering Cisco IOS, NX-OS, IOS-XR and ASA, Juniper, Arista, Fortinet, HPE, Nokia and many other vendors, and detects changes in near real time from Syslog messages and SNMP traps.

The cloudimg image installs Netshot 0.24 under a dedicated non-root netshot service user on the Oracle GraalVM Java runtime that Netshot requires to execute its polyglot device drivers, backed by a local PostgreSQL database that stores the inventory, configuration snapshots, compliance results and users. Netshot's embedded Jetty server serves the web UI and the full REST API over HTTPS on port 443. The netshot service user binds the privileged port via the CAP_NET_BIND_SERVICE capability, so no reverse proxy is required.

Netshot ships with a single built-in administrator account whose default password is publicly documented. Because Netshot holds privileged access to your network devices, this image is secure by default: on the first boot of every deployed VM a one-shot service rotates the built-in admin password to a unique per-VM value, rotates the PostgreSQL role password, rotates the credential-encryption key that protects device secrets at rest, and regenerates a fresh per-VM self-signed TLS certificate — all before the web port accepts traffic. The per-VM administrator password is written to /root/netshot-credentials.txt with mode 0600, so no two VMs share credentials. Backed by 24/7 cloudimg support.

What is included:

• Netshot 0.24 (/usr/local/netshot/netshot.jar) run as the non-root netshot user on the Oracle GraalVM JDK 21 runtime
• The embedded Jetty web UI and REST API served over HTTPS on port 443, with a self-signed certificate you can replace with your own
• A local PostgreSQL as Netshot's backing database (inventory, configuration snapshots, compliance results, users)
• Syslog (UDP/1514) and SNMP-trap (UDP/1162) change-detection listeners enabled
• Secure by default: the built-in admin password, the database password, the credential-encryption key and the TLS certificate are all rotated/regenerated per VM on first boot; the default login is neutralised
• Per-VM admin password written to a root-only file
• netshot.service and postgresql.service as systemd units, enabled and active
• 24/7 cloudimg support

Prerequisites

An active Azure subscription, an SSH key pair, and a VNet + subnet in the target region. Standard_B2ms (2 vCPU / 8 GiB RAM) is the recommended starting point — Netshot runs a GraalVM JVM (Jetty, Hibernate and the polyglot driver engine) alongside a local PostgreSQL server, so it benefits from memory headroom. NSG inbound: allow 22/tcp from your management network and 443/tcp from the networks your operators will reach the Netshot console on. If you want Netshot to detect changes in near real time, also allow 1514/udp (Syslog) and 1162/udp (SNMP traps) from your devices.

Step 1 — Deploy from the Azure Marketplace

Sign in to the Azure Portal, choose Create a resource, search the Marketplace for Netshot by cloudimg, and select Create. On Basics pick your subscription, resource group, region and size; under Administrator account choose SSH public key and paste your key; under Inbound port rules allow SSH (22) and HTTPS (443). Then Review + create → Create.

First-boot initialisation takes approximately one to two minutes after the VM starts — Netshot runs its database migrations, rotates the built-in admin password, regenerates the TLS certificate and starts the embedded web server.

Step 2 — Deploy from the Azure CLI

az vm create \
  --resource-group <your-rg> \
  --name netshot \
  --image <marketplace-image-urn> \
  --size Standard_B2ms \
  --admin-username azureuser \
  --ssh-key-values ~/.ssh/id_ed25519.pub \
  --vnet-name <your-vnet> --subnet <your-subnet> \
  --public-ip-sku Standard

az vm open-port --resource-group <your-rg> --name netshot --port 443 --priority 1010

Step 3 — Connect to your VM

ssh azureuser@<vm-public-ip>

Step 4 — Confirm the services are running

systemctl is-active postgresql netshot
curl -sk https://127.0.0.1/api/cluster/masterstatus

Both services report active, and the unauthenticated masterstatus endpoint returns JSON, confirming the embedded HTTPS server is up:

active
active
{"clusterEnabled":false,"master":true,"currentMasterId":null}

On the very first boot allow a minute or two for the database migration and the web-server start before the endpoint responds.

Step 5 — Retrieve your administrator login

Netshot's built-in admin password is rotated to a value unique to your VM on first boot and written to a root-only file:

sudo cat /root/netshot-credentials.txt

NETSHOT_USERNAME=admin
NETSHOT_ADMIN_PASSWORD=<generated-per-VM>
NETSHOT_URL=https://<vm-address>/

The NETSHOT_ADMIN_PASSWORD value is your sign-in password; the username is admin.

Step 6 — First sign-in

Open a web browser and navigate to https://<vm-public-ip>/. The image ships with a self-signed certificate, so your browser will warn on the first visit — proceed past the warning (and replace the certificate with your own trusted one, below). Sign in with the username admin and the password from /root/netshot-credentials.txt.

The Netshot sign-in page, with the per-VM administrator password already rotated at first boot.

Step 7 — Secure by default

Because Netshot holds privileged access to your devices, the image ships with no usable default credential. You can confirm the rotation from the shell: the publicly documented default password netshot is rejected, while the per-VM password from the credentials file authenticates.

PASS=$(sudo grep '^NETSHOT_ADMIN_PASSWORD=' /root/netshot-credentials.txt | cut -d= -f2-)
curl -sk -o /dev/null -w 'default password: HTTP %{http_code}\n' -X POST -H 'Content-Type: application/json' \
  --data '{"username":"admin","password":"netshot"}' https://127.0.0.1/api/user
curl -sk -o /dev/null -w 'per-VM password: HTTP %{http_code}\n' -X POST -H 'Content-Type: application/json' \
  --data "{\"username\":\"admin\",\"password\":\"$PASS\"}" https://127.0.0.1/api/user

default password: HTTP 401
per-VM password: HTTP 200

The 401 for the built-in default and 200 for the per-VM password prove the first-boot rotation. The database password, the credential-encryption key and the TLS certificate are rotated in the same way on first boot.

Step 8 — Explore the console

After signing in, the Reports view is your home page. From the top navigation you reach Devices (the inventory), Diagnostics, Compliance, Tasks and Admin. The Reports view gives you configuration-change tracking, device-access-failure reports, configuration and software compliance, hardware end-of-life status and data export.

The Reports view is the console home page, summarising configuration changes, compliance status and hardware lifecycle across the estate.

Step 9 — Add your first device

Open the Devices tab. A fresh appliance starts with an empty inventory. Use Add device… to add a single device by management IP, or Scan subnet(s) for devices to discover a whole subnet, then supply the SNMP and CLI (SSH/Telnet) credentials Netshot should use under Admin → Credentials. Netshot takes an initial configuration snapshot, then re-snapshots on a schedule and whenever a Syslog or SNMP-trap change signal arrives.

The Devices inventory — add a device by IP or scan a subnet, then Netshot backs up and tracks each device's configuration.

Step 10 — Compliance policies

Open the Compliance tab to define Software rules (which OS versions each device family may run) and Hardware rules (end-of-sale / end-of-life milestones), and use Create policy… to build configuration-compliance policies whose rules are evaluated against every device's configuration. The results feed the Configuration- and Software-compliance reports on the Reports view.

Compliance — define the software versions and configuration standards devices must meet; Netshot flags every device that drifts.

Step 11 — The REST API

Everything in the web UI is backed by Netshot's REST API, so you can drive it from scripts and automation. Authenticate with a session cookie (or generate an API token under Admin → API Tokens), then call the API:

PASS=$(sudo grep '^NETSHOT_ADMIN_PASSWORD=' /root/netshot-credentials.txt | cut -d= -f2-)
J=$(mktemp)
curl -sk -c "$J" -o /dev/null -X POST -H 'Content-Type: application/json' \
  --data "{\"username\":\"admin\",\"password\":\"$PASS\"}" https://127.0.0.1/api/user
echo -n 'devices in inventory: '; curl -sk -b "$J" -H 'Accept: application/json' https://127.0.0.1/api/devices | jq 'length'
echo -n 'built-in device drivers: '; curl -sk -b "$J" -H 'Accept: application/json' https://127.0.0.1/api/devicetypes | jq 'length'
rm -f "$J"

devices in inventory: 0
built-in device drivers: 43

The empty inventory and the bundled device-driver families confirm the API is serving. The interactive API browser is available from the Help → API Browser menu in the console.

Installing a trusted TLS certificate

The image serves HTTPS with a per-VM self-signed certificate. For production, replace it with a certificate from a CA your operators trust. Netshot reads its certificate from a PKCS#12 keystore referenced in /etc/netshot.conf (netshot.http.ssl.keystore.file and netshot.http.ssl.keystore.pass). Import your certificate and private key into a new keystore, point those two settings at it, and restart Netshot:

# Build a PKCS#12 keystore from your PEM certificate + key (run where you hold them):
openssl pkcs12 -export -inkey privkey.pem -in fullchain.pem \
  -out /usr/local/netshot/netshot.pfx -passout pass:<your-keystore-password>
sudo chown netshot:netshot /usr/local/netshot/netshot.pfx
# Set netshot.http.ssl.keystore.pass in /etc/netshot.conf to <your-keystore-password>, then:
sudo systemctl restart netshot

You can also front Netshot with your own reverse proxy for TLS termination; set netshot.http.ssl.enabled = false and netshot.http.trustxforwardedfor = true in /etc/netshot.conf in that case.

Backup and maintenance

Netshot keeps all of its state — the device inventory, configuration snapshots, compliance results, tasks and users — in its PostgreSQL backing database, and the binary configuration snapshots under /var/local/netshot. Back both up regularly:

sudo -u postgres pg_dump netshot01 > /tmp/netshot-db-$(date +%F).sql

Ship the dump and /var/local/netshot to Azure Blob Storage or another object store, or snapshot the OS disk in Azure for a coordinated point-in-time backup. Keep the OS patched with sudo apt update && sudo apt upgrade. To upgrade Netshot itself, follow the vendor upgrade guide for your target version, always taking a database backup first; Netshot migrates its schema automatically on the next start.

Support

This image is backed by 24/7 cloudimg support. Contact us by email and chat for help with deployment, device-driver selection, compliance-rule authoring, Syslog and SNMP-trap change detection, TLS certificates and database administration. Contact support@cloudimg.co.uk.

For general Netshot questions consult the documentation at https://github.com/netfishers-onl/Netshot/wiki. Netshot is a trademark of NetFishers. All product and company names are trademarks or registered trademarks of their respective holders. Use of them does not imply any affiliation with or endorsement by them.