SSH fails with mismatched ciphers

Document ID : KB000076636
Last Modified Date : 15/03/2019
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
The problem may also be observed in 3.X releases up to 3.2. It is expected to be fixed for good in PAM 3.3.

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