set random password

[basz]

Hello,

Would you consider adding a random password to the user creation 'cause otherwise the account is locked and passwordless keys will not work.

Try this role and then dev-sec.ssh-hardening. You will not be able to login at all.

- name: Create user
  user:
    generate_ssh_key: "{{ user_generate_ssh_key }}"
    groups: "{{ (user_groups | join(',')) }}"
    append: True
    name: "{{ user_name }}"
    shell: "{{ user_shell }}"
    # this generates a hashed and random uuid string
    password: "{{ 9999999999999999999999 | random | string | to_uuid | password_hash('sha512', 65534 | random | string) }}"
    update_password: on_create

[nickjj]

Hi,

I'm not sure what the dev-sec.ssh-hardening role does but if you supply your public SSH key to this role, you will be able to login to your server with your SSH key instead of needing a password.

Personally, I don't even allow password based logins to any of my servers and I'm surprised that the dev-sec SSH role would allow that by default.

[basz]

I'm not sure what the dev-sec.ssh-hardening role does but if you supply your public SSH key to this role, you will be able to login to your server with your SSH key instead of needing a password. Personally, I don't even allow password based logins to any of my servers and I'm surprised that dev-sec SSH role would allow that by default.

An account without password is considered locked. You can’t login to a locked account even with pub/key. (at least after hardening) And yes, password logins are disabled in /etc/ssh/sshd_config by dev-sec.ssh-hardening so it won’t allow users to connect with a password over ssh. Therefore it won’t hurt to add a random password to account. To be honest I am surprised you are able to login with pubkeys without a password set… From `/etc/ssh/sshd_config` after hardening ``` PasswordAuthentication no PermitEmptyPasswords no ```

[nickjj]

This role copies your public SSH key to your server in the server's user's authorized_keys file. This is half of what allows you to login without having any sort of user password defined.

Then on the SSH side of things you can lock things down by setting:

PermitRootLogin no
PasswordAuthentication no
PubkeyAuthentication yes

Now you'll be able to login with only SSH keys that are allowed for a specific user.

[basz]

Op 2 feb. 2019, om 14:14 heeft Nick Janetakis ***@***.***> het volgende geschreven: This role copies your public SSH key to your server in the server's user's authorized_keys file. This is what allows you to login without having any sort of password defined. Then on the SSH side of things you can lock things down by setting: PermitRootLogin no PasswordAuthentication no PubkeyAuthentication yes Now you'll be able to login with only SSH keys that are allowed for a specific user. — You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub <#6 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AAIu3MyEiBujXvgITPai4eUcX6QNDeDJks5vJY9DgaJpZM4aeg0z>.

It’s weird. After creating a user the account is NOT locked ``` passwd —status zonderbaar L 02/02/2019 0 99999 7 -1 # and sudo cat /etc/passwd | grep zonderbaar zonderbaar:x:1001:1001::/home/zonderbaar:/bin/bash ``` Still after hardening I can’t login and a login attempt show the following on the auth.log ``` Feb 2 15:01:54 zonderbaar-hop-01 sshd[6084]: Connection from 77.250.77.145 port 47654 on 10.18.0.10 port 22 Feb 2 15:01:55 zonderbaar-hop-01 sshd[6084]: User zonderbaar not allowed because account is locked Feb 2 15:01:55 zonderbaar-hop-01 sshd[6084]: input_userauth_request: invalid user zonderbaar [preauth] Feb 2 15:01:55 zonderbaar-hop-01 sshd[6084]: Connection closed by 77.250.77.145 port 47654 [preauth] ``` So, I found this on the googles; What the man page says is not that you will be able to use SSH to log into a locked account. What the man page says is that if you have set up SSH keys for non-password login to the account, such login might still work when the password is locked, because SSH key login uses the SSH key instead of the password as the authentication token, bypassing the password-authentication step which would fail. However, even with non-password login working, it only says that it may work. The authentication process is partially controlled/managed by PAM, so if you have your SSH keys set up, and you are able to login to the 'deploy' user without a password as long as it has a valid password, and you are not able to login to the 'deploy' user when the password is locked, look into your PAM configuration. Now, I don’t use PAM (its also disabled by the hardening with `UsePAM no`). Another strange thing; I set a password after hardening ``` sudo passwd Enter new UNIX password: Retype new UNIX password: passwd: password updated successfully ``` Yet, I still can’t login. <me-scratches-head/> So for now I see no other option than to add a long random password upon user creation. It is safe over ssh because the sshd configuration doesn’t allow or password authentication anyway and other local users are known or non-existant. So, puzzling… but thanks for ping-ponging (and for your repo work) Piece Bas

[basz]

Scratch that last bit.

After setting the password correctly I can log in over ssh with pubkeys

sudo passwd zonderbaar

Concluding, an account needs a password set (on Debian 9?). I'll use a long random string for that...

[nickjj]

Something else resulted in you being locked out. Debian 9 has nothing in it that would block a user from signing in without a password.

You can test this on digitalocean very easily. Spin up a brand new Debian 9 server, and set your SSH key during droplet creation. When you do that, DO won't set a root password but you'll be able to SSH into your droplet with your SSH key.