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