Linux ssh authentication failed

3 Ways to fix SSH Too many authentication failures

“Too many authentication failures” is an error message that can occur when trying to connect to an SSH server.

It indicates that the client has attempted to authenticate with the server using too many incorrect authentication methods or keys, exceeding the server’s configured maximum.

When connecting to an SSH server, the client sends its available authentication methods to the server, such as password-based authentication or public key-based authentication.

The server responds with a list of acceptable authentication methods, and the client then attempts to authenticate using the methods in the order specified by the server.

If the client has several keys or authentication methods configured and tries to use them all in a row, but none of them is accepted by the server, the server may respond with a “Too many authentication failures” error message, indicating that the maximum number of attempts has been exceeded.

This is a security feature to prevent brute-force attacks on the server.

To resolve this error, the user can try to connect again, making sure to provide the correct credentials or limit the number of keys or authentication methods being attempted by the client.

Alternatively, the server administrator can increase the maximum number of authentication attempts allowed on the server.

This article will cover how to fix Too many authentication failures for usernames in 3 ways.

Understanding Too many authentication failures

SSH servers are commonly set up to allow for a maximum number of attempted authentications before rejecting the attempt.

It will try all the available credentials (such as certificate, public key, and stored credentials).

This setting for ssh servers is called “MaxAuthTries”, and the default value is 6.

When attempting to connect to an SSH server, if we have not told our SSH client specifically which key to use with the server, it will attempt to use all of our keys (one at a time) until it finds one that works.

If the key we need to use for the server is attempted by our client after the MaxAuthTries as configured by the server, our client will never reach the correct key and will fail its authentication attempt.

Error example 1:
Received disconnect from 192.168.3.123 port 22:2: Too many authentication failures
Disconnected from 192.168.3.123 port 22

Error Example 2:
Too many authentication failures
Sep 19 16:21:24 ubuntu sshd[192635]: error: maximum authentication attempts exceeded for testfest from 192.168.6.124 port 54324 ssh2 []
Sep 19 16:21:24 ubuntu sshd[192635]: Disconnecting: Too many authentication failures []
Sep 19 16:21:48 ubuntu su[192609]: pam_unix(su:session): session closed for user testfest

Solution for Too many authentication failures

If you receive the error message “Too many authentication failures “, it means that you make too many failed login attempts to a server.

A failed login attempt could occur for a variety of reasons but the most common reason is incorrect credentials such as wrong password.

There are a few reasons why too many authentication failures might happen:

• The user’s username and password might not be correct.
• The user might be connecting to the wrong server.
• The key file is not correct.
• Add too many key files with ssh-add command

If you are still getting this error, check the following solutions.

Use a Specific SSH Key for a Specific SSH Server in configuration file

To use a specific SSH key for a specific SSH server in the configuration file, you can follow these steps:

Open or create the SSH configuration file, located at ~/.ssh/config, using your preferred text editor.

Add a new section for the SSH server you want to connect to, using the following syntax:

Host HostName IdentityFile

Replace with the name you want to use for the SSH server, with the IP address or domain name of the SSH server, and with the path to the private key file you want to use.

Save the configuration file and close it.

You can now connect to the SSH server using the specific key you specified in the configuration file by running the ssh command

Use a Specific SSH Key in command line

The -i option in the SSH command is used to specify the identity (private key) file to be used for authentication.

By default, SSH looks for the private key in the user’s home directory with the filename id_rsa or id_dsa.

However, if the private key has a different filename or is located in a different directory, the -i option is used to specify the path to the private key file.

Increase MaxAuthTries in SSH

# vi /etc/ssh/sshd_config or (sudo vi /etc/ssh/sshd_config)

we will see the “MaxAuthTries 6” .

• Click “i” to enter the editing mode in the file.
• After modifying “MaxAuthTries” to 10, we can click on ”Esc” and type “:wq” to save and exit the file.
• Fire the command “service sshd restart” or “sudo service sshd restart” in order to apply changes made in the file.

More info about MaxAuthTries in SSH

The MaxAuthTries setting tells the ssh daemon how many different authentication attempts a user can try before it disconnects.

Each ssh key loaded into ssh-agent counts as one authentication attempt.

The default is 6 because many users have multiple ssh keys loaded into ssh-agent so that we can automatically log into different hosts that use different ssh keys.

After the ssh connection attempts all of our ssh keys and we haven’t run out of attempts and passwords are enabled we will eventually get a password prompt.

David is a Cloud & DevOps Enthusiast. He has years of experience as a Linux engineer. He had working experience in AMD, EMC. He likes Linux, Python, bash, and more. He is a technical blogger and a Software Engineer. He enjoys sharing his learning and contributing to open-source.

howtouselinux.com is dedicated to providing comprehensive information on using Linux.

We hope you find our site helpful and informative.

Источник

Public Key authentication failed

I am using ubuntu 13.10, and the server runs ubuntu 12.04. I had generate private and public keys using ssh-keygen, and put id_rsa.pub to server side and added it to authorzied_keys accordding to the method I found on the Internet. But, I still have to input password while I am trying to login. I have set the home dir to 700, .ssh dir to 700, authorzied_keys file to 600, and I have checke sshd_config file, and nothing happened. The debug infomation (with -vvv option) and sshd_config is as following, and nothing listed in server’s auth.log file. I even have updated openssh-server openssh-client on both client and server side. Is there anything else I have to do? Thanks for any infomation.

debug3: load_hostkeys: loading entries for host "[xxx.101.15.62]:2222" from file "/home/leetom/.ssh/known_hosts" debug3: load_hostkeys: found key type ECDSA in file /home/leetom/.ssh/known_hosts:2 debug3: load_hostkeys: loaded 1 keys debug3: load_hostkeys: loading entries for host "[xxx.101.15.62]:2222" from file "/home/leetom/.ssh/known_hosts" debug3: load_hostkeys: found key type ECDSA in file /home/leetom/.ssh/known_hosts:2 debug3: load_hostkeys: loaded 1 keys debug1: Host '[xxx.101.15.62]:2222' is known and matches the ECDSA host key. debug1: Found key in /home/leetom/.ssh/known_hosts:2 debug1: ssh_ecdsa_verify: signature correct debug2: kex_derive_keys debug2: set_newkeys: mode 1 debug1: SSH2_MSG_NEWKEYS sent debug1: expecting SSH2_MSG_NEWKEYS debug2: set_newkeys: mode 0 debug1: SSH2_MSG_NEWKEYS received debug1: Roaming not allowed by server debug1: SSH2_MSG_SERVICE_REQUEST sent debug2: service_accept: ssh-userauth debug1: SSH2_MSG_SERVICE_ACCEPT received debug2: key: /home/leetom/.ssh/id_rsa ((nil)), debug2: key: /home/leetom/.ssh/id_dsa ((nil)), debug2: key: /home/leetom/.ssh/id_ecdsa ((nil)), debug1: Authentications that can continue: publickey,password debug3: start over, passed a different list publickey,password debug3: preferred gssapi-keyex,gssapi-with-mic,publickey,keyboard-interactive,password debug3: authmethod_lookup publickey debug3: remaining preferred: keyboard-interactive,password debug3: authmethod_is_enabled publickey debug1: Next authentication method: publickey debug1: Trying private key: /home/leetom/.ssh/id_rsa debug1: read PEM private key done: type RSA debug3: sign_and_send_pubkey: RSA 68:51:b6:ed:cc:c2:54:f4:xx:15:41:d7:f5:4a:0e:da debug2: we sent a publickey packet, wait for reply debug1: Authentications that can continue: publickey,password debug1: Trying private key: /home/leetom/.ssh/id_dsa debug3: no such identity: /home/leetom/.ssh/id_dsa: No such file or directory debug1: Trying private key: /home/leetom/.ssh/id_ecdsa debug3: no such identity: /home/leetom/.ssh/id_ecdsa: No such file or directory debug2: we did not send a packet, disable method debug3: authmethod_lookup password debug3: remaining preferred: ,password debug3: authmethod_is_enabled password debug1: Next authentication method: password leetom@xxx.101.15.62's password: 

# Package generated configuration file # See the sshd_config(5) manpage for details # What ports, IPs and protocols we listen for Port 22 # Use these options to restrict which interfaces/protocols sshd will bind to #ListenAddress :: #ListenAddress 0.0.0.0 Protocol 2 # HostKeys for protocol version 2 HostKey /etc/ssh/ssh_host_rsa_key HostKey /etc/ssh/ssh_host_dsa_key HostKey /etc/ssh/ssh_host_ecdsa_key #Privilege Separation is turned on for security UsePrivilegeSeparation yes # Lifetime and size of ephemeral version 1 server key KeyRegenerationInterval 3600 ServerKeyBits 768 # Logging SyslogFacility AUTH LogLevel INFO # Authentication: LoginGraceTime 120 PermitRootLogin yes StrictModes yes RSAAuthentication yes PubkeyAuthentication yes #AuthorizedKeysFile %h/.ssh/authorized_keys # Don't read the user's ~/.rhosts and ~/.shosts files IgnoreRhosts yes # For this to work you will also need host keys in /etc/ssh_known_hosts RhostsRSAAuthentication no # similar for protocol version 2 HostbasedAuthentication no # Uncomment if you don't trust ~/.ssh/known_hosts for RhostsRSAAuthentication #IgnoreUserKnownHosts yes # To enable empty passwords, change to yes (NOT RECOMMENDED) PermitEmptyPasswords no # Change to yes to enable challenge-response passwords (beware issues with # some PAM modules and threads) ChallengeResponseAuthentication no # Change to no to disable tunnelled clear text passwords #PasswordAuthentication yes # Kerberos options #KerberosAuthentication no #KerberosGetAFSToken no #KerberosOrLocalPasswd yes #KerberosTicketCleanup yes # GSSAPI options #GSSAPIAuthentication no #GSSAPICleanupCredentials yes X11Forwarding yes X11DisplayOffset 10 PrintMotd no PrintLastLog yes TCPKeepAlive yes #UseLogin no #MaxStartups 10:30:60 #Banner /etc/issue.net # Allow client to pass locale environment variables AcceptEnv LANG LC_* Subsystem sftp /usr/lib/openssh/sftp-server # Set this to 'yes' to enable PAM authentication, account processing, # and session processing. If this is enabled, PAM authentication will # be allowed through the ChallengeResponseAuthentication and # PasswordAuthentication. Depending on your PAM configuration, # PAM authentication via ChallengeResponseAuthentication may bypass # the setting of "PermitRootLogin without-password". # If you just want the PAM account and session checks to run without # PAM authentication, then enable this but set PasswordAuthentication # and ChallengeResponseAuthentication to 'no'. UsePAM yes 

Источник