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