Linux - SecurityThis forum is for all security related questions.
Questions, tips, system compromises, firewalls, etc. are all included here.
Notices
Welcome to LinuxQuestions.org, a friendly and active Linux Community.
You are currently viewing LQ as a guest. By joining our community you will have the ability to post topics, receive our newsletter, use the advanced search, subscribe to threads and access many other special features. Registration is quick, simple and absolutely free. Join our community today!
Note that registered members see fewer ads, and ContentLink is completely disabled once you log in.
If you have any problems with the registration process or your account login, please contact us. If you need to reset your password, click here.
Having a problem logging in? Please visit this page to clear all LQ-related cookies.
Get a virtual cloud desktop with the Linux distro that you want in less than five minutes with Shells! With over 10 pre-installed distros to choose from, the worry-free installation life is here! Whether you are a digital nomad or just looking for flexibility, Shells can put your Linux machine on the device that you want to use.
Exclusive for LQ members, get up to 45% off per month. Click here for more info.
When a ipaddress reaches this threshold, what/when does it reset for that ipaddress?
Quote:
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.
from that text in the man page it looks like it resets for each *connection* (nothing to do with the ipaddress). Are you observing some sort of different behaviour?
I would think per a connection would be per a ipddress, if not what would define the "per a connection" criteria(since there is no authentication at this point the daemon does not keep track of the user but the connection)? Yes, the behavior I have is once I reach the threshold, I can no longer log in ever for that user. The work around was to vnc into the host, raise the threshold, login successfully to reset the threshold for that connection. If I didn't do that would that connection be banned from logging in forever?
I would think per a connection would be per a ipddress, if not what would define the "per a connection" criteria(since there is no authentication at this point the daemon does not keep track of the user but the connection)?
A connection to the daemon. Ie from the time that authentication starts on a single ssh instance (to an sshd) and then exits. (but I've been unable to confirm this).
If you read the sshd man page the term "connection" is used very often in a way that is consistent with the definition I am assuming. For example, the section describing running sshd in debug mode
Code:
-d Debug mode. The server sends verbose debug output to standard error, and does not put itself in the
background. The server also will not fork and will only process one connection. This option is only
intended for debugging for the server. Multiple -d options increase the debugging level. Maximum is
3.
I would think per a connection would be per a ipddress, if not what would define the "per a connection" criteria(since there is no authentication at this point the daemon does not keep track of the user but the connection)?
The definition of "per a connection" is a new tcp session. Started with the 3 way handshake. Ring any bells?
Quote:
Originally Posted by dman777
Yes, the behavior I have is once I reach the threshold, I can no longer log in ever for that user. The work around was to vnc into the host, raise the threshold, login successfully to reset the threshold for that connection. If I didn't do that would that connection be banned from logging in forever?
I doubt that behavior comes solely from the configuration of the MaxAuthTries. Might be another programm running that blocks your ip from connecting. fail2ban for example.
The definition of "per a connection" is a new tcp session. Started with the 3 way handshake. Ring any bells?
I doubt that behavior comes solely from the configuration of the MaxAuthTries. Might be another programm running that blocks your ip from connecting. fail2ban for example.
No, these are all my personal systems and they are bare min. so I know exactly what is running on them. No fail2ban. I had the wrong key, after the first failed attempt I kept getting disconnected with I reached maximum authentication tries messages. It is is not per a TCP handshake. Which brings me back to the original question on what resets this threshold assuming it's the ipaddress that is the source for the unauthenticated session.
this is curious. A couple of things to check: have you checked the sshd logs (or better still run sshd -d) to see what is reported when a user is locked out? Also, do you see this behaviour when ssh to localhost (to eliminate possibilities of network, firewall, whatever issues)?
LinuxQuestions.org is looking for people interested in writing
Editorials, Articles, Reviews, and more. If you'd like to contribute
content, let us know.