Nicolas Williams wrote:
> On Fri, Oct 31, 2008 at 11:32:07AM -0400, Kyle McDonald wrote:
>   
>> Reading through the docs, I foudn that it's not seen as secure enough to 
>> be enabled by default, but in searching the web I haven't been able to 
>> find a real discussion of what the risks and/or concerns were, and what 
>> other steps can be taken to reduce or eliminate them.
>> Any thoughts?
>>     
>
> It's not that it's not secure, but that it has a different threat model
> than pubkey/gssapi-* and even password/keyboard-interactive userauth.
>
> The latter assume only that clients used by legitimate users aren't
> compromised by third parties.  The former assumes that trusted clients
> are not compromised at all, not even by legitimate users.
>
>   
Thanks Nico, That's the explanation I've been looking for.

So mainly if I trust the users to keep their accounts secure (good 
passwords, screen locks, etc.) then this is probably good enough. I know 
the users probably aren't good enough at that for 100% security, but in 
my case they're probably good enough at it for what it we're protecting.

Did I miss something?
> Also, the most difficult part of configuring host-based userauth is
> gathering all the trusted client host keys and making them available to
> all the servers.
>   
Yep. I'm working all of that out now also. I know how to distribute it 
once I collect it, but collecting it is the hard part.
Not to mention since many of my machines get re-installed often I've 
have to either re-install the old keys, or re-collect any new ones 
automatically. I think I have that sorted out too though.
> So if no one cared about the threat model difference it'd still be
> impossible for us to make sure that host-based userauth works out of the
> box -- the customer has to provide the list of known, trusted client
> host public keys, and the list of "equiv" hosts.
>
>   
That's true, it wouldn't work out of the box.

It wasn't really the Sun docs, but the other things I found on the web 
that seemed to imply it was less secure, and that you might be taking a 
risk using it. I just wasn't able to find any discussion of what those 
risks were, when it might be ok to take those risks, and what other 
steps could be taken to minimize those risks.


>> Reading the docs about the configuration settings that be set on this, I 
>> had decided to try this combo:
>>
>>       Protocol 2
>>       HostbasedAuthentication yes
>>       IgnoreRhosts yes
>>
>> There seem to be other (somewhat related) options, but unless I'm 
>> reading things wrong, they only apply to Version 1 of the protocol.
>>     
>
> sshd_config(4) says:
>
>      HostbasedAuthentication
>
>          Specifies whether  to  try  rhosts-based  authentication
>          with public key authentication. The argument must be yes
>          or no. The default is no. This option applies to  proto-
>          col  version 2 only and is similar to RhostsRSAAuthenti-
>          cation. See sshd(1M) for guidelines on setting up  host-
>          based authentication.
>
> ...
>
>      IgnoreRhosts
>
>          Specifies that .rhosts and .shosts files are not used in
>          authentication.  /etc/hosts.equiv  and /etc/shosts.equiv
>          are still used.  The  default  is  yes.  This  parameter
>          applies to both protocol versions 1 and 2.
>
> So that what you posted will work for SSHv2.
>
>   
Yep I knew those were only v2. And I knew the others I'd discovered were 
only v1 (RSAHostbasedAuthentication or something like that.)  I was 
asking if there were any other options I had missed that affect 
HostbasedAuthentication that you or other experts might recommend I add 
to the list above?

Thanks for the help!

  
-Kyle


Reply via email to