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@xxxxxxxxxxxxxxxxxxxxxxx
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
_______________________________________________
openssh-unix-dev mailing list
openssh-unix-dev@xxxxxxxxxxx
https://lists.mindrot.org/mailman/listinfo/openssh-unix-dev
