Login authentication fails with " Too many authentication failures "
The following error message displayed .
Received disconnect from xx.xx.xx.xx: 2: Too many authentication failures
The default authentication methods done by AIX sshd is in the following order :
Public-key( or none) , keyboard-interactive , password
What is happening is that both the ssh client and the sshd server agree to a series of methods to use to authenticate the user. The first is "none", and this fails. (It fails silently and does not increase the failure count.) Next, the client asks for publickey authentication and sends an identity key to the server. The server, being unable to open the user's authorized_keys file and fails that login attempt. The client continues sending identity keys to the server, with the server going through the same motions each time which increases the failure count.
After that, the client requests keyboard-interactive authentication. This type of authentication is different than password authentication because it requires that KbdInteractiveDevices be set to a list of "devices" (usually PAM authentication modules) where sshd will send the challenges from the module directly to the user and send the user's responses to the module. With password authentication, sshd asks the ssh client to prompt for a password and ssh sends the password back to sshd.
The main purpose of keyboard-interactive is for situations where multiple challenge-responses are needed, such as prompting for both a password and a one-time token. In most environments, this is not needed. Unfortunately, if the client requests keyboard-interactive but no devices are configured in sshd, the request will fail and be counted as an authentication failure. The test for the maximum number of tries is coded as ">=", meaning that once the failure count reaches MaxAuthTries-1, sshd gives up.
Few reasons for this error:
1) SSHD terminates the connection once the failure count reaches MaxAuthTries,
2) keyboard-interactive counts as a failure even though it's not needed.
3) This could happen if you have five or more DSA/RSA identity files stored in your .ssh
directory.
Gather ssh debug information :
https://www-01.ibm.com/support/docview.wss?uid=isg3T1011149
These are two cases shows , how login authentication works with MaxAuthTries parameter.
#/etc/ssh/sshd_config
MaxAuthTries 5
Case A : Success
The client side sets 3 secret keys in /.ssh/config as shown below.
# cat /.ssh/config
IdentityFile /.ssh/id_rsa
IdentityFile /.ssh/padmin.id.rsa
IdentityFile /.ssh/stats_admin.id_rsa
debug1: attempt 0 failures 0 [preauth]
debug2: input_userauth_request: try method none [preauth]
debug1: attempt 1 failures 0 [preauth]
debug2: input_userauth_request: try method publickey [preauth] <--- 1st IdentityFile
debug1: attempt 2 failures 1 [preauth]
debug2: input_userauth_request: try method publickey [preauth] <--- 2nd IdentityFile
debug1: attempt 3 failures 2 [preauth]
debug2: input_userauth_request: try method publickey [preauth] <--- 3rd IdentityFile
debug1: attempt 4 failures 3 [preauth]
debug2: input_userauth_request: try method keyboard-interactive [preauth]
debug1: attempt 5 failures 4 [preauth]
debug2: input_userauth_request: try method password [preauth] <--- Password
So login will be successful with 5th attempt as MaxAuthTries is 5-1 = 4 .
Case B : Failed
The client side sets 4 secret keys in /.ssh/config as shown below.
# cat /.ssh/config
IdentityFile /.ssh/id_rsa
IdentityFile /.ssh/padmin.id.rsa
IdentityFile /.ssh/stats_admin.id_rsa
IdentityFile /.ssh/id_rsa_SRM_xyz11
debug1: attempt 0 failures 0 [preauth]
debug2: input_userauth_request: try method none [preauth]
debug1: attempt 1 failures 0 [preauth]
debug2: input_userauth_request: try method publickey [preauth] <--- 1st IdentityFile
debug1: attempt 2 failures 1 [preauth]
debug2: input_userauth_request: try method publickey [preauth] <--- 2nd IdentityFile
debug1: attempt 3 failures 2 [preauth]
debug2: input_userauth_request: try method publickey [preauth] <--- 3rd IdentityFile
debug1: attempt 4 failures 3 [preauth]
debug2: input_userauth_request: try method publickey [preauth] <--- 4th IdentityFile
debug1: attempt 5 failures 4 [preauth]
debug2: input_userauth_request: try method keyboard-interactive [preauth]
So here in this case user will get " Too many authentication failures " error when he tries ssh login as failure count already reaches MaxAuthTries value.
1) SSHD terminates the connection once the failure count reaches MaxAuthTries value
Solution : Increase MaxAuthTries value on the SSH server in /etc/ssh/sshd_config
2) keyboard-interactive counts as a failure even though it's not needed.
Solution:
Configure ssh to disable keyboard-interactive authentication by setting the following option in /etc/ssh/sshd_config:
ChallengeResponseAuthentication no
With ChallengeResponseAuthentication set to "yes" (the default), sshd terminated the connection when the keyboard-interactive method failed. But when ChallengeResponseAuthentication to "no", keyboard-interactive was not attempted and prompted for a password.
3) This could happen if you have five or more DSA/RSA identity files stored in your .ssh
directory.
Solution:
If you have a number of private keys in your .ssh directory you could disable Public Key Authentication
at the command line using the
-o optional argument.
$ ssh -o PubkeyAuthentication=no root@host
SUPPORT |
If additional assistance is required after completing all of the instructions provided in this document, please follow the step-by-step instructions below to contact IBM to open a case for software under warranty or with an active and valid support contract. The technical support specialist assigned to your case will confirm that you have completed these steps.
1. Document and/or take screen shots of all symptoms, errors, and/or messages that might have occurred.
2. Capture any logs or data relevant to the situation.
3. Contact IBM to open a case:
-For electronic support, please visit the IBM Support Community:
https://www.ibm.com/mysupport
-If you require telephone support, please visit the web page:
https://www.ibm.com/planetwide/
4. Provide a good description of your issue, and reference this Technote, and any issues you had with the instructions.
5. Collect the system snap and upload all of the details and data for your case.
To collect a complete snap of your system information: |
5.1) Remove previously gathered data
# snap -r
5.2) Copy related files from #1 and #2 to the snap data directory
# mkdir -p /tmp/ibmsupt/testcase
# cp <logs, screenshots, etc> /tmp/ibmsupt/testcase
5.3) Run the snap command with one of the following options to collect all info.
* If you have already engaged with a support engineer, use the flags specified by your support team.
# snap -aZc (Omits system dump data)
OR
# snap -ac (Use if system dump data is needed)
5.4) Rename the testcase to include your case number to ensure it is properly attached to your case
# mv /tmp/ibmsupt/snap.pax.Z /tmp/ibmsupt/yourcase#[.optional_description].snap.pax.Z
5.5) Upload the file by one of the following options (a, b, or c)
a) Attach to your case
https://www.ibm.com/mysupport/s/my-cases
b) Upload to the Enhanced Customer Data Repository(ECuRep)
https://www.secure.ecurep.ibm.com/app/upload_sf
c) Upload to the Blue Diamond FTP server (Blue Diamond Customers Only)
https://msciportal.im-ies.ibm.com
* Note: For information about blue diamond upload see:
http://www.ibm.com/support/docview.wss?uid=nas8N1020947
|
|
[{"Business Unit":{"code":"BU058","label":"IBM Infrastructure w\/TPS"},"Product":{"code":"SWG10","label":"AIX"},"Component":"","Platform":[{"code":"PF002","label":"AIX"}],"Version":"All Versions","Edition":"","Line of Business":{"code":"LOB08","label":"Cognitive Systems"}}]