Unable to access instance with ED25519 key

[ethanchowell]

I'm using pre-built spel images in a AWS GovCloud environment as a base image for other Packer builds. When I create the instance using an RSA key, I'm able to ssh in as maintuser without issue. If however I use an ED25519 based key, I'm unable to login and am prompted for a password instead.

Expected behavior

I can create an instance using an ED25519 key and use that key to ssh in without a password.

Actual behavior

I'm prompted for a password and unable to login

Steps to reproduce behavior

Create an EC2 instance using a spel-minimal-rhel-7-hvm-*.x86_64-gp2 AMI, with an ED25519 based key and attempt to ssh in.

[lorengordon]

I believe ED25519 is not allowed by FIPS. The spel AMIs all have FIPS enabled by default. You'll need to disable FIPS if you want to use an ED25519 keypair.

[ethanchowell]

I'd found some docs that sort of pointed to that idea as well and was afraid that was the reason. If that's the case, would it even be feasible to extend the pre-built AMI vs building it from scratch with fips disabled? My experience with disabling fips is that a reboot is required and I'm just not familiar enough with cloudinit to know if that is/isn't doable. I assume it would have to be at the userdata level since packer won't be able to connect with the ED25519 key.

[lorengordon]

You can certainly do it in userdata, but it does indeed require a reboot to fully disable the FIPS-enabled kernel. I'm not sure if you might be able to disable it without a reboot, perhaps restarting the ssh service, and still connect over ssh with an ED25519 key.

If you choose to build an image from scratch, there is an input variable to leave FIPS off.

Note that if you are using spel, it is notionally assumed that you are subject to DISA STIG requirements, and disabling FIPS or modifying the ciphers to enable ED25519 would result in failing controls in STIG scans.

[ferricoxide]

For EL7, toggling FIPS off requires removing the FIPS kernel RPM and rebuilding the kernel (thus the reboot).

For EL8, you can set up custom enforcement profiles without having to add/remove RPMs. However, for those changes to fully work, you still need to reboot.

There's further blocking that things like the STIG and CIS benchmarks also implement at the per-service level. In the case of SSH, that generally includes disabling ED25519. For those settings, a service restart after a config-file change is enough (if kernel-level restrictions aren't causing the blocking-behavior).

Also worth noting that with EL9, and its move towards FIPS-140-3 adherence (vice EL 7 & 8's FIPS-140-2 adherence), things get even more strict. For instance, if your RSAv2 key isn't SHA2-signed, your RSAv2 key won't work for login purposes (though can still be used for things like connecting to external systems such as one might do with git-over-ssh). This particular enforcement occurs because its the default setting for the OpenSSH server version that comes in EL9 and is separate from whether FIPS-mode is enabled or whether hardening-utilities have restricted the allowed Ciphers and MACs. It's primarily this change that caused me to comment on a closed issue: some PIV-issuers' CAPI-tokens are still not SHA2-signed.