Joshua Dietz wrote:
> Imagine you had a webserver which you give the adress webserver.example.com
> (just for the purpose of management)
>
> Now you get more traffic and want to add another webserver. You give it the
> adress webserver2.example.com. Because you want to have them both named the
> same way you go into your DNS configuration and change webserver.example.com
> to webserver1.example.com (which is no problem since you use this names only
> to ssh into them). Isn't it unintuitive that this simple change in the dns
> settings lets it behave like a different server when ssh-ing into it again
> (because it asks you the yes/no question about the fingerprint again)?
Well... This assumes that an IP address is a canonical name for the
system. But it isn't. There are many issues generically with
treating it as a canonical name that may work perfectly well in some
cases but not in others.
For example I know several networks where they exclusively use DHCP +
Dynamic DNS to track server systems. Which should be stable. But
they are also using a Windows DHCP+DNS server. Then due to the way
they (mis)manage it they are routinely causing dhcp clients to spin
through addresses. Which shocks me as insane coming from a more
traditional, servers are stable, world. But they think that is just
fine. After all, the machine updates the dns when it dhcp's so
everything is fine, right? No one cares what the IP address of a
system is but just that the DNS resolves to it. In that situation
your known hosts file stored by IP address would become very
problematic as IP addresses get reused with different hosts. Of
course I am appalled that they don't maintain a robust DHCP
infrastructure to avoid this issue entirely.
There is also the issue of IPv4 versus IPv6. If I am using a mobile
device like my laptop and connecting from different networks then
there will always be at least two IP addresses for most servers.
Because I routinely connect to CenturyLink networks which do not
provide IPv6 addresses but only IPv4.
So far the name used to connect has been the best canonical name to
a system. "Do what the user said." If one connects to the same name
then that is the name that is verified against the associated known
host key. It's really more unusual for the case you mention, that one
is connecting to the same host by many different names. And even more
rarely renaming a host. Renaming a host is a big enough deal that one
might expect things like known hosts name changes to be handled with
the host rename. Along with renaming the DNS perhaps it should be
expected to edit the known hosts file and rename the entry there too.
> Sure this can be tackled with aliases, prepopulating known_hosts,
> probably the wildcard feature (*. example.com in known_hosts)
> etc. But anyway things could be more simple if you could just enable
> an option which tells ssh to always use the ip adress to find the
> right fingerprint in known_hosts - even if you used a hostname to
> connect to the server. I think this emphazises a bit more what dns
> really does: providing an easy-to-use alias for an ip adress.
I think it would be needed to have a mapping from the name given to
ssh to connect to and a canonical name for the system. You desire
that to be the IP address. Or at least one of the IP addresses.
Whereas historically ssh has used the name given to it to connect.
Note that I think it would be a bad idea to try to turn the host name
given into a FQDN by DNS lookup or other as people often try to do
these days. That has it's own many problems. Let's not do that.
As to an option to enable the behavior of canonicalizing to the
resolved IP address as you suggest, I don't have an opinion.
Note that I am not an OpenSSH developer. I am simply a user.
> Since I have the digest disabled now I just responded to the
> particular message ("Reply to List") and I hope that Thunderbird
> sets the In-Reply-To header the right way.
Worked perfectly! :-)
Bob
_______________________________________________
openssh-unix-dev mailing list
openssh-unix-dev@xxxxxxxxxxx
https://lists.mindrot.org/mailman/listinfo/openssh-unix-dev
