Human readable .ssh/known_hosts?

[Demi M. Obenour]

On 2020-09-30 20:38, Bob Proulx wrote:
> Nico Kadel-Garcia wrote:
>> Damien Miller wrote:
>>> Again, you should read the documentation for CheckHostIP. Turing it off
>>> makes known_hosts solely bind to hostnames and, as long as you use names
>>> to refer to hosts, avoids any problems caused by IP address reuse.
>>
>> Have you used AWS? Unless you spend the time and effort, the hostname
>> registered in AWS DNS is based on the IP address. Many people do *not*
>> use consistent subnets for distinct classes of server or specific OS
>> images, so different servers wind up on the same IP address with
>> distinct hostkeys based on factors like autoscaling, for which IP
>> addresses are not predictable. You can work around it, by locking down
>> and sharing hostkeys for your OS images, or by segregating subnets
>> based on application and corresponding OS image. These present other
>> burdens.
> 
> I use AWS and therefore will say a few words here.  The general
> default for an AWS EC2 node is that the hostname will look like this.
> 
>     root at ip-172-31-29-33:~# hostname
>     ip-172-31-29-33
> 
> And note that this is in the RFC1918 unroutable private IP space.
> That is not and cannot be the public IP address.  The public IP
> address is routed to it through an edge route.  It's mapped.  (And
> always IPv4 since Amazon has been slow to support IPv6 and AFAIK
> elastic IP addresses can only be IPv4 still to this day.)
> 
> And if one doesn't do anything then by default Amazon will provide a
> DNS name for it in their domain space.  In the case of the above it
> will be something like this.  [ Which I have obscured in an obvious
> way.  Do you immediately spot why this cannot be valid? :-) ]
> 
>     ec2-35-168-278-321.compute-1.amazonaws.com
> 
> So in an auto-scale-out elastic configuration one might create a node
> ip-172-31-29-33 at noon, might destroy that node by evening, and then
> tomorrow recreate the node again as ip-172-31-10-42 but with the same
> public IP address and associated amazonaws.com DNS name.
> 
> This host key collision with the AWS provided DNS name is only a
> problem if 1) one uses the AWS provided DNS name and 2) one uses a
> randomly generated ssh host key.  Avoiding this problem can be done by
> avoiding either of those two things.  I don't do either of them.
> 
> I don't use the AWS supplied DNS name.  I use my own DNS name in the
> my domain space.  However I know the stated problem was lack of
> control of the DNS.  Okay.  But note that anyone can register a random
> domain and and then have control of that namespace.  I have used my
> own domain name for my personal use when working with client systems.
> Nothing prevents this.
> 
> Also for an elastic node that is just a template produced machine then
> I believe that one should override the random ssh host key with a
> static host key appropriate for the role it is performing.  This can
> be done at instantiation time automatically using any of cloud-init or
> ansible or other system configuration tool.  Since it then has a
> repeatable host key for the role then it won't mismatch when
> connecting to it.  When re-created fresh it will have the same host
> key that it had before.  I do this.
> 
> In a previous life I used to manage a bare metal compute farm and when
> the machines are simply srv001 through srv600 and all exactly
> equivalent and smashed and recreated as needed then there is no need
> for them to have unique host keys.  That's counterproductive.  I set
> them all the same as appropriate for their role.
> 
> Bob

I strongly recommend switching to SSH certificates instead.  You can
write a program that provisions each node a certificate based on its
AWS-provided identity information, which is cryptographicly signed
by an AWS secret key and so cannot be forged.

Sincerely,

Demi

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 833 bytes
Desc: OpenPGP digital signature
URL: <http://lists.mindrot.org/pipermail/openssh-unix-dev/attachments/20200930/cda50303/attachment.asc>