User creation with password

[djach7]

This pr attempts to implement the creation of a user and password when onboarding a device, using a username and password provided within the serviceinfo_api_server.yml config.

closes #321

This is a draft, current known issues include:

• Password encryption on on user creation
• Confirming sshkey creation still functional
• Confirming edge case functionality

[miabbott]

Could you use a Rust crate to handle the password hashing instead of shelling out to openssl?

https://docs.rs/password-hash/latest/password_hash/

https://docs.rs/bcrypt/latest/bcrypt/

[miabbott]

Also we should be defaulting to SHA512 for the algorithm; MD5 is considered insecure these days.

https://access.redhat.com/articles/880733

[nullr0ute]

Could you use a Rust crate to handle the password hashing instead of shelling out to openssl?

Or using a function in the openssl crate.

[sarmahaj]

are we not contradicting to FIDO policy of "password less" logins by providing a way to set password for initial user ?
I think we should prefer sshkey rather than password for at least initial user which is for first boot/onboarding. As I recall we did this because for local user it asks for password .

[say-paul]

An general thought on having the plain text password in .yaml which may raise some eyebrows.We can force user to put the encrypted password in the file as its done with the useradd command , advantage is 1. simplify the implementation , 2. security.

[say-paul]

are we not contradicting to FIDO policy of "password less" logins by providing a way to set password for initial user ? I think we should prefer sshkey rather than password for at least initial user which is for first boot/onboarding. As I recall we did this because for local user it asks for password .

the ssh_key feature already exists, this added feature is for any user who requires password to be set also.

[djach7]

Thank you all for the comments/ideas, I'm going to try to understand the openssl crate and I'll make the other changes above too.

[7flying]

There are some changes made into the serviceinfo-api-server, owner-onboarding-server and client-linuxapp on the chore(integration-tests) commit that are not tests, I would like those changes to be moved to the implementation commit.

Other than that, we are not testing that you can add more than one ssh key per user, but we can add that as a follow-up PR.

So, feel free to mark the PR as ready

[nullr0ute]

Other than that, we are not testing that you can add more than one ssh key per user, but we can add that as a follow-up PR.

Can we ensure an issue is created so that isn't lost.

[7flying]

Other than that, we are not testing that you can add more than one ssh key per user, but we can add that as a follow-up PR.

Can we ensure an issue is created so that isn't lost.

Yep, linking the issue here for future reference #507

[7flying]

Everything looks good, thank you!