Score:0

Disabling certain OpenSSH keys on OpenBSD: why the corresponding 'sshd_config' entries are ignored and why 'ssh-keygen -A' generates forbidden keys?

cn flag

I am trying to achieve the followings on my OpenBSD 6.9 servers:

  1. Forbidding the use of all keys but the ssh-ed25519 one on both SERVER and CLIENT sides.
  2. Limiting ssh-keygen -A to generate keys only by the authorised ssh-ed25519 algorithm and nothing else.

In order to achieve these, I have added the following lines to my sshd_config:

HostKey /etc/ssh/ssh_host_ed25519_key
CASignatureAlgorithms ssh-ed25519
HostbasedAcceptedKeyTypes ssh-ed25519
HostKeyAlgorithms ssh-ed25519
PubkeyAcceptedKeyTypes ssh-ed25519

I have also added the following lines to my ssh_config:

CASignatureAlgorithms ssh-ed25519
HostbasedAcceptedKeyTypes ssh-ed25519
HostKeyAlgorithms ssh-ed25519
PubkeyAcceptedKeyTypes ssh-ed25519

I have deleted all keys but the authorised one.

Restarted sshd:

# rcctl restart sshd                                                                            
sshd(ok)
sshd(ok)

After verifying whether my settings are utilised by running the following commands:

# ssh -Q HostbasedAcceptedAlgorithms
# ssh -Q HostKeyAlgorithms
# ssh -Q PubkeyAcceptedAlgorithms

For my surprise, this is what they all return with:

ssh-ed25519
[email protected]
[email protected]
[email protected]
ssh-rsa
rsa-sha2-256
rsa-sha2-512
ssh-dss
ecdsa-sha2-nistp256
ecdsa-sha2-nistp384
ecdsa-sha2-nistp521
[email protected]
[email protected]
[email protected]
[email protected]
[email protected]
[email protected]
[email protected]
[email protected]
[email protected]
[email protected]

In other words, the key restrictions are ignored.

Just to be on the safe side, I have even restarted the server, but there is no difference.

A potential workaround is to remove all key files but the authorised one. However, the init script /etc/rc has a line, ssh-keygen -A, which regenerates all missing ssh keys after every system reboot, before the sshd daemon would start, including those of forbidden algorithms!

So removing the keys does not solve the problem.

As an additional workaround, I could remove the ssh-keygen -A line from the init script or replace it with my custom key generation algorithm, but that will lead back to where it has all started: having to deal with this problem over and over again, e.g. after every system update, whenever the OpenBSD team releases a new version of /etc/rc. Automating the removal of that line and testing such a sloppy workaround on large number of servers is difficult and it can lead to a massive network failure if something goes wrong.

Therefore, I continued my investigation and I dug into the source code of ssh-keygen. I have found out that it is not possible to restrict the behaviour of the -A switch from outside e.g. via config files. It does not even perform a preliminary test whether the keys are authorised or not, it just generates the keys, according to a list of algorithms from a hardcoded array. The only way of avoiding this is by editing, recompiling and using a custom fork of ssh-keygen, but then I will have to deal with it after every OpenSSH update...

I have found a partial solution for other operating systems but not for OpenBSD.

Could somebody please point me to a proper solution? Why my sshd_config and ssh_config key restrictions are ignored and how to get ssh-keygen -A stop generating keys with forbidden algorithms?

Before anyone would ask: all other settings are utilised in both config files by OpenSSH, so these config files are indeed the actual ones being loaded.

Many thanks for all useful answers.

Michael Hampton avatar
cz flag
For ssh-keygen you should be talking to the OpenSSH developers via whatever issue tracking system they use.
Michael Hampton avatar
cz flag
In addition I'd also complain to the OpenBSD maintainers about their use of ssh-keygen -A in the startup scripts. On Linux the keys are all generated separately and generating each one (e.g. rsa, ecdsa, ed25519) can be enabled or disabled at will independently of the others.
mangohost

Post an answer

Most people don’t grasp that asking a lot of questions unlocks learning and improves interpersonal bonding. In Alison’s studies, for example, though people could accurately recall how many questions had been asked in their conversations, they didn’t intuit the link between questions and liking. Across four studies, in which participants were engaged in conversations themselves or read transcripts of others’ conversations, people tended not to realize that question asking would influence—or had influenced—the level of amity between the conversationalists.