dev-sec / ansible-collection-hardening

This Ansible collection provides battle tested hardening for Linux, SSH, nginx, MySQL
http://dev-sec.io/
Apache License 2.0
4.09k stars 732 forks source link

Replace default 2048 bits RSA keypair fails on Ubuntu 20.04 #459

Closed rscott1010101 closed 2 years ago

rscott1010101 commented 3 years ago

Describe the bug Fresh install of Ubuntu 20.04, simple playbook to apply ssh_hardening fails to regenerate the host key.

Actual behavior


TASK [devsec.hardening.ssh_hardening : Parse openssh-version] *******************************************************************************************************************************************************************************
ok: [10.8.10.230]

TASK [devsec.hardening.ssh_hardening : Set default for ssh_host_key_files if not supplied] **************************************************************************************************************************************************
included: /home/ansible/.ansible/collections/ansible_collections/devsec/hardening/roles/ssh_hardening/tasks/crypto_hostkeys.yml for 10.8.10.230

TASK [devsec.hardening.ssh_hardening : Replace default 2048 bits RSA keypair] ***************************************************************************************************************************************************************
fatal: [10.8.10.230]: FAILED! => {"changed": false, "msg": "Unable to read the key. The key is protected with a passphrase or broken. Will not proceed. To force regeneration, call the module with `generate` set to `full_idempotence` or `always`, or with `force=yes`."}

Example Playbook

- hosts: 10.8.10.230
  collections:
  - devsec.hardening
  roles:
  - ssh_hardening
  vars:
    ssh_permit_tunnel: true
    ssh_allow_tcp_forwarding: 'all'
    ssh_print_last_log: true
    sftp_chroot: false
    ssh_server_password_login: true
    sshd_authenticationmethods: 'publickey,password'

OS / Environment

Ubuntu 20.04 running on AWS.

Ansible Version

ansible 2.10.11
  config file = /opt/playbooks/ansible.cfg
  configured module search path = ['/home/ansible/.ansible/plugins/modules', '/usr/share/ansible/plugins/modules']
  ansible python module location = /usr/lib/python3/dist-packages/ansible
  executable location = /usr/bin/ansible
  python version = 3.8.10 (default, Jun  2 2021, 10:49:15) [GCC 9.4.0]

Role Version

7.7.0
rndmh3ro commented 3 years ago

Interesting, this does not happen in our CI. Can you share the AMI you experienced the problem with?

rscott1010101 commented 3 years ago

Ami name is ubuntu/images/hvm-ssd/ubuntu-focal-20.04-amd64-server-20210430 . It's the default Ubuntu 20.04 image listed in Quick Start when creating a new instance.

skipperTux commented 3 years ago

Same issue on a bare metal Debian 10 machine, but only if the playbook runs as non-root (with become password). Looking into roles/ssh_hardening/tasks/crypto_hostkeys.yml the task Replace default 2048 bits RSA keypair is not running with become: true. However regenerating keys and writing into /etc/ssh needs root privileges. It looks like we either need to run this role on a root connection with ansible_user: 'root' (and no idempotency, if the role disables ssh root login), or the role needs to be imported with become, see below.

- name: SSH hardening
  ansible.builtin.import_role:
    name: devsec.hardening.ssh_hardening
  become: true

(Though this gives [WARNING]: sftp transfer mechanism failed on [server]. Use ANSIBLE_DEBUG=1 to see detailed information on second run.)

What is the recommended approach?

_Edit: Warning could be fixed by setting sftp_enabled: true._

bedrin commented 3 years ago

Same error on Ubuntu 21.10 Server Minimized

chris-beckman commented 2 years ago

Same error on Amazon Linux AMI 2018.03.

HeikoG67 commented 2 years ago

I had same error on Ubuntu 22.04 but could solve it by runing playbook as sudo. ansible-playbook ansible/playbooks/ssh_hardening.yml -u xxxxx -b -K

schurzi commented 2 years ago

This role needs to run with root privileges, since we are changing a lot of system files. In the past we relied on our users adding become: true to the playbooks. I have checked if it makes sense to add the become: true to all tasks, that require root privileges, but that would apply to nearly every task and it would be very redundant. However, I discovered a solution, to add become: true in our role in a single place and have everything run with an unprivileged user. The PR #561 is currently in review and, once merged, will be part of the next released version.