I have passwords turned off, and require keys to match. The zombie armies swarming outside are trying brute force attacks that in part involve guessing login NAMES. If they guess the wrong NAME, this is logged in syslog. If they guess a working user name, then the attack has PARTIALLY SUCCEEDED, but this information is IGNORED. That is, it is not logged. If the zombie army has tell when it has found a working user name, then it might concentrate on finding its key, and I will be none the wiser. I will not see that happening. I can get this info by turning logging to DEBUG, but then it is very noisy. I do not understand why failed attempts to login to my account are not logged. Why is this, and how do I get it fixed? Thanks! -- Perry
On Wed, Oct 06, 2010 at 18:07:29 -0500, Perry Wagle wrote:> I have passwords turned off, and require keys to match. The zombie armies swarming outside are trying brute force attacks that in part involve guessing login NAMES. If they guess the wrong NAME, this is logged in syslog. If they guess a working user name, then the attack has PARTIALLY SUCCEEDED, but this information is IGNORED. That is, it is not logged. If the zombie army has tell when it has found a working user name, then it might concentrate on finding its key, and I will be none the wiser. I will not see that happening. > > I can get this info by turning logging to DEBUG, but then it is very noisy. I do not understand why failed attempts to login to my account are not logged. > > Why is this, and how do I get it fixed? > > Thanks! > > -- Perry > >Try verbose rather than debug. -- Iain Morgan
LogLevel VERBOSE logs the ipaddress of the attempt on a "signon that exists", but not which signon name. -- Perry On Oct 7, 2010, at 9:51 AM, Iain Morgan wrote:> On Wed, Oct 06, 2010 at 18:07:29 -0500, Perry Wagle wrote: >> I have passwords turned off, and require keys to match. The zombie armies swarming outside are trying brute force attacks that in part involve guessing login NAMES. If they guess the wrong NAME, this is logged in syslog. If they guess a working user name, then the attack has PARTIALLY SUCCEEDED, but this information is IGNORED. That is, it is not logged. If the zombie army has tell when it has found a working user name, then it might concentrate on finding its key, and I will be none the wiser. I will not see that happening. >> >> I can get this info by turning logging to DEBUG, but then it is very noisy. I do not understand why failed attempts to login to my account are not logged. >> >> Why is this, and how do I get it fixed? > > Try verbose rather than debug.
On Thu, Oct 07, 2010 at 14:39:13 -0500, Perry Wagle wrote:> > LogLevel VERBOSE logs the ipaddress of the attempt on a "signon that > exists", but not which signon name. > > -- Perry > > On Oct 7, 2010, at 9:51 AM, Iain Morgan wrote: > > On Wed, Oct 06, 2010 at 18:07:29 -0500, Perry Wagle wrote: > > I have passwords turned off, and require keys to match. The zombie > armies swarming outside are trying brute force attacks that in part > involve guessing login NAMES. If they guess the wrong NAME, this is > logged in syslog. If they guess a working user name, then the > attack has PARTIALLY SUCCEEDED, but this information is IGNORED. > That is, it is not logged. If the zombie army has tell when it has > found a working user name, then it might concentrate on finding its > key, and I will be none the wiser. I will not see that happening. > > I can get this info by turning logging to DEBUG, but then it is very > noisy. I do not understand why failed attempts to login to my > account are not logged. > > Why is this, and how do I get it fixed? > > Try verbose rather than debug.Actually, the attempted username, source IP address, and source port are logged. This is done in auth.c. At least that is the case in cvs HEAD and looks like it goes back at least as far as 5.1p1. 273 274 authlog("%s %s for %s%.100s from %.200s port %d%s", 275 authmsg, 276 method, 277 authctxt->valid ? "" : "invalid user ", 278 authctxt->user, 279 get_remote_ipaddr(), 280 get_remote_port(), 281 info); 282 Note that in the case of password authentication, authlog is a pointer to logit(), whereas for all other authentication methods it is a pointer to verbose(). -- Iain
I rather see that it is logged whenever the last valid method fails.
So if you disable the password method, you still want to have that log
if the publickey method fails, even if it is not in verbose logging
Its pretty simple to implement that, just above that add 1 line.
if (authenticated == 1 ||
!authctxt->valid ||
authctxt->failures >= options.max_authtries / 2 ||
+ strcmp(method, "publickey") == 0 ||
strcmp(method, "password") == 0)
authlog = logit;
Hans
> Actually, the attempted username, source IP address, and source port are
> logged. This is done in auth.c. At least that is the case in cvs HEAD
> and looks like it goes back at least as far as 5.1p1.
>
> ? ?273
> ? ?274 ? ? ? ? authlog("%s %s for %s%.100s from %.200s port
%d%s",
> ? ?275 ? ? ? ? ? ? authmsg,
> ? ?276 ? ? ? ? ? ? method,
> ? ?277 ? ? ? ? ? ? authctxt->valid ? "" : "invalid user
",
> ? ?278 ? ? ? ? ? ? authctxt->user,
> ? ?279 ? ? ? ? ? ? get_remote_ipaddr(),
> ? ?280 ? ? ? ? ? ? get_remote_port(),
> ? ?281 ? ? ? ? ? ? info);
> ? ?282
>
> Note that in the case of password authentication, authlog is a pointer
> to logit(), whereas for all other authentication methods it is a pointer
> to verbose().
>
> --
> Iain
> _______________________________________________
> openssh-unix-dev mailing list
> openssh-unix-dev at mindrot.org
> https://lists.mindrot.org/mailman/listinfo/openssh-unix-dev
>