SSH fails with mismatched ciphers

Document ID : KB000076636
Last Modified Date : 02/07/2018
Show Technical Document Details
Customer upgraded PAM from older version(2.6.4) to 2.8.3.x and found they can no longer SSH to their Linux machines.
The error being reported is mismatched ciphers.
From user's point of view, the SSH applet launches but it is stuck and does not appear to do anything without any specific signs of error.

SSH Access is stuck and failed to login due to chiper mismatch
PAM SSH (Mindterm) shows different behavior after upgrading PAM.
SSH (Mindterm) fails to connect to target Linux server while the Putty Service can.
How can I change the PAM side of ciphers to match the target Linux server instead of changing the ciphers at the target server?
PAM Upgraded from 2.6.4 to 2.8.3.x
Target device is Centos OS 5.x and 7.x
sshd.conf at the target device allows AES256-CTR only, other ciphers have been disabled for security reasons.
This issue affects PAM version 2.8.3.x but not PAM or later
If you run PAM version 2.8.3.x then you can upgrade to to permanently address this issue or you should upgrade to latest PAM version 3.2 or later.

The target device enforces strictly limited set of ciphers so the client(PAM) will have to use matching set of ciphers to handshake or it will fail to establish secure connection.
This cipher list in SSH Mindterm is hard-coded so you will have to upgrade to fixed version of PAM to address this problem.

If you cannot upgrade, as a workaround, you can utilize Putty service to access the Linux machines or liaise with your Linux Administrator so SSH (sshd service) is configured to accept at least one of the following ciphers on the target Linux machines.

   aes128-ctr, arcfour128, aes128-cbc, blowfish-ctr, blowfish-cbc, 3des-ctr, 3des-cbc, arcfour