ansible/test/integration/targets/user/tasks/test_ssh_key_passphrase.yml

# Test creating ssh key with passphrase
- name: Remove ansibulluser
  user:
    name: ansibulluser
    state: absent

- name: Create user with ssh key
  user:
    name: ansibulluser
    state: present
    generate_ssh_key: yes
    force: yes
    ssh_key_file: .ssh/test_id_rsa
    ssh_key_passphrase: secret_passphrase
  register: ansibulluser_create_with_ssh_key

- name: Unlock ssh key
  command: "ssh-keygen -y -f {{ ansibulluser_create_with_ssh_key.ssh_key_file|quote }} -P secret_passphrase"
  register: result

- name: Check that ssh key was unlocked successfully
  assert:
    that:
      - result.rc == 0

- name: Clean ssh key
  file:
    path: "{{ ansibulluser_create_with_ssh_key.ssh_key_file }}"
    state: absent
  when: ansible_os_family == 'FreeBSD'
user - properly handle password and password lock when used together (#73016) Do the right thing on Linux when password lock and a password hash are provided by writing out the password hash prepended by the appropriate lock string rather than using -U and -L. This is the correct way to set and lock the account in one command. On BSD, run separate commands as appropriate since locking and setting the password cannot be done in a single action. FreeBSD requires running several commands to get the account in the desired state. As a result, the rc, output, and error from all commands need to be combined and evaluated so an accurate and complete summary can be given at the end of module execution. * Improve integration tests to cover this scenario. * Break up user integration tests into smaller files * Properly lock account when creating a new account and password is supplied * Simplify rc collection in FreeBSD class Since the _handle_lock() method was added, the rc would be set to None, which could make task change reporting incorrect. My first attempt to solve this used a set and was a bit too complicated. Simplify it my comparing the rc from _handle_lock() and the current value of rc. * Improve the Linux password hash and locking behavior If password lock and hash are provided, set the hash and lock the account by using a password hash since -L cannot be used with -p. * Ensure -U and -L are not combined with -p since they are mutually exclusive to usermod. * Clarify password_lock behavior. 4 years ago			`# Test creating ssh key with passphrase`
			`- name: Remove ansibulluser`
			`user:`
			`name: ansibulluser`
			`state: absent`

			`- name: Create user with ssh key`
			`user:`
			`name: ansibulluser`
			`state: present`
			`generate_ssh_key: yes`
			`force: yes`
Don't use output_dir in target tests (#76107) * Don't use output_dir in user tests * Move blockinfile tests from using output_dir to depending on setup_remote_tmp_dir * Don't use output_dir in git tests * Don't use output_dir in uri tests 3 years ago			`ssh_key_file: .ssh/test_id_rsa`
user - properly handle password and password lock when used together (#73016) Do the right thing on Linux when password lock and a password hash are provided by writing out the password hash prepended by the appropriate lock string rather than using -U and -L. This is the correct way to set and lock the account in one command. On BSD, run separate commands as appropriate since locking and setting the password cannot be done in a single action. FreeBSD requires running several commands to get the account in the desired state. As a result, the rc, output, and error from all commands need to be combined and evaluated so an accurate and complete summary can be given at the end of module execution. * Improve integration tests to cover this scenario. * Break up user integration tests into smaller files * Properly lock account when creating a new account and password is supplied * Simplify rc collection in FreeBSD class Since the _handle_lock() method was added, the rc would be set to None, which could make task change reporting incorrect. My first attempt to solve this used a set and was a bit too complicated. Simplify it my comparing the rc from _handle_lock() and the current value of rc. * Improve the Linux password hash and locking behavior If password lock and hash are provided, set the hash and lock the account by using a password hash since -L cannot be used with -p. * Ensure -U and -L are not combined with -p since they are mutually exclusive to usermod. * Clarify password_lock behavior. 4 years ago			`ssh_key_passphrase: secret_passphrase`
Don't use output_dir in target tests (#76107) * Don't use output_dir in user tests * Move blockinfile tests from using output_dir to depending on setup_remote_tmp_dir * Don't use output_dir in git tests * Don't use output_dir in uri tests 3 years ago			`register: ansibulluser_create_with_ssh_key`
user - properly handle password and password lock when used together (#73016) Do the right thing on Linux when password lock and a password hash are provided by writing out the password hash prepended by the appropriate lock string rather than using -U and -L. This is the correct way to set and lock the account in one command. On BSD, run separate commands as appropriate since locking and setting the password cannot be done in a single action. FreeBSD requires running several commands to get the account in the desired state. As a result, the rc, output, and error from all commands need to be combined and evaluated so an accurate and complete summary can be given at the end of module execution. * Improve integration tests to cover this scenario. * Break up user integration tests into smaller files * Properly lock account when creating a new account and password is supplied * Simplify rc collection in FreeBSD class Since the _handle_lock() method was added, the rc would be set to None, which could make task change reporting incorrect. My first attempt to solve this used a set and was a bit too complicated. Simplify it my comparing the rc from _handle_lock() and the current value of rc. * Improve the Linux password hash and locking behavior If password lock and hash are provided, set the hash and lock the account by using a password hash since -L cannot be used with -p. * Ensure -U and -L are not combined with -p since they are mutually exclusive to usermod. * Clarify password_lock behavior. 4 years ago
			`- name: Unlock ssh key`
Don't use output_dir in target tests (#76107) * Don't use output_dir in user tests * Move blockinfile tests from using output_dir to depending on setup_remote_tmp_dir * Don't use output_dir in git tests * Don't use output_dir in uri tests 3 years ago			`command: "ssh-keygen -y -f {{ ansibulluser_create_with_ssh_key.ssh_key_file\|quote }} -P secret_passphrase"`
user - properly handle password and password lock when used together (#73016) Do the right thing on Linux when password lock and a password hash are provided by writing out the password hash prepended by the appropriate lock string rather than using -U and -L. This is the correct way to set and lock the account in one command. On BSD, run separate commands as appropriate since locking and setting the password cannot be done in a single action. FreeBSD requires running several commands to get the account in the desired state. As a result, the rc, output, and error from all commands need to be combined and evaluated so an accurate and complete summary can be given at the end of module execution. * Improve integration tests to cover this scenario. * Break up user integration tests into smaller files * Properly lock account when creating a new account and password is supplied * Simplify rc collection in FreeBSD class Since the _handle_lock() method was added, the rc would be set to None, which could make task change reporting incorrect. My first attempt to solve this used a set and was a bit too complicated. Simplify it my comparing the rc from _handle_lock() and the current value of rc. * Improve the Linux password hash and locking behavior If password lock and hash are provided, set the hash and lock the account by using a password hash since -L cannot be used with -p. * Ensure -U and -L are not combined with -p since they are mutually exclusive to usermod. * Clarify password_lock behavior. 4 years ago			`register: result`

			`- name: Check that ssh key was unlocked successfully`
			`assert:`
			`that:`
			`- result.rc == 0`

			`- name: Clean ssh key`
			`file:`
Don't use output_dir in target tests (#76107) * Don't use output_dir in user tests * Move blockinfile tests from using output_dir to depending on setup_remote_tmp_dir * Don't use output_dir in git tests * Don't use output_dir in uri tests 3 years ago			`path: "{{ ansibulluser_create_with_ssh_key.ssh_key_file }}"`
user - properly handle password and password lock when used together (#73016) Do the right thing on Linux when password lock and a password hash are provided by writing out the password hash prepended by the appropriate lock string rather than using -U and -L. This is the correct way to set and lock the account in one command. On BSD, run separate commands as appropriate since locking and setting the password cannot be done in a single action. FreeBSD requires running several commands to get the account in the desired state. As a result, the rc, output, and error from all commands need to be combined and evaluated so an accurate and complete summary can be given at the end of module execution. * Improve integration tests to cover this scenario. * Break up user integration tests into smaller files * Properly lock account when creating a new account and password is supplied * Simplify rc collection in FreeBSD class Since the _handle_lock() method was added, the rc would be set to None, which could make task change reporting incorrect. My first attempt to solve this used a set and was a bit too complicated. Simplify it my comparing the rc from _handle_lock() and the current value of rc. * Improve the Linux password hash and locking behavior If password lock and hash are provided, set the hash and lock the account by using a password hash since -L cannot be used with -p. * Ensure -U and -L are not combined with -p since they are mutually exclusive to usermod. * Clarify password_lock behavior. 4 years ago			`state: absent`
			`when: ansible_os_family == 'FreeBSD'`