Bug 475994

Summary: ssh client should know key of .local servers
Product: [Fedora] Fedora Reporter: Bastien Nocera <bnocera>
Component: opensshAssignee: Jan F. Chadima <jchadima>
Status: CLOSED NEXTRELEASE QA Contact: Fedora Extras Quality Assurance <extras-qa>
Severity: medium Docs Contact:
Priority: low    
Version: rawhideCC: lpoetter, mgrepl, tmraz
Target Milestone: ---Keywords: FutureFeature, Reopened
Target Release: ---   
Hardware: All   
OS: Linux   
Whiteboard:
Fixed In Version: Doc Type: Enhancement
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2011-04-22 05:44:07 EDT Type: ---
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Bug Depends On: 475996    
Bug Blocks:    

Description Bastien Nocera 2008-12-11 09:06:23 EST
When connecting to a .local SSH server, one will usually get warnings from SSH about the keys not matching the IP address, or some such.

SSH servers usually export the public key through the TXT record, so the ssh client should be using that data.
Comment 1 Tomas Mraz 2008-12-11 12:29:08 EST
What do you mean by .local server? Surely ssh could at least look up the TXT record and display its contents to the user to decide but this feature should be implemented upstream first.
Comment 2 Bastien Nocera 2008-12-17 09:47:22 EST
A server in the .local domain, of which the service is advertised through mDNS/Zeroconf/Bonjour (in our case, through Avahi).

See the output of "avahi-browse -a" on a network with MacOS X machines to see the services advertised.
Comment 3 Fedora Admin XMLRPC Client 2009-03-10 05:20:29 EDT
This package has changed ownership in the Fedora Package Database.  Reassigning to the new owner of this component.
Comment 4 Fedora Admin XMLRPC Client 2009-03-10 06:17:39 EDT
This package has changed ownership in the Fedora Package Database.  Reassigning to the new owner of this component.
Comment 5 Fedora Admin XMLRPC Client 2009-03-10 06:19:36 EDT
This package has changed ownership in the Fedora Package Database.  Reassigning to the new owner of this component.
Comment 6 Jan F. Chadima 2010-06-07 04:22:45 EDT
I'm not sure if the automatic upload of the .local server keys is not the security risk, I'm think that it's may be, so I prefer trat this topic would be discussed on upstream maillist.
Comment 7 Bastien Nocera 2011-03-29 13:37:17 EDT
Except that I'm not an upstream contributor to openssh, and I don't know the community either. If you can point out an bug tracking system, I'll gladly file a bug there.
Comment 8 Lennart Poettering 2011-03-29 14:01:00 EDT
Hmm, I don't think reading the data from TXT would be anymore secure than completely ignoring it. Hence my recommendation: make the ssh client ignore the keys from all hosts within the .local domain, since those are most likely hosts with dynamically assigned IP addresses.

We could implement such a logic in the Fedora packages without any upstream support even, with something like this in /etc/ssh/ssh_config:

Host *.local
        CheckHostIP no
        StrictHostKeyChecking no
        UserKnownHostsFile /dev/null

This would just be the default config, and if people don't like this they could comment it.

Does that make sense to you?
Comment 9 Jan F. Chadima 2011-03-29 14:25:38 EDT
(In reply to comment #8)
> We could implement such a logic in the Fedora packages without any upstream
> support even, with something like this in /etc/ssh/ssh_config:
> 
> Host *.local
>         CheckHostIP no
>         StrictHostKeyChecking no
>         UserKnownHostsFile /dev/null
> 
> This would just be the default config, and if people don't like this they could
> comment it.
> 

This change lower the security of the ssh to the security of the widely open hole.
Ssh without known host checking is nonsense.
Comment 10 Jan F. Chadima 2011-03-29 14:29:58 EDT
(In reply to comment #7)
> Except that I'm not an upstream contributor to openssh, and I don't know the
> community either. If you can point out an bug tracking system, I'll gladly file
> a bug there.

bugzilla.mindrot.org
Comment 11 Lennart Poettering 2011-03-29 15:24:51 EDT
(In reply to comment #9)
> (In reply to comment #8)
> > We could implement such a logic in the Fedora packages without any upstream
> > support even, with something like this in /etc/ssh/ssh_config:
> > 
> > Host *.local
> >         CheckHostIP no
> >         StrictHostKeyChecking no
> >         UserKnownHostsFile /dev/null
> > 
> > This would just be the default config, and if people don't like this they could
> > comment it.
> > 
> 
> This change lower the security of the ssh to the security of the widely open
> hole.

Would it?

> Ssh without known host checking is nonsense.

Why?

This config snippet does not turn it off for any host, except for those in the mDNS/DNS-SD domain ".local". For those hosts host key checking is completely useless, since IP addresses are dynamicly assigned (i.e. via DHCP or IPV4LL), and hostnames are dynamic too (they are allocated dynamically via mDNS, and can be changed dynamically and remotely simply by triggering a name conflict in which case the mDNS protocol automatically ensures to rename one of the hosts. On Fedora the public hostname is usually "linux" unless changed manually, which means a name conflict is almost guaranteed and you end up with a name like "linux7.local" if you have 7 machines on your LAN).

Hence: the address of a machine in .local is completely dynamic and can trivially be changed remotely just by forging a mDNS or DHCP packet. Hence host key checking is worthless, since it tries to identify an address with a host key, but the address is practically randomized and remotely changeable.

Host key checking makes sense for hostnames where you have a bit of trust in the IP address asignment, or in the hostname assignment. This does not exist for the mDNS/DNS-SD domain .local, hence the smart thing is to just disable it there, to stop annoying the user.

I am not asking you to disable host key checking for all hosts. Just for those in the mDNS/DNS-SD domain .local. That's without risk.

Note that the mDNS/DNS-SD domain .local is relevant only in local LANs. Avahi goes into great lengths to ensure that information cannot leak from remote networks into .local and local information cannot leak into other networks. It is only useful for identifying hosts in trusted, local networks. The emphasis is on "trusted".
Comment 12 Tomas Mraz 2011-03-29 15:50:37 EDT
I think the 'CheckHostIP no' would be appropriate for .local domain. However disabling the known host checking completely means that you can just use telnet anyway. (OK OK I know that you would have to be a MITM and not just eavesdropper if you would like to attack ssh without known host checking.)

I think that shooting themselves to the foot should be reserved for the user's if they insist on doing it.

By the way how do you ssh to a machine that has completely dynamic DNS and IP - how do you know what machine do you connect to? And couldn't the dns be generated somehow less dynamically with lower probability of conflict?
Comment 13 Jan F. Chadima 2011-03-29 16:05:29 EDT
Even in local network should be "some" security. The approach with  'CheckHostIP no' seems to me reasonable. I recommend to add it to the sshd config commented to point the users to not switch off whole known hosts mysterium.
Comment 14 Lennart Poettering 2011-03-31 08:16:11 EDT
(In reply to comment #12)

> By the way how do you ssh to a machine that has completely dynamic DNS and IP -
> how do you know what machine do you connect to?

There's this wonderful tool called "bssh" in avahi-ui-tools. It shows you a quick UI you can select an ssh host on the local network from. Incredibly useful if you juggle with a lot of lab machines on your LAN or a lot of VMs.