[Feature Request] Add (and check against) IP to known_hosts even when domain is used to connect

Joshua Dietz jospam at dietz-ulm.de
Thu Mar 26 10:59:29 AEDT 2020

Hello Bob,

thank you for your reply and for reading of all of that.

Thank you for your detailed explanation of HostKeyAlias. This was very 
helpful although I think it is not a suitable solution for me. If 
there's no good option to achieve what I described I guess I'd prefer a 
dedicated IP Adress management tool like phpipam or something like that

> The "Alias" feature being "HostKeyAlias"??  Or something different.
Sorry! I was unclear again about what I meant. Here I talked about 
HostKeyAlias, yes.

> However for the configuration there is
> the Include directive.
I didn't read about that before so for the future I'll give it a closer 
look and I'm sure this will come in useful some day.

> For my tastes that seems to be more than I would want to use.
Thank you for your honest feedback on that.

> But hey
> if it works for you then I say go for it.
Yes but I guess that it's currently not possible in a useful way because 
of the problems described before

> However for a feature in a
> tool such as ssh my opinion is that the feature should be well
> defined, simple, and generic, whenever possible.
Absolutely! But to be honest I think the feature I requested meets this 
criteria. With all my descriptions I noticed myself that I almost forgot 
what I asked for in the first place: The option to resolve the host 
adress before checking against the known_hosts file.

Apart from what I want to do with it I think allowing a behavior like I 
described (resolving host before adding/checking) may even be more 
intuitive for many people. In my research before writing to this mailing 
list I found many forum entries where people found it unintuitive why 
the same server behaves almost like different servers depending on which 
host adress you use to ssh into it. It's a bit like a house which has a 
different adress depending on which door you use to enter it (well not 
really but I think the analogy may do it's job here anyway :-) )

Just to give another scenario where it may be of use to use the resolved 
host (=ip adress) as identity for picking the right host key from 

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)? 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.

> However for a feature in a
> tool such as ssh my opinion is that the feature should be well
> defined, simple, and generic, whenever possible.  Otherwise we end up
> with features so specific that we know they were written for kerberos
> and nothing else and other such things
I can't agree more. I absolutely hate these messes in the documentation 
and the discrepancy between documentation and real behavior found in 
many projects nowadays. So if a feature as requested by me would be 
implemented it would be essential to implement it in the most simple and 
generic way possible and also make clear what the use of the feature is. 
To make it concrete, I'd suggest something like this

Add a configuration option (and also a corresponding command line flag) 
named something like "ResolveHostBeforeKeyCheck". The description for 
the option could sound something like "If enabled hostnames are resolved 
to the corresponding ip adress before the existence of a corresponding 
fingerprint in known_hosts is checked. If the host is added to 
known_hosts with this flag enabled the host's ip adress is added instead 
of its hostname, even if a hostname was used to connect"

I could if you devs/project maintainers allow it also try to implement 
the feature myself and send it to the list to be pulled in. To be honest 
I most of the time do more high level stuff when it comes to programming 
so I'm not sure if I can do it but since this feature seems pretty small 
to me and I'm always willing to learn something new I'm willing to try. 
Unfortunately I could not find some kind of contribution guidlines for 
this project. Is it possible for the public to contribute? How do you 
decide which new features to accept and which patches to accept? How is 
your process for contributions? As far as it looked to me patches are 
sent to this mailinglist similar to how the linux kernel devs handle it, 

> Let me also comment on your nice effort to do the right thing with
> regards to mail responses.
Thank you for your explanation on that! I always like to hear how to do 
it right and why things should be done the way they should be done. So I 
really appreciate your effort on that. 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.

Kind regards


More information about the openssh-unix-dev mailing list