Ssh – In sshd_config ‘MaxAuthTries’ limits the number of auth failures per connection. What is a connection

opensshsshsshd

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?

https://linux.die.net/man/5/sshd_config

Best Answer

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".

systemd

If that doesn't work and your using a distro such as Fedora/CentOS/RHEL and it's using systemd then try this:

$ systemctl sshd.service reload

You can get all the commands that sshd.service will accept by doing this. Hit the Tab key after typing the following:

$ systemctl sshd.service 
cancel                 emergency              is-enabled             list-unit-files        reload-or-restart      start
condreload             enable                 is-failed              list-units             reload-or-try-restart  status
condrestart            exit                   isolate                load                   rescue                 stop
condstop               force-reload           kexec                  mask                   reset-failed           suspend
daemon-reexec          halt                   kill                   poweroff               restart                try-restart
daemon-reload          help                   link                   preset                 set-environment        unmask
default                hibernate              list-dependencies      reboot                 show                   unset-environment
delete                 hybrid-sleep           list-jobs              reenable               show-environment       
disable                is-active              list-sockets           reload                 snapshot

If it's a Debian/Ubuntu system they use upstart to mange services, at least with the newer versions.

See my answer to this Q&A titled: How to “close” open ports?. I discuss your options for using upstart & systemd further in that answer.

Neither?

You could use kill to send the SIGHUP signal to the running process if none of the above are appropriate for your particular distro.

$ pkill -1 sshd

Will send signal 1 (SIGHUP) to the sshd process. If you don't have the pkill or pgrep family of commands you can use ps.

$ ps -eaf | grep sshd 1234

Then take that process ID and send it a signal using the kill command.

$ kill -1 1234

Signals

If you ever forget which ones are which you can use the kill command to find out via the -l switch.

Example

$ kill -l
 1) SIGHUP       2) SIGINT       3) SIGQUIT      4) SIGILL       5) SIGTRAP
 6) SIGABRT      7) SIGBUS       8) SIGFPE       9) SIGKILL     10) SIGUSR1
11) SIGSEGV     12) SIGUSR2     13) SIGPIPE     14) SIGALRM     15) SIGTERM
16) SIGSTKFLT   17) SIGCHLD     18) SIGCONT     19) SIGSTOP     20) SIGTSTP
21) SIGTTIN     22) SIGTTOU     23) SIGURG      24) SIGXCPU     25) SIGXFSZ
26) SIGVTALRM   27) SIGPROF     28) SIGWINCH    29) SIGIO       30) SIGPWR
31) SIGSYS      34) SIGRTMIN    35) SIGRTMIN+1  36) SIGRTMIN+2  37) SIGRTMIN+3
38) SIGRTMIN+4  39) SIGRTMIN+5  40) SIGRTMIN+6  41) SIGRTMIN+7  42) SIGRTMIN+8
43) SIGRTMIN+9  44) SIGRTMIN+10 45) SIGRTMIN+11 46) SIGRTMIN+12 47) SIGRTMIN+13
48) SIGRTMIN+14 49) SIGRTMIN+15 50) SIGRTMAX-14 51) SIGRTMAX-13 52) SIGRTMAX-12
53) SIGRTMAX-11 54) SIGRTMAX-10 55) SIGRTMAX-9  56) SIGRTMAX-8  57) SIGRTMAX-7
58) SIGRTMAX-6  59) SIGRTMAX-5  60) SIGRTMAX-4  61) SIGRTMAX-3  62) SIGRTMAX-2
63) SIGRTMAX-1  64) SIGRTMAX

References

F.9. Administering services with systemd

Ssh – How to configure SSH so that OTP can be used with ssh-copy-id and then only keypair authorization is accepted

Public key authentication is turned on by default and has higher priority then password authentication (handled by PAM or directly).

You can set up in sshd_config option UsePAM yes (by default on Red Hat), which will defer authentication to PAM -- this is configured in /etc/pam.d/sshd (can differ a bit on some systems).

For OTP you can use google_authenticator, or some other open implementation of one-time passwords. There are many how-to's around here. You can try to search for two-factor authentication, but basically it is adding one line like this

 auth            required        pam_google_authenticator.so

in the /etc/pam.d/sshd and do some configuration: Arch has nice instruction for this: https://wiki.archlinux.org/index.php/Google_Authenticator

Using only one-time passwords, without the second factor can be potential risk if the one-time password or token gets lost -- I recommend you not to go this way and implement rather the two factor authentication than only one-time password.