Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Remove hardcoded passwords from Hosts.template.yml #114

Open
piotrzarzycki21 opened this issue Apr 10, 2024 · 4 comments
Open

Remove hardcoded passwords from Hosts.template.yml #114

piotrzarzycki21 opened this issue Apr 10, 2024 · 4 comments
Labels
bug Something isn't working
Milestone

Comments

@piotrzarzycki21
Copy link
Contributor

There are some hardcoded passwords in Hosts.template.yml file - they should be removed and configure by the user during process of server creation.

@piotrzarzycki21 piotrzarzycki21 added the bug Something isn't working label Apr 10, 2024
@JoelProminic
Copy link
Contributor

If we are going to do this, then we should also regenerate the public/private key pair from the template. Currently, password authentication is not enabled for SSH/SCP, and we use private key authentication instead. This could change based on our implementation of #113, but I think it is worth addressing this key. The key could be generated once for the user, and saved in the SHI application settings.

Also note the passwords for the Demo Admin and Dev User. We should consider whether we would rather keep the simple passwords here for the sandbox servers, though.

@JoelProminic
Copy link
Contributor

@JustinProminic suggested that we generate the password when Super.Human.Installer is first opened (and allow manual changes). This password will be in plaintext in Hosts.yml, so we don't want users reusing passwords from elsewhere and then finding it in plaintext later.

@piotrzarzycki21 piotrzarzycki21 added this to the v0.11.0 milestone May 15, 2024
@MarkProminic
Copy link
Collaborator

MarkProminic commented May 16, 2024

It is now possible for SHI to update the following variables with the latest hcl_domino_standalone_provisioner:

vagrant_user_pass: 'AUTOGENERATEDPASS'
vagrant_insert_key: true

https://developer.hashicorp.com/vagrant/docs/vagrantfile/ssh_settings#config-ssh-insert_key
https://developer.hashicorp.com/vagrant/docs/vagrantfile/ssh_settings#config-ssh-password

However the gotcha, is that the new SSH key is generated on the VM, not the Host, so I had to add a section to post-provisioner ruby section, that updates the key:

https://github.com/STARTcloud/core_provisioner/blob/30b2856e58c0b297877114fdd06dc75a85716499/Hosts.rb#L337-L339

That works in conjunction with this role: https://github.com/STARTcloud/startcloud_roles/blob/main/roles/lockdown/meta/main.yml

If you are worried about passing it to me in plain text, I can always drop the password_hash('sha512') function, and you can pass it to the variable via yourself hashed like that.

https://github.com/STARTcloud/startcloud_roles/blob/c2b6fcb8db11eed9d1995b241c91294e96f98495/roles/lockdown/tasks/main.yml#L15

This role is should always be the last role called, as Ansible doesn't like the key being changed on it.

If we run into issues, we can simply append the key instead of replacing it, in the authenticated_keys file, and have both, but in the long run.

Side note, should we also change the default password for the domino_admin_notes_id_password: variable? its currently password, if so, should it match the above password? This password variable is used to create the id, and is displayed in the welcome page. I have no use for it anywhere else so its up to you as to what you want this to be.

@JoelProminic
Copy link
Contributor

@MarkProminic added some provisioner/role updates in v0.1.23: #118

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
bug Something isn't working
Projects
None yet
Development

No branches or pull requests

3 participants