FortiNAC-F - Validate Credentials Fails on Switches, SSH Shows Algorithm Mismatch Error

[Thonno]

Hello Fortinet Community,

I'm currently facing an issue with my FortiNAC-F 7.2.8 (previously 7.2.7, upgraded in an attempt to resolve this) when trying to connect to switches via the Validate Credentials button in the device configuration. The credentials are verified to be correct, and FortiNAC successfully connects to the devices via SNMP. However, it fails to connect using CLI for validation.

Here’s a breakdown of the problem:

1. SNMP Connectivity: Successful – FortiNAC recognizes the device through SNMP without any issues.
2. CLI Connection (SSH) Fails with Validation: When attempting to validate CLI credentials on FortiNAC, the connection fails even though the credentials are accurate.
3. Direct SSH Attempt from FortiNAC CLI: When I directly try to SSH into the switch from FortiNAC's CLI, I receive the following error:
   Unable to negotiate with [Switch_IP] port 22: no matching key exchange method found. Their offer: diffie-hellman-group-exchange-sha1, diffie-hellman-group14-sha1, diffie-hellman-group1-sha1
   This indicates that FortiNAC doesn’t support the SSH key exchange algorithms that the switch is offering.
4. Telnet Connection: I also tested Telnet from the FortiNAC CLI, and it successfully connects to the switch. However, the Validate Credentials button does not seem to work with Telnet, resulting in a failure when validating CLI credentials via this protocol.

Steps Taken So Far

• Attempted SSH KEX Configuration: Tried to add older key exchange algorithms using:
  device -ip <Switch_IP> -setAttr -name SSH_KEX -value "diffie-hellman-group1-sha1 diffie-hellman-group14-sha1 diffie-hellman-group-exchange-sha1"
  However, this didn't resolve the issue.
• Firmware Update on FortiNAC: I upgraded FortiNAC from version 7.2.7 to 7.2.8, but the issue persists.

Has anyone encountered this issue? Is there a known solution or workaround to enable FortiNAC to use these older SSH algorithms, or to make Telnet work with Validate Credentials?

Thank you in advance for any advice or recommendations!

[ndumaj]

Hello @Thonno 
What is the SW brand and version?
Is this a new integration?

ssh -vvv user@SW-IP
Should provide more information.
However, Validate credentials via GUI is totally unrelated to the ssh via CLI.

BR

[Thonno]

T

he NAC is currently being implemented in the network.

I tested the following switches:

1. Cisco IOS Software, C3560E Software (C3560E-UNIVERSALK9-M), Version 15.0(2)SE4, RELEASE SOFTWARE (fc1)

2. Cisco IOS Software, IOS-XE Software, Catalyst L3 Switch Software (CAT3K_CAA-UNIVERSALK9-M), Version 03.06.06E RELEASE SOFTWARE (fc1)

3. Cisco IOS Software, IOS-XE Software, Catalyst L3 Switch Software (CAT3K_CAA-UNIVERSALK9-M), Version 03.06.06E RELEASE SOFTWARE (fc1)

All three switches show the same issue. Below is the debug output for the first switch:
fortinac # execute enter-shell
fortinac:~$ ssh -vvv FortiNac@172.27.1.2
OpenSSH_8.9p1, OpenSSL 3.0.14 4 Jun 2024
debug1: Reading configuration data /etc/ssh/ssh_config
debug1: /etc/ssh/ssh_config line 20: Applying options for *
debug2: resolve_canonicalize: hostname 172.27.1.2 is address
debug3: expanded UserKnownHostsFile '~/.ssh/known_hosts' -> '/home/admin/.ssh/known_hosts'
debug3: expanded UserKnownHostsFile '~/.ssh/known_hosts2' -> '/home/admin/.ssh/known_hosts2'
debug1: Authenticator provider $SSH_SK_PROVIDER did not resolve; disabling
debug3: ssh_connect_direct: entering
debug1: Connecting to 172.27.1.2 [172.27.1.2] port 22.
debug3: set_sock_tos: set socket 3 IP_TOS 0x48
debug1: Connection established.
debug1: identity file /home/admin/.ssh/id_rsa type -1
debug1: identity file /home/admin/.ssh/id_rsa-cert type -1
debug1: identity file /home/admin/.ssh/id_ecdsa type -1
debug1: identity file /home/admin/.ssh/id_ecdsa-cert type -1
debug1: identity file /home/admin/.ssh/id_ecdsa_sk type -1
debug1: identity file /home/admin/.ssh/id_ecdsa_sk-cert type -1
debug1: identity file /home/admin/.ssh/id_ed25519 type -1
debug1: identity file /home/admin/.ssh/id_ed25519-cert type -1
debug1: identity file /home/admin/.ssh/id_ed25519_sk type -1
debug1: identity file /home/admin/.ssh/id_ed25519_sk-cert type -1
debug1: identity file /home/admin/.ssh/id_xmss type -1
debug1: identity file /home/admin/.ssh/id_xmss-cert type -1
debug1: identity file /home/admin/.ssh/id_dsa type -1
debug1: identity file /home/admin/.ssh/id_dsa-cert type -1
debug1: Local version string SSH-2.0-OpenSSH_8.9
debug1: Remote protocol version 1.99, remote software version Cisco-1.25
debug1: compat_banner: match: Cisco-1.25 pat Cisco-1.* compat 0x60000000
debug2: fd 3 setting O_NONBLOCK
debug1: Authenticating to 172.27.1.2:22 as 'FortiNac'
debug1: load_hostkeys: fopen /home/admin/.ssh/known_hosts: No such file or directory
debug1: load_hostkeys: fopen /home/admin/.ssh/known_hosts2: No such file or directory
debug1: load_hostkeys: fopen /etc/ssh/ssh_known_hosts: No such file or directory
debug1: load_hostkeys: fopen /etc/ssh/ssh_known_hosts2: No such file or directory
debug3: order_hostkeyalgs: no algorithms matched; accept original
debug3: send packet: type 20
debug1: SSH2_MSG_KEXINIT sent
debug3: receive packet: type 20
debug1: SSH2_MSG_KEXINIT received
debug2: local client KEXINIT proposal
debug2: KEX algorithms: curve25519-sha256,curve25519-sha256@libssh.org,ecdh-sha2-nistp256,ecdh-sha2-nistp384,ecdh-sha2-nistp521,sntrup761x25519-sha512@openssh.com,diffie-hellman-group-exchange-sha256,diffie-hellman-group16-sha512,diffie-hellman-group18-sha512,diffie-hellman-group14-sha256,ext-info-c,kex-strict-c-v00@openssh.com
debug2: host key algorithms: ssh-ed25519-cert-v01@openssh.com,ecdsa-sha2-nistp256-cert-v01@openssh.com,ecdsa-sha2-nistp384-cert-v01@openssh.com,ecdsa-sha2-nistp521-cert-v01@openssh.com,sk-ssh-ed25519-cert-v01@openssh.com,sk-ecdsa-sha2-nistp256-cert-v01@openssh.com,rsa-sha2-512-cert-v01@openssh.com,rsa-sha2-256-cert-v01@openssh.com,ssh-ed25519,ecdsa-sha2-nistp256,ecdsa-sha2-nistp384,ecdsa-sha2-nistp521,sk-ssh-ed25519@openssh.com,sk-ecdsa-sha2-nistp256@openssh.com,rsa-sha2-512,rsa-sha2-256
debug2: ciphers ctos: chacha20-poly1305@openssh.com,aes128-ctr,aes192-ctr,aes256-ctr,aes128-gcm@openssh.com,aes256-gcm@openssh.com
debug2: ciphers stoc: chacha20-poly1305@openssh.com,aes128-ctr,aes192-ctr,aes256-ctr,aes128-gcm@openssh.com,aes256-gcm@openssh.com
debug2: MACs ctos: umac-64-etm@openssh.com,umac-128-etm@openssh.com,hmac-sha2-256-etm@openssh.com,hmac-sha2-512-etm@openssh.com,hmac-sha1-etm@openssh.com,umac-64@openssh.com,umac-128@openssh.com,hmac-sha2-256,hmac-sha2-512,hmac-sha1
debug2: MACs stoc: umac-64-etm@openssh.com,umac-128-etm@openssh.com,hmac-sha2-256-etm@openssh.com,hmac-sha2-512-etm@openssh.com,hmac-sha1-etm@openssh.com,umac-64@openssh.com,umac-128@openssh.com,hmac-sha2-256,hmac-sha2-512,hmac-sha1
debug2: compression ctos: none,zlib@openssh.com,zlib
debug2: compression stoc: none,zlib@openssh.com,zlib
debug2: languages ctos:
debug2: languages stoc:
debug2: first_kex_follows 0
debug2: reserved 0
debug2: peer server KEXINIT proposal
debug2: KEX algorithms: diffie-hellman-group-exchange-sha1,diffie-hellman-group14-sha1,diffie-hellman-group1-sha1
debug2: host key algorithms: ssh-rsa
debug2: ciphers ctos: aes128-cbc,3des-cbc,aes192-cbc,aes256-cbc
debug2: ciphers stoc: aes128-cbc,3des-cbc,aes192-cbc,aes256-cbc
debug2: MACs ctos: hmac-sha1,hmac-sha1-96,hmac-md5,hmac-md5-96
debug2: MACs stoc: hmac-sha1,hmac-sha1-96,hmac-md5,hmac-md5-96
debug2: compression ctos: none
debug2: compression stoc: none
debug2: languages ctos:
debug2: languages stoc:
debug2: first_kex_follows 0
debug2: reserved 0
debug1: kex: algorithm: (no match)
Unable to negotiate with 172.27.1.2 port 22: no matching key exchange method found. Their offer: diffie-hellman-group-exchange-sha1,diffie-hellman-group14-sha1,diffie-hellman-group1-sha1

[ndumaj]

Hello @Thonno 

Here you can find some related article that i guess you have already followed above:
https://community.fortinet.com/t5/FortiNAC/Troubleshooting-Tip-Modify-SSH-authentication-algorithms-...
https://community.fortinet.com/t5/FortiNAC-F/Troubleshooting-Tip-SSH-communication-fails-after-upgra...

For security Reason FNAC removed  Vulnerable Diffie-Hellman SSH Ciphers.

I would suggest testing with a test SW with the latest firmware version GA.

BR

[ndumaj]

Additionally, what are the ciphers supported by the SW?
On the SW terminal log, you should also get info for what is the SW complaining.
Adding the latest Ciphers on the SW side should resolve the issue.
Update of firmware SW should also add the latest ciphers.

BR

[ebilcari]

It seems that the switch offer is limited to these 3 old protocols:
Unable to negotiate with 172.27.1.2 port 22: no matching key exchange method found. Their offer: diffie-hellman-group-exchange-sha1,diffie-hellman-group14-sha1,diffie-hellman-group1-sha1

After adding the switch in FNAC, enter CLI und run the commands:

# execute enter-shell
$ device -ip 172.27.1.2 -setAttr -name SSH_KEX -value "diffie-hellman-group1-sha1 diffie-hellman-group14-sha1"

and than try to validate credentials again from GUI.

If the validation is failing also for Telnet, that may be an indication of wrong device mapping or user access limitation. FNAC should enter via CLI and apply some basic commands in order for the validation to succeed. Do this switches have 'Enable Password:' configured?

[Thonno]

@ndumaj @ebilcari 
After experimenting with the parameters while trying to connect via SSH from execute enter-shell, I was able to connect using this command:

ssh -oKexAlgorithms=+diffie-hellman-group-exchange-sha1,diffie-hellman-group14-sha1,diffie-hellman-group1-sha1 -oHostKeyAlgorithms=+ssh-dss,ssh-rsa -oCiphers=+aes128-cbc,3des-cbc,aes192-cbc,aes256-cbc user@switch

Following this, I applied the following commands to FortiNAC:

device -ip switchIP -setAttr -name SSH_KEX -value "diffie-hellman-group-exchange-sha1 diffie-hellman-group14-sha1 diffie-hellman-group1-sha1"
device -ip switchIP -setAttr -name SSH_HOST_KEY -value "ssh-dss ssh-rsa"
device -ip switchIP -setAttr -name SSH_CIPHERS -value "aes128-cbc 3des-cbc aes192-cbc aes256"

However, even with these settings, I’m still unable to connect via CLI with a regular `ssh user@switch` command, nor does it work through the Validate Credentials feature in FortiNAC.

Additionally, I am unable to update the OS or authentication algorithms on the switches, as they are managed by another provider. Therefore, it would be ideal to find a workaround on the FortiNAC side to enable the connection.

Thank you very much for your help!

[ebilcari]

The changes applied with 'device -ip' command will affect the behavior of the SSH client used by the FNAC application. When you run directly from CLI 'ssh user@switch', the system SSH client is used, this is commonly used to troubleshoot but the results doesn't really matter.

The fact that Telnet is also failing is an indication that the user of the switch doesn't have full rights or the enable password may be missing in the configuration.
The 'aaa new-model' in the switch configuration may also change the behavior of the login and enable password. Another reason could be the banner that may have special characters included like '>' or '#', that may confuse the parsing logic of FNAC.

Some checks and debug logs can be find in this article.

[Thonno]

No luck, despite adding the following parameters in device -ip:

• Name: SSH_KEX, Value: diffie-hellman-group1-sha1 diffie-hellman-group-exchange-sha1 diffie-hellman-group14-sha1, Length: 89
• Name: SSH_CIPHERS, Value: aes128-ctr aes192-ctr aes256-ctr aes128-cbc 3des-cbc aes192-cbc aes256-cbc, Length: 74

the issue persists.

I noticed that the only missing configuration is for the Host Key Algorithms in ssh-rsa.
Is there a command to configure it?

As for Telnet, I am still waiting for updates regarding the enable password.

[ndumaj]

Hello @Thonno 
Your reply: Additionally, I am unable to update the OS or authentication algorithms on the switches, as they are managed by another provider. Therefore, it would be ideal to find a workaround on the FortiNAC side to enable the connection.

Answer: Fortinac Debugs might help in this case, but it would be very useful if you can test the behavior with a SW updated to the latest Firmware version.

BR