Useless log message "POSSIBLE BREAK-IN ATTEMPT"

Dan Mahoney, System Admin danm at prime.gushi.org
Sun Dec 29 08:09:50 EST 2013


On Sat, 28 Dec 2013, Philipp Marek wrote:

>>> That's not entriely true. from=... restrictions in authorized_keys
>>> and "Match host" sections in sshd_config depend on the hostname. In
>>> the reverse-mapping check failed case, they don't get to see the
>>> original (probably untrustworthy) hostname and are just passed the
>>> IP address.
>> Right, and that was my point -- if you have a bunch of "match host"
>> blocks, what do you put *outside* those blocks to just deny all
>> connections?  I don't see an option like "AllowUsers None" or
>> "DenyUsers All" or "DenyUsers *", at least according to the manpage.
>>
>> In theory you could disable all authentication methods, which will
>> cause login to fail, but there's no easy way to do an apache-style
>> "deny from all", which in theory should happen even without doing a
>> handshake in this situation.

> You can always just restrict to key-based authentication, and then say
> 	AuthorizedKeysFile /dev/null
>
> or use
> 	DenyUsers *

Hrmmm, yeah I suppose that is an allowed pattern, although I didn't quite 
grok that in the ssh_config manpage.  It should probably be added to 
sshd_config's manpage for the allowusers/denyusers section.

It's still a roundabout way to say "drop connection".  There's also not a 
good way to throw a message out in-band.  (In sendmail parlance, REJECT 
553 "Go Away")

At any rate, we're somewhat off-topic here, which I'll cover in another 
message in this thread.

-Dan

-- 

--------Dan Mahoney--------
Techie,  Sysadmin,  WebGeek
Gushi on efnet/undernet IRC
ICQ: 13735144   AIM: LarpGM
Site:  http://www.gushi.org
---------------------------



More information about the openssh-unix-dev mailing list