Joshua Dietz
2020-Mar-24 15:23 UTC
[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
Bob Proulx
2020-Mar-24 20:22 UTC
[Feature Request] Add (and check against) IP to known_hosts even when domain is used to connect
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.comI 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 syncUnfortunately 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 englishI 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
Joshua Dietz
2020-Mar-25 23:59 UTC
[Feature Request] Add (and check against) IP to known_hosts even when domain is used to connect
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 thingsI 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