Description
This article describes how to resolve an issue where, when selecting the Validate Credentials button in Model Configuration, the following message appears:
SNMP connect succeeded. However, the device failed to connect using CLI credentials.
The device either does not support a CLI or credentials are invalid.
Scope
FortiNAC, FortiNAC-F.
Solution
- Verify the Protocol Type in the switch's Model Configuration is set appropriately (Telnet, SSH1 or SSH2). For example, if the Type is set to Telnet, ensure Telnet is enabled on the switch.
- Verify the CLI credentials in the Model Configuration match those set in the switch itself. Note the following:
- The user account must have the appropriate permissions configured on the device.
- If no enabled password is configured in the switch for that user account (example: level 15 accounts), the Enable Password field in the Model Configuration must be left blank.
- Arista switches can be configured to require typing 'enable' to enter enable mode, but no password is needed. For such configurations, populate the Enable Password field with the # character (requires version 8.7.2 or higher). Technical Note: CLI credential failure for Arista switches
- Attempt to access the switch using the same credentials and Protocol Type set in Model Configuration. If it is not possible, use another device in the same subnet as the Control Server. Enter the following:
ssh <userid>@<device IP address>telnet <device IP address> - It might also occur when a non-standard SSH port is used but is blocked by firewall policies or other firewalls that are in the path.
- The FortiGate Model Configuration' now includes a new REST-API, but the FortiNAC-F Inventory view still cannot validate credentials. If the connection attempt results in a 'connection refused' message, the port may be getting blocked somewhere on the network, or the function may be disabled in the switch.
diagnose debug plugin enable TelnetServer
The following entries appear in the debug logs if there is an issue with the REST API.
yams INFO :: 2025-01-28 09:13:56:234 :: #3397361 :: Thread:https-jsse-nio-0.0.0.0-8443-exec-86, IP:XX.XX.XX.XX- Creating SSH2 session: cli_timeout=12000ms, connect_timeout=12000ms, retries=3, retry_interval = 5000, retry_multiplier=1.5, update_timeout=true
yams INFO :: 2025-01-28 09:13:56:234 :: #3397361 :: Thread:https-jsse-nio-0.0.0.0-8443-exec-86, IP:XX.XX.XX.XX - Connect retry #1: cli_timeout=12000ms, connect_timeout=12000ms
yams INFO :: 2025-01-28 09:13:56:235 :: #3397361 :: IP=XX.XX.XX.XX, keyboard-interactive = false
yams INFO :: 2025-01-28 09:13:56:235 :: #3397361 :: SSH2: Connecting to XX.XX.XX.XX port 222
yams INFO :: 2025-01-28 09:13:56:243 :: #3397361 :: SSH2: Connection to XX.XX.XX.XX succeeded
yams INFO :: 2025-01-28 09:13:56:243 :: #3397361 :: SSH2: Authenticating to XX.XX.XX.XX
yams SEVERE :: 2025-01-28 09:13:56:327 :: #3402046 :: Mismatched keys presented by /XX.XX.XX.XX:222 for entry=[XX.XX.XX.XX]:10222 ssh-ed25519 AAAAC3NzaC1lZDI1NTE5AAAAILugZQM/aKSU0LcYSygxaiug3P0nmQMqMiTUpvevdxlA
org.apache.sshd.client.session.ClientSessionImpl WARNING :: 2025-01-28 09:13:56:327 :: #3402046 :: exceptionCaught(ClientSessionImpl[admin@/XX.XX.XX.XX:222])[state=Opened] SshException: Server key did not validate
org.apache.sshd.client.session.ClientSessionImpl INFO :: 2025-01-28 09:13:56:327 :: #3402046 :: Disconnecting(ClientSessionImpl[admin@/XX.XX.XX.XX:222]): SSH2_DISCONNECT_HOST_KEY_NOT_VERIFIABLE - Server key did not validate
yams.TelnetServer INFO :: 2025-01-28 09:13:56:329 :: #3397361 :: Warning: failed to connect to XXXXXX
-02/XX.XX.XX.XX Server key did not validate. code = (9)
yams INFO :: 2025-01-28 09:13:56:392 :: #3397361 :: https-jsse-nio-0.0.0.0-8443-exec-86 Fortigate.getAPIPort could not read from device XX.XX.XX.XX
yams INFO :: 2025-01-28 09:13:56:392 :: #3397361 :: https-jsse-nio-0.0.0.0-8443-exec-86 Fortigate.testCLIAccess failed to read api port from XX.XX.XX.XX
To resolve the issue related to the old/wrong REST-API key, follow these steps.
Log in to the FortiNAC-F CLI console and run these commands.
To check if the old fingerprint is present using this command:
execute ssh-known-hosts show nac
If it is presented, then remove it with the following command.
execute ssh-known-hosts remove-host nac XX.XX.XX.XX <------------replace XX with an actual IP
# Host XX.XX.XX.XX found: line 191
/bsc/.ssh/known_hosts updated.
Original contents retained as /bsc/.ssh/known_hosts.old
If the SSH port is not standard, use the command syntax below.
execute ssh-known-hosts remove-host nac [XX.XX.XX.XX]:222
# Host [XX.XX.XX.XX]:222 found: line 195
/bsc/.ssh/known_hosts updated.
Original contents retained as /bsc/.ssh/known_hosts.old
Note:
If the credentials validation fails even after running the aforementioned command, the appliance must be removed from Inventory view and added again.
After debugs are enabled, again 'Validate Credentials' again from the FortiNAC model configuration and investigate the output.
Press Ctrl+C to stop tail output when finished.
FortiNAC (CentOS):
logs
nacdebug -logger org.apache.sshd
nacdebug -name TelnetServer false
diagnose debug plugin disable TelnetServer
- FortiNAC system logs as noted in this article
- FortiNAC CLI output while the issue was recreated.
Related articles:
Technical Tip: Issues using '#' character in CLI banner
Technical Note: Configure SSH keys
Technical Note: CLI failures to Avaya switches with no login banner
