Network Device Connectivity & Backup Process - SSH, Telnet, SNMP Guide

Network Device Connectivity & Backup Process - SSH, Telnet, SNMP Guide

Understanding how rConfig connects to your network devices is essential for effective troubleshooting, security hardening, and performance optimization. This guide details the complete connectivity lifecycle—from initial protocol selection and credential retrieval through command execution and configuration storage. Whether you’re diagnosing connection failures, configuring firewall rules, or optimizing backup schedules, knowing the order of operations and decision logic behind each connection attempt will help you maintain a robust and secure configuration management workflow.

rConfig employs a flexible, multi-protocol approach to device connectivity, automatically selecting the most appropriate method based on device capabilities, configured settings, and connection success history. The platform supports SSH (preferred for its security), Telnet (for legacy devices), and various API-based protocols including SNMP, FTP Services, and REST APIs as well as custom scripts. Each connection attempt follows a well-defined sequence: device selection, credential retrieval, protocol negotiation, authentication, command execution, and graceful disconnection. This systematic approach ensures reliable configuration backups while maintaining detailed audit logs and providing intelligent retry mechanisms when connections fail.

---

Supported Connection Protocols

SSH (Secure Shell)

rConfig uses its own built-in SSH engine rather than relying on the operating system’s SSH client. This provides greater control over connection handling, authentication methods, and error management, ensuring consistent behavior across different deployment environments.

• Default port: 22 (configurable per device)
• Authentication methods: Password, SSH keys, keyboard-interactive
• Key exchange and encryption: Industry-standard algorithms with configurable cipher suites
• When SSH is preferred: Always recommended for security and reliability on modern network devices

Telnet

Telnet support is available for legacy devices that do not support SSH. However, Telnet is not supported in rConfig Vector and will not be added in future Vector releases due to its inherent security limitations.

• Default port: 23 (configurable per device)
• Security considerations: Transmits credentials and data in cleartext; use only on isolated management networks
• Legacy device support: Essential for older equipment lacking SSH capabilities
• When to use telnet: Only when SSH is not available and the device is on a secure, isolated network

API Connections

rConfig supports REST API connections for devices that expose configuration management through modern API interfaces. API support is currently read-only (RO) and REST-based.

• Supported protocols: REST APIs
• Authentication methods: Token-based, Basic Auth, custom headers
• Use cases: Cloud-native devices, SDN controllers, modern network appliances
• Limitations: Currently read-only; write operations planned for future releases

SNMP

SNMP support enables configuration retrieval from devices via SNMP protocol, as well as receiving SNMP traps for event-driven configuration backups.

• Supported versions: SNMPv2c, SNMPv3 (recommended for security)
• Operations: Read operations for configuration data, trap receiving for event notifications
• Community strings / credentials: Encrypted storage with RBAC-controlled access
• Use cases: Devices where CLI access is restricted, trap-triggered backups, bulk data collection

xFTP Services (Docker-based)

rConfig includes an optional xFTP Docker container that provides FTP, TFTP, and SFTP services for devices that push configurations to an FTP server. Alternatively, you can use your own FTP services if docker is not allowed or feasible.

• Protocols: FTP, TFTP, SFTP (SCP)
• Use cases: Devices configured to push configurations automatically, legacy backup workflows
• Security: SFTP recommended; FTP/TFTP should only be used on isolated networks

Note: Detailed xFTP configuration is covered in dedicated documentation.

BYOC/SIE (Bring Your Own Code / Script Integration Engine)

The Script Integration Engine allows you to use custom scripts written in any programming language to retrieve configurations or run advanced custom workflows from devices. This provides ultimate flexibility for specialized connection requirements or proprietary protocols.

• Supported languages: Any language available on your system (Python, Perl, Ruby, Go, etc.)
• Use cases: Proprietary devices, custom protocols, complex authentication flows, specialized parsing
• Integration: Scripts are executed by rConfig with device parameters passed as arguments

Note: BYOC/SIE implementation details and examples are covered in dedicated documentation.

---

Authentication Flow

When rConfig initiates a device connection, it follows a precise sequence of operations to ensure successful authentication and command execution. Understanding this flow is critical for troubleshooting connection issues and optimizing your device configuration for reliable backups.

Order of Operations

Step 1: Job Initiation A backup job is triggered via scheduled task, manual CLI command, UI action, or external event (SNMP trap, API call).

Step 2: Device Selection rConfig identifies the target device(s) from the job parameters. For scheduled tasks, this includes all devices assigned to the command group associated with the task.

Step 3: Retrieve Device Settings Device-specific settings are loaded from the database, including IP address, port, connection timeout, protocol preferences, and vendor template associations.

Step 4: Credential Retrieval Credentials are retrieved based on device assignment. rConfig supports both device-specific credentials and shared credential sets. Credentials are decrypted from secure storage just-in-time for the connection attempt.

Step 5: Protocol Determination The connection protocol is determined based on:

• Device-level protocol override (if set)
• Vendor template default protocol
• Global system defaults
• Previous connection success history (cached for performance)

Step 6: Connection Establishment rConfig initiates the connection using the selected protocol:

• SSH: TCP connection to port (default 22), SSH handshake, cipher negotiation
• Telnet: TCP connection to port (default 23), terminal negotiation
• API: HTTPS connection, SSL/TLS handshake, token/header preparation
• SNMP: UDP or TCP connection to port (default 161), community string or v3 auth prep
• BYOC: Script execution with device parameters passed as environment variables or arguments

Step 7: Authentication Authentication is attempted using the retrieved credentials. The specific method depends on the protocol:

• SSH: Password, public key, keyboard-interactive, or combination
• Telnet: Username/password prompts with pattern matching
• API: Bearer tokens, Basic Auth, or custom header authentication
• SNMP: Community strings (v2c) or user credentials (v3)
• BYOC: Script-defined authentication logic

Step 8: Command Execution Once authenticated, rConfig executes the command set associated with the device’s command group. Commands are sent sequentially with prompt detection between each command to ensure proper timing.

Step 9: Output Capture Command output is captured in real-time, with intelligent buffering to handle large configurations. Pagination is automatically handled by detecting “More” prompts and sending appropriate responses (space, return, etc.).

Step 10: Configuration Processing Raw output is processed to remove prompts, ANSI escape sequences, terminal artifacts, and unnecessary whitespace. The cleaned configuration is then validated and prepared for storage.

Step 11: Storage The processed configuration is stored in the file system following rConfig’s hierarchical structure and a corresponding database record is created with metadata including timestamp, file path, hash, and relationship to previous versions.

Step 12: Clean Disconnection The session is gracefully terminated with proper logout commands (if applicable) and the connection is closed. This ensures device resources are released and logs on the device reflect a clean disconnect.

Step 13: Logging & Notification Connection attempt details, execution times, success/failure status, and any errors are logged to the activity log. If configured, email or webhook notifications are sent for failures or specific events.

Queued Connections vs Debug/ CLI Connections

• Queued Connections: Follow the full authentication and command execution flow as described above, with retries and error handling. Used for scheduled tasks and bulk operations.
• Debug/CLI Connections: Bypass certain steps for immediate execution. Used for manual testing and troubleshooting. Limited error handling and no retries and critically do not timeout.

Authentication Methods Priority

rConfig follows a hierarchical credential priority system to ensure flexible and secure authentication. The order of credential attempts varies by protocol, with SSH and Telnet following the most comprehensive hierarchy.

SSH & Telnet Authentication Priority

When connecting via SSH or Telnet, rConfig attempts authentication in the following order:

1. Device-Specific Credentials (Highest Priority)

   • Credentials configured directly on the device record
   • Used when a device requires unique authentication (jump hosts, special access accounts, etc.)
   • Overrides all other credential sources
   • Best for devices with unique security requirements or non-standard authentication

2. Device Credential Set

   • Shared credential sets assigned to the device
   • Allows grouping devices that share common credentials (e.g., all branch routers)
   • Supports credential rotation across multiple devices simultaneously
   • Ideal for devices organized by region, role, or security zone

3. Key Vault Credentials (Fallback)

   • Credentials stored in external key vault integrations (HashiCorp Vault, AWS Secrets Manager, etc.)
   • Used when set is configured
   • Provides centralized credential management across multiple rConfig instances
   • Requires key vault integration to be configured in system settings

4. ** SSH Keys from Credential Sets**

   • If SSH keys are configured in the credential set, they are attempted after passwords
   • Supports both password and key-based authentication methods
   • Allows for more secure, key-based access where supported by the device

5. Authentication Failure

   • If all credential sources fail, the connection attempt is logged as failed
   • Retry logic may attempt the sequence again depending on configuration
   • Detailed error messages indicate which credential methods were attempted

API Authentication

API connections use protocol-specific authentication methods:

• No Auth: Some APIs may not require authentication (public endpoints)
• Token-Based: Bearer tokens, API keys from device configuration or credential sets
• Basic Auth: Username/password combinations
• Custom Headers: Vendor-specific authentication headers configured per device

SNMP Authentication

SNMP authentication follows a simpler hierarchy:

1. Device-specific community strings or SNMPv3 credentials
2. Credential set SNMP credentials
3. Global SNMP defaults (if configured)

BYOC/SIE Authentication

Custom scripts handle their own authentication logic. rConfig passes credentials as environment variables or command-line arguments based on script configuration:

• $RCONFIG_USERNAME, $RCONFIG_PASSWORD, $RCONFIG_ENABLE_PASSWORD
• Scripts can implement their own fallback logic

Best Practice: For production environments, use credential sets or key vaults to centralize credential management and simplify rotation. Reserve device-specific credentials for exceptions only.

Configuration Backup Process

How Backups Are Initiated

Scheduled Backups Configuration backups can be scheduled via the rConfig UI or CLI. Scheduled tasks run at defined intervals (daily, weekly, monthly) and can target specific command groups or individual devices.

Manual Backups Manual backups can be initiated through the rConfig UI or CLI. Users can select specific devices or command groups to back up immediately.

Event-Triggered Backups Event-triggered backups can be initiated by external events such as SNMP traps or API calls. This allows for real-time configuration backups in response to network changes or alerts.

Backup Execution Flow

The backup execution flow follows the authentication flow detailed above, with additional steps for processing and storing the configuration data. The key steps include:

1. Job Queue - Job is queued and scheduled for execution
2. Device Connection - Connection is established per the above authentication flow
3. Command Execution - Commands are run to retrieve the device configuration
4. Output Capture - Output is captured and validated for completeness
5. File Processing - Output is parsed, cleaned, and formatted as needed
6. Storage - Files are stored in the appropriate location
7. Versioning - Versions are tracked using a consistent naming convention and metadata
8. Notification - Success/failure notifications are sent to relevant stakeholders

---

Configuration Storage

File System Structure

The configuration files are stored in a hierarchical directory structure based on device categories, device names, and timestamps. This structure allows for easy navigation and retrieval of configuration files. This also allows for efficient storage and retrieval of configuration files, as well as easy identification of the most recent version. Custom scripting can be used to interact with the file system directly if needed.

/storage/app/rconfig/
  ├── data/
  │   ├── [Category]/
  │   │   ├── [Device]/
  │   │   │   ├── [YYYY]/
  │   │   │   │   ├── [MMM]/
  │   │   │   │   │   ├── [DD]/
  │   │   │   │   │   │   ├── config_timestamp.txt

The file naming convention includes the device name and timestamp to ensure uniqueness and facilitate version tracking.

Database Records

Each configuration file stored in the file system has a corresponding record in the rConfig database. This record includes metadata such as:

• Device ID
• File path
• Timestamp of backup
• File hash (for integrity verification)
• Version number
• User who initiated the backup (if applicable)

Encryption

Configuration files can be encrypted at rest using filesystem-level encryption or application-level encryption. This ensures that sensitive configuration data is protected from unauthorized access. See the configuration encryption documentation for more details.

---

Command Execution

Connection Templates

Connection templates define the command sequences used to interact with different device types. These templates are associated with vendor profiles and can be customized per device or command group. Templates include:

• Login sequences
• Enable/privilege escalation commands
• Configuration retrieval commands
• Logout sequences

There is a library of pre-defined templates for common vendors, and custom templates can be created as needed. They are stored on github for easy access and version control, and can easily be imported into your rConfig instance via the UI or CLI for use in your environment.

Terminal Handling

Some templates may require specific terminal settings (e.g., terminal length, width) to ensure proper output formatting. rConfig can send terminal configuration commands as part of the connection sequence to optimize output for parsing.

Review the vendor specific templates for recommended terminal settings. Or contact rConfig support for assistance.

Output Processing

Output from command execution is processed to remove extraneous data such as prompts, ANSI escape sequences, and pagination artifacts. This ensures that the stored configuration is clean and usable. rConfig includes built-in parsers for common output formats, and custom parsers can be developed for unique device outputs.

rCONfig code and templates can handle a variety of output formats, including:

• Plain text
• XML
• JSON
• Proprietary formats

Custom scripts can also be used to further process output if needed. Or contact rConfig support for assistance.

---

Error Handling & Retries

Connection Failure Scenarios

• Authentication failures - incorrect credentials, unsupported authentication methods are all logged in the activity log
• Timeout handling - connection timeouts, command execution timeouts are all managed by the Horizon Queue Engine
• Protocol negotiation failures - unsupported protocols, version mismatches are all logged in the activity log
• Network connectivity issues - unreachable devices, DNS resolution failures are all logged in the activity log

Retry Strategy

• Retry attempts and intervals - rConfig only attempts a single connection attempt per job execution. If the connection fails, it is logged and the job is marked as failed. Users can manually re-run the job or schedule a new job as needed.
• Backoff logic - Not applicable as rConfig does not implement automatic retries. The exception is for inbound SNMP trap jobs, has a configuration retry and backoff mechanism to handle transient failures.

Logging & Auditing

• Detailed error messages - All connection attempts and errors are logged with detailed messages to facilitate troubleshooting.

---

Security Considerations

Credential Management

• Encryption at rest - All sensitive credential data is encrypted when stored to protect against unauthorized access.
• Access control - Fine-grained access controls are implemented to restrict who can view or modify credentials.
• Credential rotation - Regular rotation of credentials is recommended to minimize the risk of compromise.

---

Related Documentation

• CLI Commands - Manual device download commands and automation
• Device Management Fundamentals - Core device concepts and workflows
• Configuration Snippets - Automated configuration deployment
• Universal Device Support - Multi-vendor device support
• Device Import Methods - Getting devices into rConfig