I set MaxAuthTries to 1 on my Linux machine. Then I tried to ssh into my Linux machine from a different machine on my local network but it failed saying "Too many authentication failures".

I'm assuming this is because I had some failures earlier while I was setting things up, and they still count towards the total.

The man page says:

MaxAuthTries Specifies the maximum number of authentication attempts permitted per connection. Once the number of failures reaches half this value, additional failures are logged. The default is 6.

What is considered a connection? Does that mean you only get MaxAuthTries from a certain IP address? Is this referring to a TCP connection? How can I kill the connection so I can make a new one and try to ssh again?



In the case of SSH, a connection is one established connection to the sshd's TCP port (usually port 22). Omce sshd stops accepting further authentication attempts it closes the connection, and at this point the connection is done.

Before a user gets to make an authentication attempt, SSH protocol requires the negotiation of encryption and other protocol options, establishment of session keys and exchange of host keys. So each new connection requires a non-trivial bit of work: a storm of SSH connection attempts from multiple sources could certainly be used to DoS a server.

An authentication attempt is one attempt of any authentication method that is currently enabled in sshd configuration. For example:

  • if client offers a SSH key for authentication, each offered key counts as one attempt.
  • if Kerberos/GSSAPI authentication method is enabled, seeing if the client can be authenticated with it counts as one attempt
  • each password typed into the password authentication prompt obviously counts as one.

The first two can cause the situation you're experiencing: if you set MaxAuthTries to one and Kerberos/GSSAPI authentication is enabled, it may eat up the single attempt before you even get to try password authentication. Likewise, if your SSH client has an authentication key available, but you haven't added your public key to the destination system's ~/.ssh/authorized_keys for the destination user, the public key authentication attempt will eat up your single attempt and you won't even get to try password authentication.

pam_unix, the PAM library that normally handles password authentication, enforces a delay of two seconds after a failed authentication attempt by default.

If your primary threat is password-guessing worms and bots on other compromised systems in the internet, reducing MaxAuthTries may be a bad move: since a bot won't tire, it will always reconnect and try again. Each attempt requires you to spend some CPU capacity for SSH protocol negotiations. You'll want to primarily ensure that the bot won't succeed, and secondarily that the bot will waste as much of its time as possible on that one existing connection, with minimum cost to you. Allowing multiple authentication attempts over one connection but answering... very... slowly... will do exactly that.

This is also why sshd will request a password from the client even if password authentication is completely disabled: the prompt is completely fake, and the client will be rejected no matter what password is entered. But the client has no way to know that for sure.

Of course, if you allow too many authentication attempts over one connection, the bot may eventually terminate the connection from its side, if the bot programmer has implemented a timeout to limit the effectiveness of such a "tar-pit defense".


To be broad, a connection is defined as any attempt to connect as a certain user.

The pam_tally or pam_tally2 command is useful here depending on which distribution you are using. The following command will show you how many failures there have been for a certain user:

pam_tally --user=username

To reset it for a certain user:

pam_tally --reset

For all users:

pam_tally --reset user=username

To verify that it has been reset:

pam_tally --username=user

Executing the command pam_tally or pam_tally2 with no options will show all users which have any failed attempts or who are locked out. Be sure to change to pam_tally2 in case you have that one.

  • 1
    I'm pretty sure you can have multiple authentication attempts (PAM or otherwise) over a single connection. That's pretty much the point of MaxAuthTries. – ilkkachu Jan 21 '18 at 10:00
  • I'm not disputing that. It's just that once he exceeds the limit in MaxAuthTries, he's not going to be able to connect anymore. The only thing that he can do in that case is to increase MaxAuthTries or reset pam_tally or pam_tally2. The latter makes more sense. – Nasir Riley Jan 21 '18 at 14:13

This is a bit crystal ball gazing, but a connection is exactly that, and unless you explicitly set options around connection multiplexing and lingering (ControlMaster, ControlPersist) on the client, it should terminate immediately.

What I suppose is happening (and ssh -v can help you verify, look out for "Trying private key") is that you want to use password-based auth to that machine. However, your client likely has a key pair for passwordless authentication in ~/.ssh. Standard configs give preference to keys over password, so your ssh offers your key, the server doesn't like it, and that's the one failed try you're allowed. (Variation of the theme: maybe you have multiple keypairs setup and only one of those is authorized for your server.) You can use -oPreferredAuthentications=keyboard-interactive,password to override what auth mechanisms to offer: if the client stops suggesting it can do key-based, you should the password prompt, so you can log in to set the value on the server higher again.

  • 1
    In practice, a "connection" is a TCP connection, as the question suggests as one possibility. I don't know if there are any SSH servers and clients that would support connecting over anything else. Also, I don't think you can use connection multiplexing before authentication, so that shouldn't be an issue here(?) – ilkkachu Jan 21 '18 at 10:03
  • @ilkkachu: yes, the multiplexing is a bit of a red herring before auth, there's a bit of an XY problem in the question. – Ulrich Schwarz Jan 21 '18 at 14:15

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.