Das ist nicht nur sinnvoll, sondern die einzige Möglichkeit.breakthewall hat geschrieben:Wäre es nicht sinnvoller SSH-Schlüssel zu löschen die nicht genutzt werden sollen? Oder besser noch, erst gar nicht zu erstellen?
- wenn man einem Ex-Mitarbeiter den Zugang sperren willuname hat geschrieben:Welchen Sinn soll es machen bestimmte Keys zu verbieten?
Natürlich muss man alle Einträge des öffentlichen Schlüssels auf allen Servern löschen. Nicht mehr und nicht weniger.- wenn man einem Ex-Mitarbeiter den Zugang sperren will
- wenn der zum öffentlichen Schlüssel gehörende private Schlüssel kompromitiert wurde (Notebook geklaut)
Code: Alles auswählen
AuthorizedKeysFile /var/keys/%u/authorized_keysDie Blacklist hatte aber einen anderen Grund. In einer älteren Debianversion war SSH kaputt und hat mit ssh-keygen nur 65536 verschiedene Keys erzeugen können, was die Sicherheit entsprechend extrem reduziert hatte. Diese 65536 Keys wurden in die Blacklist aufgenommen.eggy hat geschrieben:Früher (in sid nicht mehr, in stable noch drin) gabs mal https://packages.debian.org/de/stable/openssh-blacklist , ka, ob das in deinem Szenario hilfreich wäre.
Es geht hier um Ex-Mitarbeiter, kommt zum glück nicht häufig vor, aber wenn ist man schon mal länger Dabei.MSfree hat geschrieben:- wenn man einem Ex-Mitarbeiter den Zugang sperren willuname hat geschrieben:Welchen Sinn soll es machen bestimmte Keys zu verbieten?
- wenn der zum öffentlichen Schlüssel gehörende private Schlüssel kompromitiert wurde (Notebook geklaut)
Das ist unnötig unsicher. Besser wäre wenn die öffentlichen Schlüssel außerhalb vom HOME-Verzeichnis liegen.und wenn in einem "Home Dir" ein key hinzugefügt wird, wird dieses mit geloggt und überprüft.
openssl-blacklist nicht mehr benötigt wird? Nur weil fast 10 Jahre vergangen sind?Ja, das war mir klar, aber man kann (soweit ich mich erinnere) mit ssh-vulkey und ner entsprechend angepassten Blacklist die authorized-keys durchgehen und auf eigene Keys prüfen. Muss man halt entsprechend zusammenbasteln. Der Hinweis war als "wenn Du basteln willst, da gabs mal nen Ansatz" gemeint, dachte das wäre offensichtlich.MSfree hat geschrieben:Die Blacklist hatte aber einen anderen Grund. In einer älteren Debianversion war SSH kaputt und hat mit ssh-keygen nur 65536 verschiedene Keys erzeugen können, was die Sicherheit entsprechend extrem reduziert hatte. Diese 65536 Keys wurden in die Blacklist aufgenommen.
ansible.Code: Alles auswählen
#!/usr/bin/ansible-playbook
---
- hosts: projectXY
remote_user: root
become: no
vars_prompt:
- name: "keystate"
prompt: "Soll der ssh-key eingetragen (present) oder entfernt (absent) werden?"
tasks:
# state kann absent oder present sein
- name: Projektzugang auf die Server {{play_hosts}}
authorized_key:
user=root
key="{{ item }}"
state="{{keystate}}"
exclusive=no
with_file:
- ../static/sysadmin@4ma-20150708.pub
when: inventory_hostname in groups.projectXY
# vim: set nowrap ft=yaml:
