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@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
Attachment:
signature.asc
Description: OpenPGP digital signature
_______________________________________________ openssh-unix-dev mailing list openssh-unix-dev@xxxxxxxxxxx https://lists.mindrot.org/mailman/listinfo/openssh-unix-dev
