Skip to content
This repository was archived by the owner on Dec 26, 2020. It is now read-only.

RHEL/CentOS 8 requires removal or editing of /etc/crypto-policies/back-ends/openssh*.config #275

Closed
Teknoenie opened this issue Apr 24, 2020 · 6 comments

Comments

@Teknoenie
Copy link

Teknoenie commented Apr 24, 2020

Describe the bug
OpenSSH server configuration is handled by 'update-crypto-policy' which provides

/etc/crypto-policies/back-ends/openssh.config

and

/etc/crypto-policies/back-ends/opensshserver.config.bak

These files must be removed or altered in to function correctly.

Expected behavior
OpenSSH policies for Key Exchanges, MACs and Ciphers as defined by the Ansible module work.

Actual behavior
OpenSSH policies for Key Exchanges, MACs and Ciphers as defined by the Ansible module are ignored.

Example Playbook

- hosts: localhost
  roles:
    - ansible-ssh-hardening

  vars:
    ssh_moduli_minimum: 3071
    ssh_host_key_files: [ '/etc/ssh/ssh_host_ed25519_key' ]
    ssh_cipers: [ 'chacha20-poly1305@openssh.com',
                  'aes256-gcm@openssh.com',
                  'aes256-ctr',
                  'aes128-gcm@openssh.com',
                  'aes128-ctr' ]
    ssh_kex: [ 'curve25519-sha256',
               'curve25519-sha256@libssh.org',
               'diffie-hellman-group16-sha512',
               'diffie-hellman-group18-sha512' ]
    ssh_macs: [ 'hmac-sha2-512-etm@openssh.com',
               'hmac-sha2-256-etm@openssh.com',
               'umac-128-etm@openssh.com' ]

OS / Environment
CentOS Linux release 8.1.1911 (Core)

Ansible Version

ansible 2.9.7
  config file = None
  configured module search path = ['/root/.ansible/plugins/modules', '/usr/share/ansible/plugins/modules']
  ansible python module location = /usr/local/lib/python3.6/site-packages/ansible
  executable location = /usr/local/bin/ansible
  python version = 3.6.8 (default, Nov 21 2019, 19:31:34) [GCC 8.3.1 20190507 (Red Hat 8.3.1-4)]

Role Version

- src: https://github.com/dev-sec/ansible-ssh-hardening.git

Additional context
None

@Teknoenie Teknoenie changed the title RHEL/CentOS 8 requires removal of /etc/crypto-policies/back-ends/opensshserver.config RHEL/CentOS 8 requires removal or editing of /etc/crypto-policies/back-ends/opensshserver.config Apr 24, 2020
@Teknoenie Teknoenie changed the title RHEL/CentOS 8 requires removal or editing of /etc/crypto-policies/back-ends/opensshserver.config RHEL/CentOS 8 requires removal or editing of /etc/crypto-policies/back-ends/openssh*.config Apr 24, 2020
@rndmh3ro
Copy link
Member

rndmh3ro commented May 1, 2020

Thanks for this, I did not know that this exists.

More information: https://access.redhat.com/documentation/en-us/red_hat_enterprise_linux/8/html/security_hardening/using-the-system-wide-cryptographic-policies_security-hardening

We'll have to decide what to support and use.

@Teknoenie
Copy link
Author

Teknoenie commented May 11, 2020

While not a bug, it would seem that the client configurations also don't disallow host key types for use. I'm not sure how to best accomplish this but it would be nice if we could also figure out how to enforce SSH client configuration for allowed HostKeyTypes.

'HostKeyAlgorithms' can (should 🤔 ) be defined to also limit client Host Key Types.

HostKeyAlgorithms -ssh-dss,ecdsa-sha2-nistp256,ecdsa-sha2-nistp384,ecdsa-sha2-nistp521,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,ssh-rsa,ssh-rsa-cert-v01@openssh.com

@schurzi
Copy link
Contributor

schurzi commented Jul 18, 2020

The openssh-server side of this issue is fixed by #309.
This only leaves the client side issue remaining.

@schurzi
Copy link
Contributor

schurzi commented Jul 18, 2020

the crypto policy for ssh client is activated by an include /etc/ssh/ssh_config.d/05-redhat.conf since our config does not have this include the client part should also be solved. Will check this in a moment.

@schurzi
Copy link
Contributor

schurzi commented Jul 18, 2020

This is possible to check via ssh -G localhost |grep ciphers. We will add some tests for this to our baseline. So basically this is solved now, just waiting for the PR in ssh-baseline and then we should be safe :)

@schurzi
Copy link
Contributor

schurzi commented Jul 22, 2020

just submittet a PR to our baseline (dev-sec/ssh-baseline#177)
I will close this now, since all issues are resolved.

@schurzi schurzi closed this as completed Jul 22, 2020
# for free to subscribe to this conversation on GitHub. Already have an account? #.
Labels
None yet
Projects
None yet
Development

No branches or pull requests

3 participants