[pxc]

Amazon Linux does something sort of like this, which I guess is 'production quality', meaning much more complex. It annoys me on older versions of Amazon Linux (2 and earlier) because it involves (among other things) an invocation of the openssl CLI to verify the format of individual keys in the authorized keys file that is hardcoded to use RSA, so you can't authenticate to Amazon Linux 2 hosts using ed25519 even though the version of OpenSSH on them supports it.

In theory it's kinda nice because it can let you do fancy things¹, but my actual experiences with it breaking basic functionality even for people who don't use those fancy things has ultimately made me trust Amazon Linux less.

It was especially frustrating because when I first encountered this, I was trying to SSH into a box owned by one of our cloud-first DevOps guys. I couldn't diagnose the box because I didn't have hands on it. He couldn't diagnose the issue because he knows AWS better than he knows Linux and didn't know where to look. He'd chosen Amazon Linux because it's by the owner of the cloud platform, so it must be 'more compatible', right? But here, 'more compatible' actually meant 'more full of stupid surprises'.

Bleh.

--

1: https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/connect-...

[Shadowmist]

Use AWS SSM with something like Leapp.

[pxc]

Thanks for the tip! I will probably learn and play with SSM at some point.

As it is, I'm much the opposite of our cloud-first DevOps guys: I know how to operate Linux a lot better than I know how to operate AWS. That makes yours a more intimidating proposition to me.

At the same time, this particular box was a shortlived VM that was already behind a VPN, my organization already has tentative plans to implement a different network access system than SSM, it won't be my project to execute, and I don't get to be in the room for architecture decisions related to it.