On Fri, Apr 08, 2011 at 08:24:32 -0500, Jean-Michel Elyn (MAILZ)
wrote:> Hello there,
>
> I'm a little afraid of writing here, hope I don't make any mistake
doing
> so. I'm trying for days and searching the web too, but no obvious
> solution, no reply from the specialized forum I wrote in.
>
> Here is the situation:
> I would like to have a lighter security inside our domain, without
> changing when going outside. By "lighter security" I mean at
least, no
> host key check; we often install and re-install hosts and managing all
> that public keys is heavy. Then my goal is to have two different
> configurations when targeting a host:
Before going any further, it should be pointed out that disabling the
host key checking _significantly_ degrades the security of SSH. I would
stongly recommend that you consider the other side of the problem:
Simplifying the management of host keys.
There are basically three approaches to this issue:
- Ensure that host keys are preserved across system upgrades/reinstalls,
i.e. save the keys prior to an install and restore them afterwards.
- Providing a centralized location for distributing an 'official'
ssh_known_hosts file for your domain. The file could be updated either
via an automated process (using ssh-keyscan) or manually. Systems
could periodically retrieve the ssh_known_hosts file via wget,
cfengine, etc.
- Host certificates might also be an option. (This assumes that both the
the clients and servers are running a recent enough version to support
certificates.) In this case, the host key (and certificate does not
need to be preserved across system installs. A new cettificate can
simply be generated for the system when needed. The advantage that
this method has is that maintenance of the ssh_known_hosts file is
minimal.>
> * inside our domain: "StrictHostKeyChecking no" and
"UserKnownHostsFile
> /dev/null".
> * into the Wild: "StrictHostKeyChecking yes" and
"UserKnownHostsFile
> ~/.ssh/known_hosts".
>
> And now my problem:
> The easiest way to sort target hosts, I thought, was to select our
> domain in ssh_config:
>
> # inside
> Host *.our_domain
> parameters
> # outside
> Host *
> parameters
>
> However, the hostname used is the one written in the command, I suppose:
> "ssh a_host.our_domain" works fine! But "ssh a_host"
does not. Of course
> we all avoid writing our domain. So I wanted to check whether a domain
> is provided (a point "." should exist):
>
> # inside
> Host !*.*
> parameters
> # outside
> Host *
> parameters
>
> Unfortunately it doesn't work... I tried many other possibilities but
> all failed. Is there a solution to that problem? If yes how to do? If
> not is it a bug? Thanks for your help.
>
> Jean-Michel.
> _______________________________________________
The second approach (with Host *.* and Host *) should work. However, you
might want to also include a Host *.your.domain section in case a local
FQDN is used. Note also that if you have occasion to ssh to an explicit
IP address, the Host *.* section would be used unless you have made
other provisions. You might want something like:
Host *.your.domain xxx.yyy.zzz.*
blah blah
Host *.*
blah blah
Host *
blah blah
Note that ssh uses the first instance of an applicable parameter, not
simply the parameters from the first applicable section. Thus if you set
some parameters in the Host * section, you will want to explicitly set
those parameters in the other sections as well. For example, if you set
UserKnownHostsFile in the Host * section. You will need to explicitly
set it in the other sections.
--
Iain Morgan