[jamescun]

If you are managing enough servers to justify automating the deployment SSH keys, you probably also have configuration management.

Why would you use this rather than your existing configuration management system? The latter reuses existing infrastructure and is naturally more concurrent and scalable.

I get this is a push mechanism and configuration management is generally pull-based, alternatively tools like Ansible exist which can perform the same task and then some.

[tamier]

Since we are the sysop team of a students council with very fluctuating members, we have to keep our whole infrastructure as simple as possible. That means: Very simple virtual machines with very few software packages on it, very detailed documentation and so on. The problem is that students are joining our team partly with very little knowledge. Configuration management would mean another system to figure out for every member.

[102030485868]

As opposed to every new member having to figure out this new project?

Documentation is your best bet. It would be better to teach students about things that are currently being used instead of making up your own solutions.

Though, there is a lot to gain from rolling your own solutions, so: ¯\_(ツ)_/¯

[Ao7bei3s]

Here's why I think configuration management, Ansible in particular, would be a good idea for your use case:

1. Playbooks are executable documentation that's concise, accurate and doesn't rot away as fast. And no one can put off writing it.

2. If you keep them in git, you'll later have a history of what changed when - and who did it!

3. Your servers will stay consistent. Less trying to debug why server X behaves differently than server Y. No more forgetting one server when doing mass changes.

4. Your members will need to learn one less thing specific to your infrastructure.

5. Your members may learn something useful. It's a CS student council, they should be able to pick it up. And they don't need to understand it completely right away. (I know that's a controversial thing to say in university circles ;) Copy/paste + knowing how to run it should be enough at first.

6. Once you have it in place, you can still decide if you want to automate more things -- or not!

7. Why Ansible in particular: no server side software, leaves no trace on server -> you can always just stop using it.

Note: It's totally ok to not do everything but just the common things in config management.

Here's a hopefully complete (but untested) example optimized for beginner-friendlyness, just to give you an example. It's shorter than your code!

  # On workstation, nothing extra is needed on servers (well, except Python):
  dnf install ansible

  # Put your own SSH key on the servers manually.

  # File "site.yml":
  ---
  - hosts: all   # "all", or a hostname, or a groupname
    vars_files:
    - keys.yml
    tasks:  # always executed in the order they're written
    - authorized_key: user="root" key="{{ item }}" state=present   # use state=absent to remove keys
      with_items: user_keys["Alice"]
    - authorized_key: user="root" key="{{ item }}" state=present
      with_items: user_keys["Bob"]

  # File "keys.yml":
  ---
  user_keys:
    Alice:
    - "ssh-rsa AAA....."
    - "ssh-rsa AAA....."
    Bob:
    - "ssh-rsa AAA....."
    - "ssh-rsa AAA....."
  
  # File "hosts":
  [my_hosts]  # This line is optional. It groups hosts.
  demo-host ansible_host=10.11.12.13 ansible_ssh_user=root

  # Deploy:
  ansible-playbook -i hosts site.yml

  # Run it, but make it not change anything on the servers:
  ansible-playbook -i hosts site.yml --check

Wasn't so hard, was it?