netmiko-ssh-automation

Safe Python Netmiko patterns for read-only collection, bounded batch SSH, TextFSM parsing, guarded config changes, timeouts, and network automation error handling. Use when automating network device access with Python Netmiko, whether collecting state or pushing guarded config changes.

By affaan-m · 2,804 installs

npx skills add affaan-m/ecc --skill netmiko-ssh-automation

Source repository · Upstream listing

Netmiko SSH Automation Use this skill when writing or reviewing Python automation that connects to network devices with Netmiko. Keep the default path read only; config changes need a separate change window, peer review, and rollback plan. When to Use Collecting show command output across routers, switches, or firewalls. Building a small audit script for interface, routing, or config evidence. Adding timeouts and exception handling to network SSH scripts. Parsing command output with TextFSM when a template exists. Reviewing automation before it touches production devices. Safety Defaults Start with read only send command() collection. Keep inventory small and explicit; do not sweep whole address ranges. Use environment variables, a vault, or getpass ; never hardcode credentials. Set connection and read timeouts. Limit concurrency so older devices are not overloaded. Require an explicit operator flag before send config set() . Do not call save config() until the change has been verified and approved. Read Only Connection Pattern Use placeholder addresses from documentation ranges in examples. Keep real inventory in an ignored local file or a secrets managed system. Batch Collection Keep max workers low unless the device estate and AAA systems are known to handle higher connection volume. Structured Parsing Netmiko can ask TextFSM, TTP, or Genie to parse supported command output. Treat parser output as an optimization, not the only evidence path. If parsing drives a blocking decision, keep the raw command output alongside the parsed result so an operator can inspect mismatches. Guarded Config Pattern Saving the config is a separate approval step. In production, include a rollback snippet and capture before/after evidence in the change record. Review Checklist Does the script identify an explicit inventory source? Are credentials absent from source, logs, and exception messages? Are conn timeout , auth timeout , and command read timeout set? Are failures reported per device without stopping the whole batch? Does the script avoid broad scans and unbounded concurrency? Are config changes behind a dry run or explicit operator flag? Is save config() separate from the initial push and tied to verification? Anti Patterns Hardcoding passwords, enable secrets, or private keys in source. Sending config commands as the default code path. Running automation against a CIDR range instead of a reviewed inventory. Logging full running configs to shared systems without sanitization. Treating parser success as proof that the device state is correct. See Also Skill: cisco ios patterns Skill: network config validation Skill: network interface health