I want to force all users to use only ed25519 type keys when logging in via SSH / SFTP to a Linux server which is running a recent version* of OpenSSH.

Some general reasons for putting controls on SSH keys might include:

In many cases, SSH keys have been completely overlooked in identity and access management planning, implementation, and audits. Users have been able to create and install keys without oversight and controls. This has led to violations of corporate access policies and dangerous backdoors.

Information security starts from controlling who is given access to systems and data. If there is no control over access, there is no security, no confidentiality, no integrity, and no guarantees of continued operation

Source: https://www.ssh.com/iam/ssh-key-management/

I am not trying to accomplish a full key management implementation. And I do not wish to remove the ability for a user to manage their own SSH keys (including adding, removing, changing the keys). My only objective is to mandate that the key used is of type ed25519.

How can this be accomplished while maintaining the above user privileges and while maintaining this setting?

AuthorizedKeysFile  .ssh/authorized_keys

The main (non-default) sshd_config settings I'm using on this server include:

The only host key enabled:
HostKey /etc/ssh/ssh_host_ed25519_key

PermitRootLogin no
PasswordAuthentication no
ChallengeResponseAuthentication no
UsePAM yes
AuthorizedKeysFile  .ssh/authorized_keys
KexAlgorithms [email protected]
MACs [email protected]
Ciphers [email protected]
AllowUsers user@host ...

However, with those settings a user can still select an older user identity key type and use it to log in. My only objective now is to stop a user from getting access except via an ed25519 user identity key. How?

*Actually running: OpenSSH_8.1p1, OpenSSL 1.1.1d

  • 1
    What you are proposing to do may actually reduce rather than enhance security. Not allowing people to use RSA keys means that you may force them away from secure key storage options. For example, YubiKey works beautifully as a secure key storage mechanism. But it only supports RSA. The same goes for other USB HSM devices. In theory it might be possible to make it work with other HSMs, but in practice RSA rules the roost (especially with older SSH clients, the SSH devs have only very recently been improving PKCS11 support for non-RSA algos, but non-RSA is still a bit buggy). Commented Nov 28, 2019 at 21:25
  • @LittleCode Yes, I read that info in the SSH docs, but it does not apply in my situation. Still, it is good for others to know. Our team exclusively uses ed25519 keys. No reason to leave the door open for other key types.
    – MountainX
    Commented Nov 29, 2019 at 3:31
  • Security by obscurity is not security. That's all I've got to say. Commented Nov 29, 2019 at 7:54
  • 2
    @LittleCode, how is that security by obscurity? In general, if users are generating their own SSH keys, not too many of them will know which key type is better or more secure (assuming that they even have thought of that). Otherwise, many of those users may generate relatively weak SSH keys or save the keys in the old format, thus making the server more vulnerable. I see this as a viable solution by enforcing clients to use ED25519 keys. Only 4096-bit RSA keys and longer "outmatch" ED25519 keys.
    – Klaidonis
    Commented Apr 7, 2020 at 10:45

2 Answers 2


According to https://unix.stackexchange.com/questions/549610/limit-sshd-to-use-only-ssh-ed25519-keys-to-authenticate


I am trying to configure my sshd on ubuntu 18.04 to accept only ed25519 keys to authenticate, at the moment the server accepts ssh-rsa and ssh-ed25519. Any idea to achieve that? thanks!


PubkeyAcceptedKeyTypes [email protected],ssh-ed25519 worked for me.

This worked for me too. I edited /etc/ssh/sshd_config and added this setting:

PubkeyAcceptedKeyTypes [email protected],ssh-ed25519
  1. OpenSSH does not have a builtin feature to do what you describe (unlike client which can restrict host pubkey algorithms) -- I did go through the man page and I don't know _how_I missed that -- butor you can construct it using AuthorizedKeysCommand -- just grep or sed out the keys you don't want from the (usual) file. FWIW that works on versions below 6.8 (released 2015-03), which may matter in some cases but hopefully not often.

  2. However, this does NOTHING, ZILCH, NADA to accomplish what you describe as your reason, which makes me suspect or at least hope this is not your real reason and you're just having us all on.

  • 2
    See my answer. The configuration option PubkeyAcceptedKeyTypes does it.
    – MountainX
    Commented Nov 30, 2019 at 5:03

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .