Navigating the Telnet Frontier: Mastering Legacy Protocol Automation with Ansible

In the rapidly evolving landscape of modern infrastructure automation and DevOps methodologies, the integration of legacy communication protocols remains a critical operational challenge. Telnet, operating primarily on TCP port 23, represents a foundational yet antiquated mechanism for remote device management. While Secure Shell (SSH) dominates contemporary network administration, numerous legacy hardware components, network switches, and virtualization environments—such as GNS3 and EVE-NG emulation platforms—lack cryptographic capabilities, necessitating the continued use of Telnet. Automating interactions with these devices requires deep architectural comprehension of how the Ansible framework interfaces with raw socket connections, navigates interactive prompt-based authentication, and manages cryptographic security standards. The successful deployment of Telnet automation hinges on precise configuration of inventory files, rigorous handling of Python type mismatches within core action plugins, and the implementation of enterprise-grade credential encryption. This comprehensive technical analysis dissects the exact methodologies, configuration parameters, and troubleshooting procedures required to establish robust Telnet automation pipelines, providing an exhaustive blueprint for infrastructure engineers tasked with bridging legacy systems into modern code-driven infrastructure management.

Architecting the Telnet Infrastructure

The foundational step in establishing a functional Telnet automation environment involves meticulously configuring the target network device to accept remote connections. Within emulation environments like EVE-NG, this requires enabling the Telnet service, assigning a unique IP address, and configuring the virtual terminal (vty) lines to permit incoming connections. Crucially, authentication credentials must be established to facilitate secure login sequences. For example, a standard configuration might designate the username as test and the password as test123, which are subsequently mapped into the automation inventory.

The inventory file acts as the central registry of target hosts and their respective connection parameters. While Ansible supports multiple inventory formats, including INI, YAML, and TOML, the choice of format carries significant technical implications. Historical documentation for Ansible has been notably misleading regarding the storage of vaulted passwords within INI files—a known limitation documented in issue #43897. Consequently, utilizing the YAML format for the inventory file is the strictly recommended approach, as it provides a structured, hierarchical representation of host attributes such as ansible_host and connection parameters. By defining the host sw1 with the IP address 192.168.1.100 in inventory_telnet.yml, the automation framework is provided with the precise network coordinates required to initiate the Telnet session.

Furthermore, defining connection: local within the playbook ensures that the Ansible control node utilizes the local system user to execute the Telnet action plugin, bypassing unnecessary remote shell interactions that could complicate the connection flow. This configuration forces the automation engine to establish a direct TCP socket connection to the target device, completely circumventing the SSH transport layer that Ansible utilizes by default.

Playbook Configuration and Prompt Engineering

Once the infrastructure is architected, the core automation logic is encoded within the Ansible playbook. The playbook for Telnet operations requires specific parameters to manage the highly interactive nature of the Telnet protocol. Because Telnet does not possess a built-in key exchange mechanism or standardized prompt structure like SSH, it relies heavily on regular expression-based prompt matching to determine when a command has been executed and when the device is ready for the next input.

In the pb_telnet.yml playbook, the gather_facts parameter is explicitly set to false to bypass the standard SSH-based fact-gathering phase, which is entirely irrelevant and technically destructive to a pure Telnet session. The telnet action block requires explicit definition of the user and password fields, which are parsed directly from the playbook or inventory. The login_prompt must precisely match the string output by the device during authentication, such as Username:. Following successful authentication, the automation engine must anticipate the command prompt of the target switch. The prompts field utilizes a regular expression—[>|#]—to dynamically detect whether the device presents a user prompt (>), a privileged executive prompt (#), or a generic output indicator (|). This prompt engineering is the technical bedrock of Telnet automation, allowing the script to reliably detect command completion.

The command sequence typically includes configuration commands to ensure a clean, uninterrupted output stream. Issuing terminal length 0 disables pagination, preventing the device from pausing the output with --More-- prompts that would break the regex matching. Subsequently, executing show version retrieves critical system information. By defining these commands within the command list, the Ansible telnet module establishes a sequential execution pipeline. Running this configuration is accomplished via the terminal command:

text ansible-playbook -i inventory_telnet.yml pb_telnet.yml

This command triggers the local control node to initiate the Telnet handshake, authenticate, and sequentially execute the defined commands against the target switch. The playbook will connect to the device and run the show version command, returning the output directly to the automation log.

Overcoming the Ansible Telnet TypeError

Despite meticulous configuration, engineers frequently encounter severe runtime errors rooted in the underlying Python implementation of Ansible's Telnet action plugin. A catastrophic failure frequently manifests as a TypeError originating from the telnet.py file located deep within the site-packages directory:

text /site-packages/ansible/plugins/action/telnet.py

Specifically, at line 69, the function tn.read_until(login_prompt) fails because the argument passed is of the type AnsibleUnicode, whereas the underlying Python telnetlib strictly requires an integer or a bytes-like object. This type mismatch causes the entire automation run to fail with an error message indicating an "Unexpected failure during module execution."

This bug represents a critical intersection of legacy Python 2/3 compatibility issues and Ansible's internal string handling. To resolve this systemic failure, the engineer must manually patch the Ansible installation. The process involves backing up the existing telnet.py file and replacing it with the patched version sourced from the official Ansible GitHub repository, specifically addressing issue #43609. By deploying the corrected telnet.py into the local virtual environment path:

text /Users/kz/Documents/C/ansibleprj/venv/lib/python3.7/site-packages/ansible/plugins/action/telnet.py

the type error is neutralized. Once the patched module is active, re-running the playbook completes successfully, returning a clean changed: [sw1] status and proving that the type mismatch has been resolved, restoring full operational capability to the Telnet automation workflow. The error log previously displayed:

text "/Users/kz/Documents/C/ansibleprj/venv/lib/python3.7/site-packages/ansible/plugins/action/telnet.py", line 69, in run tn.read_until(login_prompt) File "/Library/Frameworks/Python.framework/Versions/3.7/lib/python3.7/telnetlib.py", line 302, in read_until i = self.cookedq.find(match) TypeError: argument should be integer or bytes-like object, not 'AnsibleUnicode' fatal: [sw1]: FAILED

Securing Credentials with Ansible Vault

Storing plaintext credentials in playbooks or inventory files poses a severe security vulnerability. Modern DevOps standards mandate the encryption of sensitive data, a requirement fulfilled by the Ansible Vault utility. The ansible-vault command-line tool provides cryptographic protection for passwords using AES256 encryption.

To secure the Telnet password, the engineer executes the command:

text ansible-vault encrypt_string --vault-id test@prompt 'test123' --name 'ansible_ssh_pass'

This command encrypts the string test123 and outputs a long, encoded hash string. This encrypted payload must then be embedded directly into the YAML inventory file under the ansible_ssh_pass parameter, utilizing the !vault tag to instruct Ansible to decrypt it at runtime. The inventory configuration thus evolves to include:

• ansible_ssh_user: test
• ansible_ssh_pass: !vault | [encrypted_hash]
• ansible_ssh_timeout: 2
• ansible_ssh_port: 23

When executing the playbook, the vault ID must be explicitly passed via the command line to unlock the credentials during runtime. The execution command:

text ansible-playbook -i inventory_telnet.yml --vault-id test@prompt pb_telnet.yml

ensures that the encryption key is dynamically injected, allowing the Telnet session to authenticate seamlessly while maintaining rigorous data security standards. This mechanism prevents credential exposure in version control systems, aligning Telnet automation with enterprise-grade security protocols. The encrypted string structure follows a strict format containing the vault identifier, encryption algorithm (AES256), and the hashed payload:

text $ANSIBLE_VAULT;1.2;AES256;test 63386332356237643731346539336262336231343432313963376438653933323737636535383365 3562383633646261653739343536386566323462323063320a613638373439363032353137343330 34306264613932323832373532636230323730626239393564326564303563356666343734633135 6664373266663238660a363666336661353364393437356433616462346331313537623430393861 3536

Troubleshooting Connectivity and Protocol Conflicts

A persistent challenge in cross-platform Telnet automation is the unintended fallback to SSH. In complex environments utilizing virtualization software like GNS3, a switch running on a remote machine (e.g., IP 192.168.56.176 on port 5003) might not support SSH, yet Ansible's default behavior often attempts an SSH connection, resulting in connectivity failures.

When the playbook utilizes the ansible.netcommon.telnet module, incorrect configuration or missing inventory definitions can cause Ansible to erroneously attempt an SSH handshake. This manifests as a fatal error:

text fatal: [sw1]: UNREACHABLE! => {"changed": false, "msg": "Failed to connect to the host via ssh: kex_exchange_identification: banner line contains invalid characters\r

This error indicates that the control machine attempted an SSH connection to the GNS3 switch, failing because the target only speaks Telnet.

Resolving this requires strict alignment between the inventory and the playbook. The inventory file must explicitly define the host and port, such as sw1 ansible_hosts=192.168.56.176 ansible_port=5003. The Ansible configuration file (ansible.cfg) must correctly point to this inventory (inventory=/home/ar/Diss_Network/ansible/tests/hosts) and disable SSH key checking (host_key_checking=False). Furthermore, the inventory plugins must be correctly enabled (enable_plugins=host_list, script, auto, yaml, ini, toml). By ensuring the telnet action plugin is explicitly called within the task and that the connection type is explicitly managed, the SSH fallback error is eliminated, forcing the automation framework to correctly establish a raw Telnet session to port 5003.

Advanced Command Execution and Filtering

Once basic connectivity and authentication are secured, the automation can be enhanced with advanced command execution strategies. One highly effective technique for extracting specific system information involves utilizing command-line filtering directly on the network device. As noted by community expert Stefan P, appending | include uptime to standard information queries—such as show version | include uptime—forces the switch to return only the specific line containing the device's operational duration.

This filtering mechanism operates entirely on the device side, reducing the bandwidth and processing overhead on the Ansible control node. By integrating this piped command into the command list within the telnet action block, engineers can extract highly specific data points without having to parse massive blocks of unstructured text within Python. This technique exemplifies how leveraging native device capabilities enhances the efficiency and precision of the automation pipeline, bridging the gap between raw protocol interactions and structured data extraction.

Conclusion

The automation of legacy Telnet devices represents a critical intersection of historical protocol constraints and modern DevOps methodologies. Mastering this domain requires navigating Python type mismatches, securing credentials via AES256 encryption, and rigorously managing prompt-based state transitions. The underlying architecture of Ansible's Telnet plugin demands manual patching of the telnet.py file to resolve AnsibleUnicode type errors, ensuring that string handling aligns with Python's telnetlib requirements. Furthermore, distinguishing between SSH and Telnet connection parameters prevents catastrophic unreachable errors in virtualized network environments, particularly when dealing with GNS3 switches on non-standard ports. By meticulously configuring YAML inventory files, implementing robust vault encryption, and utilizing device-side command filtering, organizations can successfully integrate antiquated Telnet hardware into robust, scalable automation frameworks. This exhaustive technical approach ensures that legacy infrastructure remains fully compatible with contemporary Infrastructure as Code practices, maintaining operational continuity while transitioning towards fully encrypted, automated network management ecosystems.

Sources
1. GitHub Gainskills Ansible Telnet
2. Gainskills Blog Ansible Access Network via Telnet
3. Ansible Forum Use Telnet Connection