Unable to login to UNIX from PAM endpoint due to cipher errors
Article ID: 277317
Updated On:
Products
Issue/Introduction
There are times when SSH Mindterm access to a remote Linux endpoint does not work, even if running
nmap -p 22 --script ssh2-enum-algos <target>
seems to provide a list of valid algorithms as compared with the list available in Configuration --> Security --> Cryptography --> SSH Mindterm
In this particular case, also, the tcpdump captured by support from inside a PAM appliance will show that the server is trying to initiate the handshake by using a list of key exchange algorithms and the client is presenting a similar list, only to fail immediately on the server side sending a FIN ACK packet
The PAM GUI will just show for a couple of seconds a message about not being able to agree on algorithms, and xcd_spfd.log will not identify a cause for the lack of connectivity
Environment
CA PAM all versions up to the present one (4.1.6)
Cause
While carrying out the handshake it is not only the type of Key Exchange Algorithm and Cipher that counts, but also the type of Server Host Key.
The type of Server Host Key supported in the server must as well be supported by PAM or else this type of problem will occur: there won't be a disagreement in the type of algorithm for key exchange, but since there is no common support for the Server Host Key type, the operation will fail.
To see if this is the case, you need to set sshd in debug. In AIX 7.2, where this problem was detected, this is done by setting
LogLevel DEBUG
in file sshd_config, making sure this goes the AUTH (usually pointing to /var/adm/syslog/authlog.log) and restarting the sshd subsystem. Reproducing the problem messages like the following will appear
Dec 19 11:59:31 <machine_name> auth|security:info sshd[36766050]: Connection from 172.17.0.2 port 49468 on 172.17.0.3 port 22
Dec 19 11:59:31 <machine_name> auth|security:info sshd[36766050]: Unable to negotiate with 172.17.0.2 port 49468: no matching host key type found. Their offer: ssh-rsa,ssh-dss [preauth]
Resolution
To solve this one can try to check the list of server key type offered by the UNIX system, obtained with the nmap command above
nmap -p 22 --script ssh2-enum-algos <target>
For instance in the case from which this article has been derived this was giving
server_host_key_algorithms: (4)
rsa-sha2-512
rsa-sha2-256
ecdsa-sha2-nistp256
Against the potential list supported by PAM which can be obtained by unchecking the "Default" option in Configuration --> Security --> Cryptography --> SSH Mindterm --> Server Host Key and clicking on the eye icon. In a 4.1.6.83 system, for instance, the full list of supported Server Host Key is
ecdsa-sha2-nistp256,ecdsa-sha2-nistp384,ecdsa-sha2-nistp521,rsa-sha2-256,rsa-sha2-512,ssh-rsa,ssh-dss
whereas by default is is just ssh-rsa,ssh-dss
We can see in this particular case that the full list of server host keys supported does include among other the ecdsa-sha2-nistp256 and the rsa-sha2 server host keys, whereas the default configuration did not.
So using the full list as supported Server Host key types in PAM instead of just leaving the default will resolve the problem
Feedback
