openssh unix dev - Mar 2020 - [Feature Request] Add (and check against) IP to known_hosts even when domain is used to connect

Hello Bob and thank you for your reply,

first of all I hope that I'm answering in the right way since I had 
enabled the daily digest and I'm not sure if it's the right way to use 
Thunderbirds "Reply List" feature on this digest. If it's wrong
this way
I apologize. I turned of the daily digest so my next messages should be 
correct.
> Are you aware of HostKeyAlias?
Yes I read that but as far as I understand the feature is more like 
aliasing commands in linux (so i.e if I have a server which I use as 
webserver I could create the alias "webserver", configure the
hostname,
port etc. and then just use the alias "webserver" instead of typing
the
whole line with port etc. OpenSSH will then act as if I typed everything 
like it's saved in the alias configuration. So if I understood that 
right I don't really see how this helps me with my specific problem.
> Regardless of other things, for a set of servers I recommend using
> ssh-keyscan to pre-populate the known_hosts file.
Yea you're right. Currently my approach is far from perfect (I currently 
just rely that everything is correct when first connecting to a newly 
created server)
> but it isn't clear to me where you were thinking
> of those wildcards.
By wildcards I meant the feature to change the entry in known_hosts to 
*.mydomain.com which would match this hostkey to the ssh commands 
webserver.example.com, database.example.com etc.
> An example name or two to help us understand the type of naming you
> are using would help make this more concrete.
Sure, here you go (just a made-up example):

Imagine I have two servers, Server A has the ip AA.AA.AA.AA, Server B 
has the ip BB.BB.BB.BB

I have to following services running on A:

- Webserver for website 1

- Mailserver

- Database for the Website

And the following on B

- Some backend in node

- an gitlab instance

- gitlab database

- Webserver for website 2

Further I have the domain mydomain.com

Now I would create the following dns records:

webserver.mydomain.com A-Record with content AA.AA.AA.AA

mailserver.mydomain.com A-Record with content AA.AA.AA.AA

[...]

node-backend.mydomain.com A-Record with content BB.BB.BB.BB

gitlab.mydomain.com A-Record with content BB.BB.BB.BB

[...]

If I had to add another service I would install it on one of the servers 
and then I would create a respective record and from there on I could 
connect to the server running the service by using its respective dns 
name (i.e. if I'd like to ssh into the server running the mailserver I'd
just type ssh username at mailserver.mydomain.com

Until now it sounds like something easy to accomplish with the Alias 
feature. *But* this has a few disadventages to me:

- It requires a client side configuration which would need to be synced 
between multiple clients (i.e. laptop, pc)

- It requires to make a change (and resync to all my devices) this 
config when I move a service to another server instead of just changing 
the DNS settings which are automatically in sync

- My end-goal goes even further (I left that out in the first mail 
because it makes everything sound way more complex but I'll try to 
explain it briefly now:)

What I really want to create in the end is something like this:

A service (probably web based). Let's say it has the domain 
myservice.net. At the beginning I want to use the service just for me, 
later users shall be able to create a subdomain on this service (for 
free), i.e. username.myservice.net.

Then they shall be able to add their servers (so it's ipv4 and/or ipv6 
ips) like they would add A and AAAA records in every normal DNS service. 
The special thing is that they can add a description for every server. 
This may be keywords or even a short text summarizing all services 
running on the server.

The special thing is a custom designed DNS server (which I already 
started to implement since I did not knew that known_hosts does not save 
the ip but instead the hostname to check a servers fingerprint).

This DNS server implements a feature that I'd call "search by
DNS". I
think I should explain it with the example from above.

So Imagine I created the subdomain joshua.myservice.net on the service

Then I'd add my servers A and B with its respective ip adresses 
AA.AA.AA.AA and BB.BB.BB.BB

For server A the description could look like this: "This server runs a 
webserver for website 1, a mailserver and the respective database for 
the website"

And server B's description could look like "This server runs the node 
backend, the gitlab instance, the respective database for gitlab and the 
webserver for website 2"

Now I want to be able to use all subdomains under joshua.myservice.net 
as a search-query which resolves to the respective server as soon as the 
search has exactly one result (this is what the custom DNS server 
implements)

So i.e. I could type ssh username at git-database.joshua.myservice.net

Since only the description of Server B contains the words "git" *and* 
"database" this is the only server matching the search term and so
it's
resolved to the IP of server B, BB.BB.BB.BB

*But* (and this is why I think wildcards and aliases are not suitable 
for this) the same search could also look like this:

database.gitlab.joshua.myservice.net OR gitlab-data.myservice.net and so 
on.

So there is an infinit number of hostnames for each server. Also since 
many users could use the service and it (or one of the servers) *could* 
be hacked I don't want to use a wildcard like *.joshua.myservice.net. 
(what I mean by wildcard is explained above) This would open an attack 
vector like described here (https://superuser.com/a/1328615/933511) 
(under heading "security caveat")

In my opinion a service like this could be really useful (at least for 
me) but I don't think that it would be usable if it opens up even a 
small attack vector or if it requires more then one small client-side 
configuration change.

So as far as I can see the only option to make this useful and keep it 
secure would be if there was an option like I described to add (and 
check) hostkeys by ip even if a hostname is used to connect.

Sorry for the long message, it's pretty hard for me to explain it in 
detail in english


Thank you for your time again

Kind regards

Joshua

Joshua Dietz wrote:
> > Are you aware of HostKeyAlias?
>
> Yes I read that but as far as I understand the feature is more like
aliasing
> commands in linux (so i.e if I have a server which I use as webserver I
> could create the alias "webserver", configure the hostname, port
etc. and
> then just use the alias "webserver" instead of typing the whole
line with
> port etc. OpenSSH will then act as if I typed everything like it's
saved in
> the alias configuration. So if I understood that right I don't really
see
> how this helps me with my specific problem.
     HostKeyAlias
             Specifies an alias that should be used instead of the real host
             name when looking up or saving the host key in the host key
             database files and when validating host certificates.  This
             option is useful for tunneling SSH connections or for multiple
             servers running on a single host.

Let me "use it in a sentence" for the context.  Let's say I can
access
a host using any of three different names.  Let's say these are all
the same host.

  ssh foo
  ssh foo.example.com
  ssh foo.example.net
  ssh foo.example.org

Then in each case I would get a prompting about the host
authenticity.  In each case it would get a separate line stored into
the known_hosts file for the hostname as gave it on the command line.
That could be four in the above lines.  But I can consolidate them
with this ssh configuration.  My choice would be to store it as the
actual hostname of the system.

  Host foo.example.com foo.example.net foo.example.org foo
    HostKeyAlias sugarbombs

With that configuration in place all four of the example ssh commands
would be mapped into one known_hosts file line using the name
"sugarbombs" for the name instead of the one that was used on the
command line.

  sugarbombs ecdsa-sha2-nistp256 AAAAE2V...

Another very typical case is where port forwards from some gateway
machine is used to access other hosts behind it.  (Newer ssh includes
a ProxyJump configuration but I am going to describe the -W option
which has been supported for longer.)

  Host myprivatesystem
    Port 27788
    Hostname shell.example.com  

  ssh myprivatesystem

The result would be this stored in the known_hosts file.

  [shell.example.com]:27788 ecdsa-sha2-nistp256 AAAAE2V...

Again if the same host is accessed multiple different ways then this
is stored in those different ways.  Using HostKeyAlias allows this to
be stored in a canonical name.

  Host myprivatesystem
    Port 27788
    Hostname shell.example.com  
    HostKeyAlias myprivatesystem

  myprivatesystem ecdsa-sha2-nistp256 AAAAE2V...
> > but it isn't clear to me where you were thinking
> > of those wildcards.
>
> By wildcards I meant the feature to change the entry in known_hosts to
> *.mydomain.com which would match this hostkey to the ssh commands
> webserver.example.com, database.example.com etc.
Ahh...  I see.  Thanks.  I was thinking of this following use instead.
> > An example name or two to help us understand the type of naming you
> > are using would help make this more concrete.
>
> Sure, here you go (just a made-up example):
...
> Now I would create the following dns records:
>  webserver.mydomain.com A-Record with content AA.AA.AA.AA
>  mailserver.mydomain.com A-Record with content AA.AA.AA.AA
>  node-backend.mydomain.com A-Record with content BB.BB.BB.BB
>  gitlab.mydomain.com A-Record with content BB.BB.BB.BB
> 
> If I had to add another service I would install it on one of the servers
and
> then I would create a respective record and from there on I could connect
to
> the server running the service by using its respective dns name (i.e. if
I'd
> like to ssh into the server running the mailserver I'd just type ssh
> username at mailserver.mydomain.com
I would try something like this ssh configuration.

  Host webserver.mydomain.com webserver
    HostKeyAlias AA.AA.AA.AA
  Host mailserver.mydomain.com mailserver
    HostKeyAlias AA.AA.AA.AA
  Host node-backend.mydomain.com node-backend
    HostKeyAlias BB.BB.BB.BB
  Host gitlab.mydomain.com gitlab
    HostKeyAlias BB.BB.BB.BB

Those could be further compacted but the above is how I would do it.
I also tend to specify both the FQDN and the short name so that either
are available and both combine to the same host.  That's just my
personal preference.
> Until now it sounds like something easy to accomplish with the Alias
> feature. *But* this has a few disadventages to me:
The "Alias" feature being "HostKeyAlias"??  Or something
different.
> - It requires a client side configuration which would need to be synced
> between multiple clients (i.e. laptop, pc)
> 
> - It requires to make a change (and resync to all my devices) this config
> when I move a service to another server instead of just changing the DNS
> settings which are automatically in sync
Unfortunately yes that being a client side configuration that if you
have multiple clients then the configuration would need to be updated
and kept in sync across the multiple clients.  The same is true for a
global ssh_known_hosts file.  However for the configuration there is
the Include directive.

           o   Include /etc/ssh/ssh_config.d/*.conf

     Include
             Include the specified configuration file(s).  Multiple pathnames
             may be specified and each pathname may contain glob(7) wildcards
             and, for user configurations, shell-like '~' references to
user
             home directories.  Files without absolute paths are assumed to be
             in ~/.ssh if included in a user configuration file or /etc/ssh if
             included from the system configuration file.  Include directive
             may appear inside a Match or Host block to perform conditional
             inclusion.

One could pretty easily keep one master copy of the file and then sync
that one file out easily.  Including it in with other locally
different configuration.  That would be pretty easy to keep in sync.

Also there are tools that can automate the sync.  Not just the
excellent rsync but also unison and syncthing and such.  With your web
server you could easily wget/curl a master file to the local system.
> - My end-goal goes even further (I left that out in the first mail because
> it makes everything sound way more complex but I'll try to explain it
> briefly now:)
For my tastes that seems to be more than I would want to use.  But hey
if it works for you then I say go for it.  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. :-)
> Sorry for the long message, it's pretty hard for me to explain it in
detail
> in english
I found it useful to read your vision of your end goal.  Thanks for
the description.  Even though it wasn't something I would personally
be wanting.

Let me also comment on your nice effort to do the right thing with
regards to mail responses.  This is about email and not about ssh.
Everyone who does not care, please stop reading here and skip on to
the next message.
> first of all I hope that I'm answering in the right way since I had
enabled
> the daily digest and I'm not sure if it's the right way to use
Thunderbirds
> "Reply List" feature on this digest. If it's wrong this way I
apologize. I
> turned of the daily digest so my next messages should be correct.
You have done better than most people responding to a digest.  Let me
give you a gold star for the result!  It was very good.  :-)

An absolutely perfect response (which I have not seen in my memory) is
to include an In-Reply-To: header that lists the Message-Id of the
message you are replying to.  That would thread the messages together,
in threaded mail reader.  And also a References: header, which is
similar but includes all previous message ids seen so far.

But since Gmail has most people-share these days and Gmail sorts by
Subject line (they call it by conversation, the same as MS-Outlook did
previously) most people will see it grouped together because the
subject is the same.  Since I am using a threading mail reader I see
the message as starting a new thread.

Most people fail by leaving the original digest subject and leaving
the original digest body text that says to remove it and change the
subject when replying.  Unfortunately I see that too often.

You also did the best thing possible.  You switched off digest mode so
that everything is just normal in the future. :-)

Back in the old days I remember some few mail readers having the
ability to "burst" a digest apart into individual messages where they
could be replied to individually.  Specifically I remember Elm having
that capability.  That made reading and replying to digests easy.
Because one of the initial reasons for a digest was so that three
dozen emails would not cause three dozen individual phone calls to be
made to transfer the email individually over UUCP as they came in
slowly over time over a phone modem line.  In that time using digests
can be more efficient by grouping them into one transfer.  But those
days are long past now.

Bob

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 
known_hosts

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, 
right?

> 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

Joshua