SSH authentication failing after upgrade - Support and Troubleshooting

SSH authentication failing after upgrade Issue SSH authentication started failing post Quebec upgrade Error observed on the MID as below LogStatusMonitor.60 DEBUG: Event: OneMinuteEvent&#13; Worker-Interactive:CommandPipeline-491028e51b366010f29aedf1b24bcb93 DEBUG: SSHSessionFactory: connection failed authentication for key SSHSessionPoolKey[target:10.80.48.48&amp;port:22&amp;fixed_cred:&amp;tag:&amp;unique_id:8d10202157322010fc39b8efe34ee9ba&amp;privilegedCommand:sudo&amp;passwordPrompt:&amp;debug:false&amp;useSeperateSession: false&amp;updateIndex: 2&amp;disablePrivilegeCheck: false&amp;cipherAlgorithms: aes128-ctr,aes192-ctr,aes256-ctr,3des-ctr,aes128-cbc,aes192-cbc,aes256-cbc,3des-cbc&amp;hostKeyAlgorithms: ecdsa-sha2-nistp256,ecdsa-sha2-nistp384,ecdsa-sha2-nistp521,rsa-sha2-256,rsa-sha2-512,ssh-rsa,ssh-dss&amp;kexAlgorithms: ecdh-sha2-nistp256,ecdh-sha2-nistp384,ecdh-sha2-nistp521,diffie-hellman-group-exchange-sha256,diffie-hellman-group14-sha256,diffie-hellman-group16-sha512,diffie-hellman-group14-sha1,diffie-hellman-group1-sha1,diffie-hellman-group-exchange-sha1,rsa2048-sha256,rsa1024-sha1&amp;macAlgorithms: hmac-sha2-256,hmac-sha1,hmac-sha2-512,hmac-sha1-96,hmac-md5-96,hmac-md5] with credential SSH_ZENOSS&#13; Worker-Interactive:CommandPipeline-491028e51b366010f29aedf1b24bcb93 DEBUG: SSHSessionFactory: Authentication failure. Blacklisting key SSHSessionPoolKey[target:10.80.48.48&amp;port:22&amp;fixed_cred:&amp;tag:&amp;unique_id:8d10202157322010fc39b8efe34ee9ba&amp;privilegedCommand:sudo&amp;passwordPrompt:&amp;debug:false&amp;useSeperateSession: false&amp;updateIndex: 2&amp;disablePrivilegeCheck: false&amp;cipherAlgorithms: aes128-ctr,aes192-ctr,aes256-ctr,3des-ctr,aes128-cbc,aes192-cbc,aes256-cbc,3des-cbc&amp;hostKeyAlgorithms: ecdsa-sha2-nistp256,ecdsa-sha2-nistp384,ecdsa-sha2-nistp521,rsa-sha2-256,rsa-sha2-512,ssh-rsa,ssh-dss&amp;kexAlgorithms: ecdh-sha2-nistp256,ecdh-sha2-nistp384,ecdh-sha2-nistp521,diffie-hellman-group-exchange-sha256,diffie-hellman-group14-sha256,diffie-hellman-group16-sha512,diffie-hellman-group14-sha1,diffie-hellman-group1-sha1,diffie-hellman-group-exchange-sha1,rsa2048-sha256,rsa1024-sha1&amp;macAlgorithms: hmac-sha2-256,hmac-sha1,hmac-sha2-512,hmac-sha1-96,hmac-md5-96,hmac-md5]&#13; Release Quebec Resolution There are two types of keys " Host key " and " User key ". The " Host key " is a unique key for each host and the algorithm used is known host key algorithms. This algorithm list is shared with both client and server during SSH handshake, and come up with an algorithm that both sides agree. The " User key " is provided for each user, and may be different from the negotiated host key algorithm. When ssh client gets authenticated by the server, it would first check if host key is valid, and then check for user key. The reason of why behavior changed in "Quebec" is that : Before Quebec: snc_ssh checks the presented key match with a host key algorithm that client supports and use it. After Quebec: snc_ssh looks for if presented key match a host key algorithm that both client and server supports. If no algorithm is found, the connection would fail. This was changed because we try to follow the RFC standard as below Any public key algorithm may be offered for use in authentication. In particular, the list is not constrained by what was negotiated during key exchange. If the server does not support some algorithm, it MUST simply reject the request. Due to this code change, when a server (target) does not have ssh-dss in host key algorithm and when the MID connects to this server under a user (with ssh-dss as user key), the connection would fail. In spite of providing the fix, there are two workarounds to mitigate the situation: Upgrade the " User key " to a stronger algorithm as it is the recommended way by OpenSSH officials. If the upgrade cannot be done, we may try an alternative, that is generating a ssh-dss host key, so that the ssh-dss would be included in the host key algorithm that the server supports. This can be done as Generate a ssh-dss host key under /etc/ssh/ , similar to other keys that were generated during installation Add " HostKeyAlgorithms=+ssh-dss " in /etc/ssh/sshd_config to enable server to use ssh-dss for some newer sshd version, since it was disabled / deprecated by default.