Home / server / Questions / 873277
In Process
Tony
Asked: 2017-09-13 04:58:06 +0800 CST

Reset "Too many authentication failures" on ubuntu without server access

  • 772

I was recently given a bunch of keys and a bunch of servers and had to do some detective work to figure out which key matched which server. After a few tries (maybe 3?) SSH locked me out. My guess is due to the MaxAuthTries setting. We have tracked down the correct key but now I can't use it because of the error message:

Too many authentication failures for ubuntu
Authentication failed.

I thought restarting the server would work but no luck. Even trying to SSH in with root gives me the same error. It seems a bit weird that I would get completely locked out of a server due to this and it would never reset. Is there something I'm missing about how to reset this? It's actually hard to google for information about this because everyone experiencing this problem seems to have a bunch of keys in ~/.ssh that a dumb client in cycling through but I am setting my key very specifically:

ssh <user>@<ip-address> -i /path/to/pem.pem

Thank you!

ssh

3 Answers

  1. Just an idea in case you should not have locked yourself out of all the machines - try each key on all servers until you get a bingo. This way at least three keys will find their server. And usually that lockout doesn't last forever. Then you can find the servers for the next three keys.

    Furthermore, in most cases the lockout is IP specific or at least subnet specific. So if you can try from other locations with other IPs (for example the three servers you were able to log in), you might have three more tries for each IP.

    Can't tell more about your lockouts, because there are many ways to get it configured - and you didn't even give a hint what OS and flavour your servers are.

    EDIT:

    "I said ubuntu" - sorry I missed this well visible detail. Ubuntu (at least up to 16.04) does not come with any type of lockout by default, so it must have been added somehow.

    You wrote "a bunch of keys and a bunch of servers", so I came up with the idea above, to at least get to your other servers faster.

    Because you use -i, it can't be the issue described elsewhere as caused by gnome key daemon offering multiple keys in a row until sshd rejects.

    MaxAuthTries can't be the culprit either, because it only limits login tries per connection (it defaults to 6). Next connection you have 6 more tries.

    There are many ways to limit login attempts; fail2ban is one of them, denyhosts another one, and you can find many more.

    Looks like you are concentrating on only one of your servers. If you manage to log into one of the others, you can find out how this lockout is achieved. If you can't solve your problem with the information you find there, other people here might be able to help.

    Re-reading your post I stumbled on "bunch of keys". Even though -i should make your ssh command use only the key you gave it, you may add -v flag to your ssh command. This way you can see what ssh is trying to do or wether the server cuts it off immediately.

    • 0

  2. Do try to ssh in verbose mode (ssh -vv) to double check that you are only offering the one key. Occasionally a client would present keys from an agent even if you use -i. Ideally, try the following to:

    1. Prevent the use of agent
    2. Get verbose output

    3. Put the options in front... just in case.

      env -u SSH_AUTH_SOCK ssh -vv -i /path/to/pem.pem -l user ip-address
    • 0
    1. create subdirectory ~/.ssh/keys/
    2. move almost all keys there
    3. adapt ~/.ssh/config to find the subdir
      IdentityFile ~/.ssh/keys/myproper.key

    issue done. nothing broken.

    thanks a lot to daniel kullmann How to recover from "Too many Authentication Failures for user root"

    • 0