Bug 475994

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.

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.

This package has changed ownership in the Fedora Package Database.  Reassigning to the new owner of this component.

This package has changed ownership in the Fedora Package Database.  Reassigning to the new owner of this component.

This package has changed ownership in the Fedora Package Database.  Reassigning to the new owner of this component.

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.

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.

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?

(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.

(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

(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".

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?

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.

(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.