Host selection in ssh_config [SOLVED]

[Jean-Michel Elyn (MAILZ)]

Hello Iain,

First of all, I would like to thank you for your fast and synthetic 
reply, even giving other possibilities than the one I was looking for. 
I'm going to reply to all of them:

That's right, not checking host keys degrades security. However, being 
inside our organization provides a good protection against outside 
attacks; we rely on some specialists focused on that topic.

The first solution you gave, saving private-public keys of all our hosts 
seems to me not secure enough unless encrypted. But then the burden to 
manage is non negligible: Saving keys, encrypting them, backing them up, 
decrypting them on demand...

The second solution is the one we are currently using, saving the public 
key of each host in a central place, collecting all of them to make a 
common ssh_known_hosts file, then distributing this file to all hosts 
every day. This is boring to have to wait the day after when installing 
a host (we have more than one thousand computers running Linux). Or we 
need to manually run all the scripts to have few updated machines each 
time we (re-) install one.

The third solution seems interesting. Unfortunately the ssh-keygen we 
have on our distributions (derived from rhel4 and 5: openssh 4.3) does 
not include certificate options such as -I, -h or -s. Too old, too bad.

Finally the second approach seems to me the best one. Well, I suppose it 
can be a bit refined by forcing strong security when connecting to some 
important servers inside our organization, but that's one step ahead. I 
needed first to solve the difficulty I had.

I understood from your example that pattern list in Host line is space 
separated, not comma separated patterns. So if I write

Host *.our.domain xxx.yyy.*

it works well! This was one of my mistakes. Another one was I read help 
(ssh_config's man pages) from many sources but the one from our hosts 
does not tell anything about "!", because it must be a too old version. 
So finally I've got an ssh_config that works:

# 1) inside with FQN or IP address
Host *.our.domain xxx.yyy.*
   parameters for weak security

# 2) outside (of course with FQN)
Host *.*
   parameters for strong security

# 3) inside with no domain provided
Host *
   parameters for weak security

Thank you very much for your precious help to solve this problem.

Jean-Michel.


On 04/08/2011 07:24 PM, Iain Morgan wrote:
> 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.
>