ansible-collection-hardening icon indicating copy to clipboard operation
ansible-collection-hardening copied to clipboard

SSH KexAlgorithms causes SSH daemon to fail

Open max-wittig opened this issue 4 years ago • 7 comments

Describe the bug Because of the renaming of a KEX algorithm, an upgrade from Fedora 33 to 34 or 35, will cause the SSH daemon to crash on start with this message.

Unsupported KEX algorithm "[email protected]"

Although this algorithm was updated in https://github.com/dev-sec/ansible-collection-hardening/pull/437, it's currently quite difficult to apply this fix as it's only run when the sshd_version is equal or above 8.5. Fedora 33 seems to have version 8.4. More details below.

This is a continuation issue from https://github.com/dev-sec/ansible-collection-hardening/issues/433

Expected behavior

I think the key algorithm rename should be done, before it causes problems. I'm also aware that this might not be possible, as OpenSSL didn't follow a nice deprecation path, it seems.

But I'm not sure about this, maybe we can change the key algorithm name already in 8.4, which would prevent this problem.

Actual behavior

SSH daemon crashes with the following message

Unsupported KEX algorithm "[email protected]"

OS / Environment

$ ssh -V
OpenSSH_8.4p1, OpenSSL 1.1.1l  FIPS 24 Aug 2021

$ ssh -Q kex
diffie-hellman-group1-sha1
diffie-hellman-group14-sha1
diffie-hellman-group14-sha256
diffie-hellman-group16-sha512
diffie-hellman-group18-sha512
diffie-hellman-group-exchange-sha1
diffie-hellman-group-exchange-sha256
ecdh-sha2-nistp256
ecdh-sha2-nistp384
ecdh-sha2-nistp521
curve25519-sha256
[email protected]
[email protected]

cat /etc/redhat-release
Fedora release 33 (Thirty Three)

Ansible Version

ansible [core 2.11.6] 
  config file = None
  configured module search path = ['/home/z003s32w/.ansible/plugins/modules', '/usr/share/ansible/plugins/modules']
  ansible python module location = /usr/local/lib/python3.9/site-packages/ansible
  ansible collection location = /home/z003s32w/.ansible/collections:/usr/share/ansible/collections
  executable location = /usr/local/bin/ansible
  python version = 3.9.7 (default, Aug 30 2021, 00:00:00) [GCC 10.3.1 20210422 (Red Hat 10.3.1-1)]
  jinja version = 3.0.1
  libyaml = True

Role Version

0c840372d86db41f08496d1d61d0d4a2d2b2a640  # latest master

/cc @schurzi @dlouzan

max-wittig avatar Nov 08 '21 08:11 max-wittig

Running ssh-hardening after the upgrade command and before the reboot doesn't help as the ssh-daemon still reports OpenSSH version 8.4

max-wittig avatar Nov 08 '21 10:11 max-wittig

For the people running into the same issue. We're doing this this now before rebooting for the upgrade. Seems to work quite well.

  - name: Upgrade | Patch SSH algorithms to circumvent https://github.com/dev-sec/ansible-collection-hardening/issues/500
    lineinfile:
      path: /etc/ssh/sshd_config
      regexp: '^KexAlgorithms [email protected]'
      line: KexAlgorithms [email protected],[email protected],diffie-hellman-group-exchange-sha256

  - name: Upgrade | Run system upgrade reboot
    command: "dnf system-upgrade reboot"
    ignore_errors: yes  # Fedora will kill this SSH connection immediately
    args:
      warn: false

max-wittig avatar Nov 08 '21 12:11 max-wittig

I think Fedora did some custom patching here. Especially since the not working Key Exchange is clearly in the list of supported Key Exchanges. This is somewhat puzzling. I think I will setup a test environment for this and do some tests with different Fedora versions.

schurzi avatar Nov 08 '21 13:11 schurzi

This seems to be the culprit:

For example, if OpenSSH is upgraded then sshd_config reverts to the default package configuration. The default package configuration does not enable public key authentication, and allows password authentication.

That's weird behavior imo: https://docs.fedoraproject.org/en-US/quick-docs/dnf-system-upgrade/#sect-upgraded-package-configurations

max-wittig avatar Nov 08 '21 15:11 max-wittig

That Fedora behaviour is really, really weird. Who would want their basic services configuration to be reverted to the defaults automatically? 😒

dlouzan avatar Nov 08 '21 15:11 dlouzan

I'm running into the same on Ubuntu 22.04. The above work-around does not work for me.

# ansible --version
ansible [core 2.12.5]
  python version = 3.9.12 (main, Mar 26 2022, 15:51:15) [Clang 13.1.6 (clang-1316.0.21.2)]

---

# ssh -V
OpenSSH_8.9p1 Ubuntu-3, OpenSSL 3.0.2 15 Mar 2022

# ssh -Q kex
diffie-hellman-group1-sha1
diffie-hellman-group14-sha1
diffie-hellman-group14-sha256
diffie-hellman-group16-sha512
diffie-hellman-group18-sha512
diffie-hellman-group-exchange-sha1
diffie-hellman-group-exchange-sha256
ecdh-sha2-nistp256
ecdh-sha2-nistp384
ecdh-sha2-nistp521
curve25519-sha256
[email protected]
[email protected]

# uname -a
Linux home-server-test 5.15.0-27-generic #28-Ubuntu SMP Thu Apr 14 04:55:28 UTC 2022 x86_64 x86_64 x86_64 GNU/Linux

# lsb_release -ds
Ubuntu 22.04 LTS

# cat devsec/hardening/roles/ssh_hardening/MANIFEST.json | jq '.collection_info.version'
"7.0.0"

Update:

This works for me:

    - name: Run devsec.hardening.ssh_hardening
      vars:
        ssh_kex:
          - [email protected]
          - [email protected]
          - diffie-hellman-group-exchange-sha256
      ansible.builtin.import_role:
        name: devsec.hardening.ssh_hardening

bradleyfrank avatar Apr 28 '22 13:04 bradleyfrank

We should probably update the ciphers here: https://github.com/dev-sec/ssh-baseline/blob/master/libraries/ssh_crypto.rb

Then we can also update the ciphers used in the collection.

rndmh3ro avatar May 09 '22 11:05 rndmh3ro

Should be fixed for some time now here: https://github.com/dev-sec/ansible-collection-hardening/pull/437 and here https://github.com/dev-sec/ssh-baseline/pull/209

rndmh3ro avatar Jan 30 '23 09:01 rndmh3ro