Often, it may be desired to configure sshd on a target Linux server to present specific KEX algorithms in the SSH negotiation with the client. This can be achieved by OS-level configuration on the target server by modifying the sshd_config file.

When using Advanced Server Access (ASA) to establish the SSH connection, the SFT debug output may suggest that the peer server is presenting algorithms that do not match what has been set on the target server. This may make it seem that using ASA to establish the SSH connection is interfering with the desired algorithms that had been configured within the target server's sshd settings.

For example, here is a target server that has been configured to exclude the "-diffie-hellman-group14-sha1" algorithm.

[root@targetserver ~]# grep -i "kexalgorithm\|loglevel" /etc/ssh/sshd_config
LogLevel DEBUG3
KexAlgorithms -diffie-hellman-group14-sha1

[root@targetserver ~]# sshd -T | grep kex
kexalgorithms curve25519-sha256,curve25519-sha256@libssh.org,ecdh-sha2-nistp256,ecdh-sha2-nistp384,ecdh-sha2-nistp521,diffie-hellman-group-exchange-sha256,diffie-hellman-group14-sha256,diffie-hellman-group16-sha512,diffie-hellman-group18-sha512

However, the SFT debug output from the ASA client still suggests that the peer server is presenting "diffie-hellman-group14-sha1"

asaclient@P4XF7TX3PY Downloads % SFT_DEBUG=1 sft ssh targetserver

debug2: peer server KEXINIT proposal
debug2: KEX algorithms: curve25519-sha256,curve25519-sha256@libssh.org,ecdh-sha2-nistp256,ecdh-sha2-nistp384,ecdh-sha2-nistp521,diffie-hellman-group14-sha256,diffie-hellman-group14-sha1
debug2: host key algorithms: rsa-sha2-256,rsa-sha2-512,ssh-rsa

• Advanced Server Access (ASA)
• Linux/SSH

The reason why different algorithms are seen in the SFT_DEBUG=1 output of "sft ssh" is because under the covers, "sft ssh" utilizes "sft proxycommand" which spins up a local SSH proxy on the client that bridges the SSH connection between the ASA client and the target server. So the algorithm output seen in the debug output on the client is not showing the negotiation between the client and target server. It shows the negotiation between the client and the local SSH proxy, which is all purely internal communication.

No action is required, as this is a working-as-designed behavior. ASA is not actually interfering with the algorithms on the target server. The debug output seen on the client is simply a logging artifact based on ASA's architectural usage of an internal SSH proxy within the client.

One way to confirm this is by increasing the sshd log verbosity on the target server in order to verify which algorithms the target server is actually presenting.

In this example, the above output suggested perhaps the ASA client was seeing the target server presenting the "diffie-hellman-group14-sha1" algorithm.

But by verifying from the target server perspective itself, we can see that it is NOT presenting "diffie-hellman-group14-sha1"

Dec 06 21:00:05 targetserver sshd[2966]: debug2: local server KEXINIT proposal [preauth]
Dec 06 21:00:05 targetserver sshd[2966]: debug2: KEX algorithms: curve25519-sha256,curve25519-sha256@libssh.org,ecdh-sha2-nistp256,ecdh-sha2-nistp384,ecdh-sha2-nistp521,diffie-hellman-group-exchange-sha256,diffie-hellman-group14-sha256,diffie-hellman-group16-sha512,diffie-hellman-group18-sha512 [preauth]