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

---

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 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
• Universal Device Support - Multi-vendor device support
• Device Import Methods - Getting devices into rConfig