Tips for finding Knowledge Articles

  • - Enter just a few key words related to your question or problem
  • - Add Key words to refine your search as necessary
  • - Do not use punctuation
  • - Search is not case sensitive
  • - Avoid non-descriptive filler words like "how", "the", "what", etc.
  • - If you do not find what you are looking for the first time,reduce the number of key words you enter and try searching again.
  • - Minimum supported Internet Explorer version is IE9
Home  >

KB-6180: Troubleshooting SSH Connection Problems Preauth

Authentication Service ,  

20 June,16 at 04:13 PM

Applies to: OpenSSH server and any SSH client. 

Cannot log in to machines using SSH or scp. Typically, this happens after upgrading Centrify OpenSSH. 

SSH clients are using ciphers, KexAlgorithms, or MACs which are not supported or accepted by the SSH server. 

Note: SSH options can be specified using the -o option if you are using SCP or SFTP.

Most SSH pre-authenticaiton issues can be diagnosed by examining the final error message and enabling debug3 on SSH clients. e.g. ssh user@server -vvv 
Please pay close attention to kex_parse_kexinit entries for clues regarding pre-authentication failures.

Cipher mismatch: 
If there are no ciphers that both client and server accept, an error message similar to the following is given. 
no matching cipher found: client aes128-cbc server,aes128-ctr,aes192-ctr,aes256-ctr
In the example above, the client is requesting to use aes128-cbc cipher which is not accepted by the server.
Check the sshd_config file for allowed ciphers that matches one of ciphers that SSH clients are trying to use. Alternatively, ciphers to be used can be specified in SSH clients when connecting. (e.g. ssh -c aes256-ctr ).
For the particular example above, the following needs to be specified in the sshd_config file. 
If no ciphers are defined in the config file, check the sshd_config(5) for supported and default accepted ciphers for your paticular version of OpenSSH.
Note that a cipher being supported does not necessary mean it is accepted. 

KexAlgorithms mismatch:

If KexAlgorithm negotiation fails, an error message simiar to the following is given. 
Unable to negotiate a key exchange method
In SSH client debug2 output, you should see entries similar to the following: 
debug2: kex_parse_kexinit: diffie-hellman-group1-sha1
debug2: kex_parse_kexinit:,,ssh-rsa,,,,ssh-dss,,,,ecdsa-sha2-nistp256,ecdsa-sha2-nistp384,ecdsa-sha2-nistp521,ssh-ed25519
In this case, the client is requesting to use diffie-hellman-group1-sha1 which is not one of KexAlgorithms accepted by the server. 

Consult sshd_config(5) man page for supported KexAlgorithms and configure it to accept KexAlgorithm that SSH client is requesting to use. Alternatively, configure SSH client to use one of KexAlgorithms accepted by server (e.g. ssh -oKexAlgorithms=diffie-hellman-group1-sha1). 

Unsupported MACs:
Entries similar to the following may appear in the client log: 
debug1: SSH2_MSG_KEX_DH_GEX_INIT sent
debug1: expecting SSH2_MSG_KEX_DH_GEX_REPLY
Received disconnect from Index was outside the bounds of the array.
Consult sshd_config(5) for supported and accepted MAC algorithms and adjust them accordingly.