Re: UpdateHostkeys now enabled by default

[Date Prev] [Date Next] [Thread Prev] [Thread Next] [Date Index] [Thread Index]

 



Damien Miller <djm@xxxxxxxxxxx> writes:

> On Sat, 3 Oct 2020, Mark D. Baushke wrote:
> 
> > UpdateHostkeys is an interesting feature. I hope you plan to document it
> > somewhat better in the ssh_config.5 file than is currently present?
> >
> > My reading of the documentation is that it is ambiguous as to the
> > following:
> >
> >   if StrictHostKeyChecking=yes and UpdateHostkeys=yes
> >   which option wins?
> >
> >   (My vote is that StrictHostKeyChecking=yes wins every time.)
> 
> They are almost completely separate:
> 
> StrictHostKeyChecking controls the circumstances under which a hostkey
> is accepted.
> 
> UpdateHostkeys controls whether to try to learn additional hostkeys
> for a host with an already trusted host key.
>
> The small point of interaction is when StrictHostKeyChecking=no and
> the user elects to continue past a changed hostkey. I'll double-check
> to make sure that UpdateHostkeys gets turned off along the other options
> that are disabled in this case.

Okay. I do think that the man page should be updated to tell the user
how these switches interact.

> >   If the hostkey that matches is found in GlobalKnownHostsFile, then I
> >   hope that the UpdateHostKeys is NOT used to update the
> >   UserKnownHostsFile ...
> >
> >   My vote is to assume that the GlobalKnownHostsFile is being properly
> >   managed and maintained for the listed hosts and UpdateHostKeys would
> >   be ignored in this case.
> 
> Good point. I'll implement this.

Thank you very much.

> >   I am unclear what happens with UpdateHostKeys when the key is found
> >   via DNS SSHFP and the use of VerifyHostKeyDNS settings.
> >
> >   My vote is that if the key is found in DNS SSHFP records, the
> >   UpdateHostKeys does NOT get used to add to the UserKnownHostsFile.
> 
> Another good point. I'll do this too :)

Thank you very much.

> >   How do CheckHostIP=yes and UpdateHostKeys play together?
> >   It is not clear to me if the HostIP fingerprints AND the Hostname
> >   fingerprint recards are BOTH to be added via the UpdateHostKeys
> >   directive or not.
> 
> They should play just fine (modulo bugs like the one Matthieu reported).
> Keys learned by UpdateHostKeys should behave exactly like ones learned
> by TOFU with respect to CheckHostIP and HashKnownHosts.

Yes. I had not cosidered how HashKnownHosts would work or what happens
with both IPv4 and IPv6 hostnames.

There may be one additional edge condition, when the host is actually a
bastian host that has an internal NAT'ed IP address and an external IP
address. Things like that get tricky when CheckHostIP=yes and an
UpdateHostKeys may only update the currently visible IP address even
though the user has previously added the old key for both IP addresses
manually. I still need to think about how that one should work.

Of course, there is another edge case I run into which is where the
hostname is using DynDNS with a dynamic IP address where I would rather
it NOT record the IP address for a particular subdomain of hosts or need
to explicity override config optios on the command-line.

	Be safe, stay healthy,
	-- Mark
_______________________________________________
openssh-unix-dev mailing list
openssh-unix-dev@xxxxxxxxxxx
https://lists.mindrot.org/mailman/listinfo/openssh-unix-dev



[Date Prev] [Date Next] [Thread Prev] [Thread Next] [Date Index] [Thread Index]

[Index of Archives]     [Linux ARM Kernel]     [Linux ARM]     [Linux Omap]     [Fedora ARM]     [IETF Annouce]     [Security]     [Bugtraq]     [Linux]     [Linux OMAP]     [Linux MIPS]     [ECOS]     [Asterisk Internet PBX]     [Linux API]

  Powered by Linux