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