Ansible Guide: Breaking Cisco's Switch One-Command SSH Limit on Switches

When automating tasks in network environments, one often encounters roadblocks that challenge our patience and creativity. For those of us working with Cisco devices, one such hurdle is the restrictive nature of cisco switch single SSH commands in Ansible. This limitation can lead to a frustrating number of workarounds, particularly when you need to run multiple commands sequentially in cisco switch within a single SSH session. In this article, I’ll dive into some proposed solutions for tackling this issue, as well as the approach I chose to implement—a custom Ansible module that maintains efficiency without sacrificing functionality.

Proposed Solutions

Solution 1: Modifying Ansible Code Directly

The first workaround is to simply modify Ansible code to handle multiple SSH commands by repeating SSH connection logic for each command in cisco switch. Essentially, if you need to run five commands, you would create five separate SSH connection segments within the code. This approach is far from ideal, but I ve seen it in some Ansible codebases online, often justified by teams under strict security policies.

While this solution works in a pinch, it’ highly inefficient, especially when scaled up. Repeating code introduces maintenance headaches, and each SSH connection incurs additional overhead, slowing down the entire process. This “brute-force” approach is only recommended when absolutely necessary.

Solution 2: Using tmux to Manage Multiple Commands

Another possible solution is using tmux in conjunction with Ansible to manage multiple commands within different sessions over a single SSH connection. With tmux, you could theoretically open several “panes” or “windows” in one SSH session, allowing multiple commands to run concurrently. While I haven’t tested this setup myself, I have thought about how tmux could be adapted for this use case. The challenge lies in seamlessly integrating tmux sessions within Ansible playbooks and handling output capture in a structured manner.

Although this option could reduce SSH connections, it would require some creative Ansible-tmux configurations and wouldn’t be as straightforward to maintain.

Solution 3: Writing a Custom Ansible Module

The third solution—and the one I opted for—was to write a custom Ansible module that handles multiple commands in a single SSH session using Netmiko and other SSH libraries. This approach allows for a much cleaner and more efficient codebase. By crafting a custom module, I can capture multiple command outputs in one session without repetitive code, while maintaining flexibility and control over the SSH connection.

Implementing the Custom Module

After weighing the pros and cons, I chose to implement the custom module solution. With the approval of my Cisco security team, I built a module that opens a single SSH connection but can handle multiple commands in sequence or parallel, capturing the output of each command as needed. This method keeps Ansible playbooks clean and free of repetitive SSH connection code, as the custom module encapsulates the SSH logic which doing multiple ssh session for multiple command.

Additionally, because I have control over the module’s functionality, I tailored the output capture to align with Cisco’s native command output format. This design choice is particularly useful because it eliminates the need for extensive regex filtering when parsing JSON resuts. The raw output from the Cisco device is stored as-is, which can be processed later or emailed directly as a report. (I love this part it’s nice right.)

Why Output Formatting Matters

Maintaining Cisco's original output format reduces the hassle of commplex regex filtering—a notorious time sink for network devops engineers working with parsed JSON data. Without needing to handle difficult \r and \n characters, this approach keeps the data clean and easy to process. It also makes it more intuitive when referring back to captured logs or when further data processing is required.

Final Thoughts

Breaking through the single SSH command limitation in Ansible required a bit of experimentation and a willingness to think outside traditional workflows. By writing a custom module, I was able to streamline the command execution process while keeping output formatting straightforward. This solution not only improves efficiency but also offers greater control and modularity when automating Cisco device configurations and queries with Ansible.

If you’re struggling with similar challenges in your automation workflow, I hope this guide has provided some helpful insights. In the end, the key takeaway is that sometimes, the best solutions lie in building custom tools/module that fits your specific need.