updated docs

Author: michaelbrusegard

.github/workflows/dingseboms.yml

@@ -9,8 +9,7 @@ on:
   workflow_dispatch:
 
 jobs:
-  run-keys-script:
-    name: Update
+  update:
     uses: ./.github/workflows/update-keys.yml
     with:
       environment: dingseboms

.github/workflows/duppeditt.yml

@@ -9,8 +9,7 @@ on:
   workflow_dispatch:
 
 jobs:
-  run-keys-script:
-    name: Update
+  update:
     uses: ./.github/workflows/update-keys.yml
     with:
       environment: duppeditt

.github/workflows/gluteus.yml

@@ -9,8 +9,7 @@ on:
   workflow_dispatch:
 
 jobs:
-  run-keys-script:
-    name: Update
+  update:
     uses: ./.github/workflows/update-keys.yml
     with:
       environment: gluteus

.github/workflows/meieri.yml

@@ -9,8 +9,7 @@ on:
   workflow_dispatch:
 
 jobs:
-  run-keys-script:
-    name: Update
+  update:
     uses: ./.github/workflows/update-keys.yml
     with:
       environment: meieri

.github/workflows/noodlebar.yml

@@ -9,8 +9,7 @@ on:
   workflow_dispatch:
 
 jobs:
-  run-keys-script:
-    name: Update
+  update:
     uses: ./.github/workflows/update-keys.yml
     with:
       environment: noodlebar

.github/workflows/phoenix.yml

@@ -9,8 +9,7 @@ on:
   workflow_dispatch:
 
 jobs:
-  run-keys-script:
-    name: Update
+  update:
     uses: ./.github/workflows/update-keys.yml
     with:
       environment: phoenix

CODEOWNERS

@@ -1,4 +1 @@
-# This file defines the DevOps teams as code owners for all files
-# Reviews from code owners are mandatory to merge pull requests to this repository
-# Essentially, this means DevOps and the organization leaders are the only ones who can manage authorized SSH keys on the servers
-* @hackerspace-ntnu/DevOps
+* @hackerspace-ntnu/devops-ledelsen

README.md

@@ -1,31 +1,47 @@
 # ssh-keys
-Public SSH keys for DevOps members
 
-The `authorized_keys` files on Hackerspace servers are automatically populated with the SSH keys in this repository.
+Public SSH keys for the Hackerspace servers
+
+The `authorized_keys` files on Hackerspace servers are automatically populated with the SSH keys in this repository on a per server basis.
 
 ## Adding a new key
 
-Adding a new key will grant the key owner server access.
+Adding a new key will grant the key owner server access. Only add a key to the servers you need access to.
+
+For services like deployment etc. it is important to add a new key specific for the service instead of reusing an existing one.
+
+1. Generate a new SSH key using `ssh-keygen`.
+
+```bash
+ssh-keygen -t ed25519 -C "your@email.com"
+```
+
+- Use `ed25519` as the key type. It is more modern than `rsa`.
+- For the comment, include a way to contact you, phone number or email (This is not necessary for keys used for services, then a comment with the service name is enough).
 
-1. Generate a new SSH key using your generator of choice (typically PuTTYgen or ssh-keygen)
-   - If using PuTTYgen, ensure you export the keyfiles with the OpenSSH format
-2. Create a new branch, commit and push your **public** key file in the `keys` folder
+2. Create a new branch, commit and push your **public** key file in the appropriate directory for the server inside the `keys` directory.
 
 Typically, a public key file looks something like the following:
+
 ```
-ssh-rsa AAAAB3NzaC1yc2EAAAADAQABAAABAQCuS3I1pwSSUtT6NqeKxa33vwXHQy0f7xlyZHq5dlB3UYJNamDR0KEs/fhxjyCJ8XLf7nJNvojJ5qAtxEJjpnVonM6ehHi3juHxgMJOGIZHcWJ72BpjdcWZk0LuOx0x1qTdHFlU+6aTl27dSgVB+2QQESwQTtVgbIGiNcdt3ES9+Yhc8Sk0PrZ2TW5cTdZJlv/kb/cKgFIk8UQqu5h7TJHyq+L6kbEZrlhB2YmJ1ZICaN2YYsHKvtX5ibkJB4RpAOwOiUHVlDzrlBzjdIKxseCt5oEIANObmdk9YOXfMeAQNJDa3Hx3j5yXuMaJCPFqdwxfzeSOJ+OFGSS5q9FG1Dr/
+ssh-ed25519 AAAAC3NzaC1lZDI1NTE5AAAAINvlUIQHvVRV0D+BY51Fzf2Q/r0wxMA9JPAPFk1iQTQv hackerspace-dev@idi.ntnu.no
 ```
-If you see the word `PRIVATE` anywhere in the file(s) you are commiting, **stop immediately**. Private keys are like passwords should be treated as highly confidential.
 
-1. Open a pull request and have someone review the addition of your key
-2. Merge your key in
+If you see the word `PRIVATE` anywhere in the file(s) you are commiting, **stop immediately**. Private keys are like passwords and should be treated as highly confidential.
+
+3. Open a pull request and have the DevOps leadership review the addition
 
-After your key is merged in, you should get SSH access to the Hackerspace servers soon(tm).
+After your key is merged in, you should get SSH access to the respective server within a few minutes.
+
+> [!NOTE]
+> If you are new to SSH, there is a private guide in the DevOps server documentation on GitHub.
 
 ## Removing a key
 
-SSH keys should be removed from the repository as soon as they are no longer in use. This *especially* applies to retired DevOps members.
+SSH keys should be removed from the repository as soon as they are no longer in use. This _especially_ applies to retired DevOps members.
+
+So when a member leaves the Hackerspace, their keys should be removed.
 
 1. Create a new branch, commit and push the removal of the appropriate key file
-2. Open a pull request and have someone review the removal
+2. Open a pull request and wait for review
 3. Merge the key removal