Hello, as part of strengthening our security posture, I evaluate SSH access behavior to machines. Historically, people tended to append SSH keys to ~root/.ssh/authorized_keys on machines. Using ssh directly as root has drawbacks: - no per-user auditing - working with privileges often not needed for the tasks one wants to conduct - no central management of access - compromise of a users private SSH key yields a larger attack surface Past benefits such as not being dependent on the authorization server for login are no longer valid since the migration to Kanidm. The Kanidm client running on machines caches your credentials reliably. Already since some time our canonical way of accessing machines is by using SSH with ones Heroes username, and further to utilize either system groups for rootless tasks or Salt role [0] specific `-admins` groups (managed in our internal Heroes IDP) to elevate to root (or to application accounts) using `sudo` where needed [1]. This way has so far not been enforced, and legacy implementations using the root user's authorized_keys file were tolerated. Starting with 2024-09-07, this will change, and we will no longer tolerate the practice of connecting via `ssh` to `root` users. Local root user's `authorized_keys` files will be wiped and their content will be enforced and managed by Salt. - If you are already only using your Heroes username to SSH to machines, you do not need to take any action. - If you are currently using `root` to SSH to machines, please: * Check if your Heroes user is already part of the `-admins` groups related to the machines you maintain: - every machine in our infrastructure already has sudo rules matching the IDP groups `<role>-admins` for all roles assigned to the machine in Salt. - members of these groups can use `sudo` to elevate to `root` on machines part of the role. - you can easily find out which groups you are member of by ssh-ing to any infra.opensuse.org machine with your Heroes username, and executing `groups` (simple output) or `id` (verbose output). * If you are already part of the relevant `-admins` groups, verify you can use `sudo` to gain `root` access on the relevant machines. * If you are missing membership to `-admins` groups for services you maintain, please create a ticket [2] to request being added. * If machines you maintain are missing Salt roles for services running on them, please submit a merge request to our Salt repository [3] adding them. Note that we allow exceptions to the rule in special cases - for example for emergency access to IDP servers to avoid circular dependencies. Thanks for cooperating! This effort is tracked via https://progress.opensuse.org/issues/161354. Best, Georg [0] https://code.opensuse.org/heroes/salt/blob/production/f/pillar/role [1] https://code.opensuse.org/heroes/salt/blob/production/f/pillar/common/sudo.s... [2] https://progress.opensuse.org/projects/opensuse-admin/issues [3] https://gitlab.infra.opensuse.org/infra/salt