| 14 Oct 2024 |
 Arian | hmm one with that worries me with AuthorizedKeysCommand for the main ssh key is
http://blog.champtar.fr/Metadata_MITM_root_EKS_GKE/
i.e. EC2 instance connect goes out of its way to protect against a rogue IMDS. But the normal ssh key does not | 13:48:06 |
| Arian | idk if this is really in scope... | 13:48:12 |
| Arian | I just find it interesting that EC2 instance connect goes all the way to protect against such attacks | 13:48:24 |
| Arian | but then the normal SSH key doesn't get protected by this at all | 13:48:32 |
| 15 Oct 2024 |
 commiterate | I wouldn't be surprised if it were on the backlog or if they view the EIC certs from IMDS also providing proof that the EC2 Key Pair is also probably safe | 06:34:32 |
| commiterate | though they don't encrypt the SSH keys and require you to use the certs to decrypt the ciphertext, so... | 06:35:10 |
| commiterate | at least that's my understanding, but the existing EIC AuthorizedKeysCommand Bash scripts aren't the easiest to read | 06:35:41 |
| commiterate | Might be interesting for people who use Nix on non-NixOS EC2 instances (e.g. macOS): https://github.com/DeterminateSystems/nix-installer/issues/1235 | 06:37:05 |
| commiterate | * I wouldn't be surprised if it were on the backlog or if they view the EIC certs from IMDS also providing proof that the EC2 Key Pair from IMDS also hasn't been tampered with | 06:39:01 |
| commiterate | * at least that's my understanding and what that security finding points out, but the existing EIC AuthorizedKeysCommand Bash scripts aren't the easiest to read | 06:45:23 |
| commiterate | * at least that's my understanding and what that security finding outlines, but the existing EIC AuthorizedKeysCommand Bash scripts aren't the easiest to read | 06:45:31 |
| commiterate | even if they did encrypt the keys with the cert, it would still be vulnerable to MITM since it can just replace all IMDS responses | 06:46:28 |
| Arian | I think the trick here is maybe to point to flakehub? | 09:53:30 |
| Arian | Note there's a determinate systems discord. I'd suggest discussing a bit there | 09:53:50 |
| Arian | P.S. MacOS is such a pain on EC2 holy moly | 09:54:18 |
| Arian | You have to install NixOS on the (unsupported) instance store | 09:54:43 |
| Arian | * You have to install Nix on the (unsupported) instance store | 09:54:51 |
| Arian | and I have had several occasions where the instance store is just... broken | 09:55:02 |
| Arian | Installing nix on the EBS volume isn't possible automatically. You need to do a GUI step | 09:55:20 |
| Arian | I've wasted days and hours of my life on this at work | 09:55:37 |
| Arian | and any time you make a mistake; AWS will take around 3-8 hours to reboot the machine | 09:55:49 |
| Arian | it's the most frustrating, painful product I have ever used | 09:56:03 |
| Arian | no you're not as you dont have control over amazon's certificates | 10:07:56 |
| Arian | that's why you cant spoof EIC keys (after they fixed the vuln in the post) | 10:08:09 |
| Arian | but the root key is just plopped on disk by cloud-init without any checks | 10:08:22 |
| Arian | I guess you're "protected" because cloud-init does this on first boot and then leaves it alone | 10:08:41 |
| Arian | But my problem is you want to replace with with a ProxyCommand which makes it a continuous risk. EIC has hardening agaisnt this by signing the payloads with an AWS Cert. but the main SSH key doesnt have this protection | 10:09:18 |
| Arian | The fact that the key is written to disk only once at bootup is kind of a security feature in this way | 10:09:40 |
| Arian | as later IMDS spoofing doesn't lead people to be able to change the key | 10:09:53 |
| Arian | EIC doesn't have this issue due to the Certificate being in play and not being able to spoof the IMDS payload | 10:10:15 |
