The Secure Shell, more commonly referred to as ssh, is a cryptographic network protocol for operating network services securely over an unsecured network. Typical applications include remote command-line, login, and remote command execution, but any network service can be secured with SSH.  Over the years, a more typical solution is to create a key type of rsa, which is the default value if not specified.  This was verified in CentOS 8 using man. This may or may not pose a problem on FIPS enabled systems.

There are four key types that may be specified.  They may be specified with the flag ‘-t’ and are dsa, ecdsa, ed25519, and rsa. This flag may also be used to specify the desired signature type when signing certificates using a RSA CA key. The available RSA signature variants are “ssh-rsa” (SHA1 signatures, not recommended), “rsa-sha2-256” “rsa-sha2-512” (the default).

Key	Detail
dsa	OpenSSH version 7 does not support and is unsafe to use.
rsa	Pending on the key size 3072 or 4096 is considered good.
ecdsa	it depends on how well your machine can generate a random number that will be used to create a signature. There is also a trustworthiness concern on the NIST curves that being used by ECDSA.
ed25519	It is the most recommended public-key algorithm available today!

The table is adapted from medium.com.  The same site among others report that the ed25519 is the key type to select and expresses the benefits in selecting this key type.

Confusion

To generate the key type, to test, I created one using the following command.  The details of switches may be found in the man pages for ssh-keygen.

ssh-keygen -o -a 100 -t ed25519 -f ~/.ssh/id_ed25519 -b 521 -C "testuser@it.megocollector.com"

I was able to successfully logon with the newly created keys.  So, the next step was to update the cryptographic policy to FIPS:OSPP and see what happens next.  I was unable to logon with a message as found in /var/log/secure and the “Server refused our key” message on the ssh session attempt.

Using arbitrary primes is not allowed in FIPS mode. Falling back to known groups.
userauth_pubkey: key type ssh-ed25519 not in PubkeyAcceptedKeyTypes [preauth]

What gives?

It seems that many websites have supported ed25519 but not FIPS. According to Red Hat, regarding the RHEL6 and RHEL7, FIPS does not support dsa or ed25519 and only supports ecdsa and rsa. According to NIST, the FIPS 186-5 (draft) will support ed25519. This draft was published October 2019.

What to do?

Use the ecdsa key type until  ed25519 becomes FIPS compliant.  Maybe the following command will work for you.  Again, look at the man pages for ssh-keygen for detail.

# NIST supports P-256 and P-384. Only explanation is that P-521 may be subject to padding attacks.
ssh-keygen -t ecdsa -b 384

# The following will work but not supported by NIST.
ssh-keygen -t ecdsa -b 521
ssh-keygen -t ecdsa -b 521 -C "YourComment Goes Here"

Verify what you use?

Authenticating with public key "Yourcomment Goes Here"

Check out your key types

for key in ~/.ssh/id_*; do ssh-keygen -l -f "${key}"; done | uniq

Source(s)

Not all of these were sourced for this article; however, there are other resources here that I found particularly useful.

• https://en.wikipedia.org/wiki/SSH_(Secure_Shell)
• man ssh-keygen
• https://medium.com/risan/upgrade-your-ssh-key-to-ed25519-c6e8d60d3c54
• https://access.redhat.com/solutions/3643252
• https://csrc.nist.gov/publications/detail/fips/186/5/draft
• https://medium.com/@tom.oloughlin/mahself-rhel7-fips-ssh-keygen-o-a-100-t-ed25519-f-ssh-id-ed25519-36971b625ae5
• https://goteleport.com/blog/comparing-ssh-keys/
• https://docs.oracle.com/cd/E37838_01/html/E61025/ssh-fips.html
• https://access.redhat.com/discussions/1518473
• https://access.redhat.com/solutions/5283941
• https://docs.microsoft.com/en-us/cpp/linux/set-up-fips-compliant-secure-remote-linux-development?view=msvc-160