CLI Over HTTPS Part 4: Where Do We Go from Here?

brett@network-notes.com (Brett Lykins) — Thu, 07 May 2026 09:00:00 +0000

This is the last post in the series. Part 1 explained why SSH is slow for automation. Part 2 measured it. HTTPS batch is up to 17x faster at real-world latencies. Part 3 showed that an edge proxy and a transparent tunnel capture most of that improvement even when devices don’t speak HTTPS natively.

This post is the practical takeaway: when to use what, how to deploy it, and what the industry should build next.

The Decision Framework

Not every network needs a proxy. Not every automation run is latency-sensitive. Here’s how to think about it:

SSH Direct Is Fine When

Your automation server is co-located with the devices (same DC, same site)
Round-trip time to the devices is under ~5ms
You’re managing fewer than a few hundred devices
You’re already using SSH multiplexing (ControlMaster) or persistent connections

At local latency, SSH overhead is measured in single-digit milliseconds. The protocol tax from Part 1 is real but negligible. Don’t add architectural complexity to save 3ms per device.

Deploy a Proxy When

Your automation runs over a WAN (30ms+ RTT to the devices)
You manage devices across multiple sites, regions, or continents
Automation run time is operationally painful (the Rackspace problem from Part 1)
You’re already running regional infrastructure (jump hosts, bastion servers, Ansible Tower nodes)
You can modify your automation to speak HTTPS instead of SSH

The proxy pattern from Part 3 showed 5.3-14.7x improvement at real WAN latencies (14.7x with connection reuse at 150ms RTT). If you already have bastion hosts in each region, you’re halfway there. The proxy is a bastion that speaks HTTPS instead of (or in addition to) SSH.

Deploy a Tunnel When

You need WAN optimization but can’t change your automation tooling
Your team has years of Ansible playbooks, Nornir scripts, or Netmiko wrappers that must speak SSH
You want a migration path: tunnel first, proxy later

The tunnel from Part 3 is transparent to both sides: automation speaks SSH to the headend, the device sees SSH from the site proxy. With command batching, it hits 12.7x speedup at intercontinental latency. Without batching, it’s still 3.0x faster than SSH direct.

Deploy NAAS When

You want a production-ready proxy with multi-vendor support out of the box
You need connection pooling, async jobs, and circuit breakers
You manage devices across 100+ platforms (everything Netmiko supports)

NAAS (Netmiko as a Service) implements the proxy pattern with production concerns handled. Deploy an instance per region, point your automation at it, and the SSH stays local. More on NAAS below.

Push for Native HTTPS When

You’re evaluating new platforms or vendors
You have influence over vendor roadmaps (large deployments, design partners)
You’re building internal tooling that could expose CLI over HTTPS

Native HTTPS eliminates the proxy entirely. The ~17x batch improvement from Part 2 is the ceiling. No intermediate hop, no backend SSH overhead. If a vendor offers it, use it.

NAAS: The Production Proxy

NAAS (Netmiko as a Service) is what the proxy pattern looks like when you build it for production. Written in Python, it wraps Netmiko behind a REST API, which means it supports 100+ device platforms: Cisco IOS, NX-OS, ASA, Juniper Junos, Arista EOS, Palo Alto, and everything else Netmiko handles.

You POST a JSON payload with the device address, platform, credentials, and commands. NAAS opens the SSH session, runs the commands, and returns the output in the HTTP response:

1
2
3
4


curl -k -X POST https://naas.dc1.example.com:8443/v1/send_command \
 -u "automation:token" \
 -H "Content-Type: application/json" \
 -d '{"host": "10.1.1.1", "platform": "cisco_ios", "commands": ["show version", "show ip route"]}'

What NAAS handles that a minimal proxy doesn’t:

Multi-vendor connection pooling. Persistent SSH connections with health checks and automatic reconnection.
Async job queue. Long-running commands (show tech-support, bulk config pushes) run in a Redis-backed queue. Your automation gets a job ID back immediately and polls for results.
Circuit breaker and observability. Stops hammering unreachable devices, exposes Prometheus metrics for connection pool health and per-device latency.

Deploy a NAAS instance in each data center or region, and your automation talks HTTPS to the nearest one. The SSH sessions stay local. The architecture is the same as what the benchmarks in Part 3 measured: HTTPS over the WAN, SSH on the last hop.

1
2
3
4
5
6


git clone https://github.com/lykinsbd/naas.git && cd naas
docker compose up -d
curl -k -X POST https://localhost:8443/v1/send_command \
 -u "username:password" \
 -H "Content-Type: application/json" \
 -d '{"host": "10.1.1.1", "platform": "cisco_ios", "commands": ["show version"]}'

See the NAAS getting started guide for full setup and configuration.

What Exists and What’s Missing

Some of the pieces are already in place.

Arista’s eAPI accepts CLI commands via JSON-RPC over HTTPS. It wraps everything in JSON, but the core pattern is there: send commands over HTTPS, get output back. The ASA interface and eAPI have been in production for years. NAAS (described above) brings the proxy pattern to the 100+ platforms Netmiko supports. The clibench tunnel mode demonstrates the transparent SSH-to-HTTP approach for teams that can’t change their automation tooling.

What’s missing:

A standard CLI-over-HTTPS interface. Not RESTCONF, not gNMI. Those are structured data interfaces for a different use case. A simple, standardized way to send CLI commands over HTTPS and get text output back. The ASA pattern is a reasonable starting point: GET /cli/exec/{command} for show commands, POST /cli/config for configuration. Basic auth or token auth over TLS. Content-Type: text/plain. No JSON wrapping unless the client asks for it. Arista’s eAPI is the closest thing to this, but it’s vendor-specific and JSON-only.

Proxy support in the automation ecosystem. Ansible could ship a connection plugin that talks HTTPS to a proxy like NAAS instead of SSH to the device. Nornir could support an HTTP transport alongside Paramiko and Netmiko. NAAS works today as a standalone API, and a native connection plugin would make adoption even easier: a configuration option instead of a code change.

Broader vendor adoption. Every network OS already has an HTTPS server for its web UI. Exposing the CLI through that same server is not a large engineering effort. The ASA proves the concept. A plain-text CLI endpoint alongside the structured API would cover both use cases.

None of this requires abandoning SSH. SSH remains the right tool for interactive sessions, for out-of-band recovery, for environments where HTTPS infrastructure doesn’t exist. The argument isn’t “replace SSH.” It’s “stop using SSH for the thing it’s worst at.”

The Numbers, One More Time

For reference, here’s the speedup picture from the series. Most automation tools (Netmiko, Ansible, Scrapli) use PTY mode, so SSH PTY is the realistic baseline:

Scenario	Speedup vs SSH PTY
HTTPS batch (native)	~17x
Proxy (reused connection)	~14.7x
Tunnel batch	~12.7x
Proxy (new connection)	~5.3x
HTTPS keep-alive (native)	~3.4x
Tunnel per-command	~3.0x
SSH with ControlMaster	~1.7x

The proxy with connection reuse gets you most of the native HTTPS improvement without requiring any changes to the devices. The tunnel with batching is close behind, and requires zero changes to your automation tooling either.

Try It Yourself

The benchmark tool supports all scenarios:

1
2
3
4
5
6
7
8


# All transports (SSH, HTTPS, HTTP/3, proxy, tunnel)
sudo ./bin/clibench bench --latency regional --iterations 20 --commands 5

# Proxy pattern (HTTPS + HTTP/3 variants)
sudo ./bin/clibench bench --latency regional --iterations 20 --commands 5 --transport proxy

# Tunnel (transparent SSH-to-HTTP WAN optimization)
sudo ./bin/clibench bench --latency intercontinental --iterations 20 --commands 5 --transport tunnel-https

The code is MIT licensed. Run it on your own infrastructure, with your own latency profiles, and see what the numbers look like for your network.

My take: The network automation community has treated SSH as a given for fifteen years. It was the right default when automation meant one engineer scripting against a handful of devices. At the scale most organizations operate today, SSH’s protocol overhead is a measurable, avoidable cost. Native HTTPS CLI is the right long-term direction. The proxy and tunnel patterns are deployable today. I built NAAS so you can start today. Contributions welcome.

Industry on network-notes