0

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
ssh-ed25519-cert-v01@openssh.com
sk-ssh-ed25519@openssh.com
sk-ssh-ed25519-cert-v01@openssh.com
ssh-rsa
rsa-sha2-256
rsa-sha2-512
ssh-dss
ecdsa-sha2-nistp256
ecdsa-sha2-nistp384
ecdsa-sha2-nistp521
sk-ecdsa-sha2-nistp256@openssh.com
webauthn-sk-ecdsa-sha2-nistp256@openssh.com
ssh-rsa-cert-v01@openssh.com
rsa-sha2-256-cert-v01@openssh.com
rsa-sha2-512-cert-v01@openssh.com
ssh-dss-cert-v01@openssh.com
ecdsa-sha2-nistp256-cert-v01@openssh.com
ecdsa-sha2-nistp384-cert-v01@openssh.com
ecdsa-sha2-nistp521-cert-v01@openssh.com
sk-ecdsa-sha2-nistp256-cert-v01@openssh.com

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.

Tony
  • 11
  • 2
  • For ssh-keygen you should be talking to the OpenSSH developers via whatever issue tracking system they use. – Michael Hampton Jul 27 '21 at 12:55
  • 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. – Michael Hampton Jul 27 '21 at 13:42

0 Answers0