AllowUsers not working under certain conditions

[Carson Gaspar]

--On Friday, November 18, 2005 12:43:18 PM +0000 Donald Fraser 
<demolish at kiwi-fraser.net> wrote:

> If security is what is at stake here then in order to user the software in
> the same way I am now, in fact, forced to reduce my level of security.
> Before I could use the option:
> AllowUsers Auser@*.somedomain.com
> One has to admit that, whilst having reverse mappping turned off, this is
> far more secure than the option I'm now forced to use to achieve the same
> of:
> AllowUsers Auser@*
>
> Does anybody know whether the VerifyReverseMapping option is going to be
> put back and what the reason for removing it in the first place was?

The OpenSSH developers tend to not allow people to do things that aren't 
secure (thus removal of the NONE cipher, etc.). Personally, I disagree with 
this "mother knows best" attitude, but I do understand it.

Trusting DNS for access control is A Very Bad Idea. Doing so without 
verifying that the name hasn't been spoofed is just insane. I wouldn't 
allow Auser@*, I'd require Auser to fix his or her broken DNS (or switch 
ISPs), but then I'm a BOFH ;-)

Can you please describe the problem you're trying to solve? I solved 
something that I _think_ is similar by writing the auth vector patch, and 
required HostBasedAuth before a user could enter a password. I was 
attempting to prevent brute force password guessing attacks from random 
Internet hosts. Sadly that patch would now probably have to be re-written 
from scratch, as the code has changed a fair amount.

Assuming some similar patch were written, it would be sensible to use the 
name presented as part of HostBasedAuth for use with AllowUsers. This would 
give you the granularity you appear to want, with some actual security. It 
_would_ require maintaining the remote hosts' public keys on your server, 
however.

-- 
Carson