Propagating user data via a finishing template

I am trying to provision an Ubuntu 18.04 Server via the default preseed templates, including the default
preseeding finish template. I’d like to be able to provision the server in such a way, that users with an SSH key set in the webinterface get created and have default settings (such as a default bash, password, basicially how the root user is set up) applied and enabled during the finishing phase, including the ability to login passwordless via SSH.

To create users and add ssh keys, I added the <%= snippet('create_users') %> snippet
found in the documentation.

I noticed there is an option, for choosing to have an entire user group added as users to the server. I assume however, that even then the users will not have default settings, such as a different default shell + a basic enironment configured. In particular I have found no option to enable passwords or passwordless SSH authentification for any user, as far as I can tell, a password is not set for any other user than root.
Additonally, I’m still prompted to enter a password when I try to connect as the default root user, even though key-based authentification seems to work fine.

Expected outcome:
Users from a user group as well as the root user get created with default parameters, similar to how you would find them in a default cloud environment (password set, passwordless SSH login, bash as the default shell etc.)

Foreman and Proxy versions:
Version 2.1.1
Foreman and Proxy plugin versions:
Distribution and version:
The distribution I am trying to provision is Ubuntu 18.04, the distribution Foreman itself is running on, is likely centos.
Other relevant data:

I anonymized my personal data, other than that its the config yaml found in the hosts tab. Notice how the users section basicially only resembles the information asked by the adduser command. Is there a way to change this?

organization_title: my_org
  owner_name: jimkoen
  - ssh-rsa anInsanelyLongSSHPublicKey
      firstname: jim
      lastname: koen
      description: ''
      fullname: jimkoen
      name: jimkoen
      - type: ssh-rsa
        key: theSameInsanelyLongSSHPublicKeyAsBefore
  root_pw: "hash"
  foreman_config_groups: []
  foreman_env: production
  netbox_device_id: 000
  remote_execution_ssh_user: root
  remote_execution_effective_user_method: sudo
  remote_execution_connect_by_ip: false
classes: {}
environment: production

This snipped was added by @ekohl maybe he knows more details. Looking at the contents, the template only adds owners, not all Foreman users. Make sure you add users you want to be provisioned as host owners.

In Foreman there is no place to store passwords. What Foreman uses as password storage is incompatible. Either it’s different hashing (internal DB) or Foreman has no access to it (external auth such as Kerberos or LDAP).

This means you can use su with the root password (which Foreman does have options for).

I’m not sure what else you are expecting. Personally I think logging in as root is a bad practice and always log in as my own user and then escalate privileges using su or sudo`. This gives you at least some basic logging of who logs in using SSH rather than root.

Yeah I am really sorry, I was misunderstanding how privilege escalation should be handled with Foreman.
I fixed my issue, by choosing a user group as an owner for a particular device, and now the SSH Keys get propagated correctly. I am trying to get ansible-foreman to work with our foreman installation. From previous ansible workflows I was genereally under the idea that the preferred way of enabling root access for ansible was by having each user at least be sudo users. Our setup requires that more than one user is able to run ansible playbooks and I was trying to setup access for each individual user, thinking I could use foreman just as dynamic inventory, but I think the intended way is to run all ansible playbooks from the foreman web-interface.

I am still missing the functionality to add additional user data to the users getting created, eg. setting a default shell or changing other things about the environment, but from the looks of it, I would have to extend the standard snippets available.