|
Größe: 5565
Kommentar:
|
Größe: 828
Kommentar:
|
| Gelöschter Text ist auf diese Art markiert. | Hinzugefügter Text ist auf diese Art markiert. |
| Zeile 3: | Zeile 3: |
| = Umgang mit Hostkeys = | = Umgang mit Public Keys = |
| Zeile 5: | Zeile 5: |
| == Private Hostkeys == | == Private Keys == |
| Zeile 13: | Zeile 13: |
| === Generierung === {{{ # Erstellt ein RSA-4096 Schluesselpaar. ssh-keygen -t rsa -b 4096 -N "" -f /etc/ssh/ssh_host_rsa_key }}} == Konsistenz der Keys == === Kompromittierter public Key === Die public-Keys der Rechner werden in regelmäßigen Abständen von zentraler Stelle übers Netz eingesammelt und auf Veränderungen überprueft. Sollten sich public-Keys verändert haben, werden die zuständigen Techniker automatisch informiert. Der betroffen Rechner wird aus {{{ssh_known_hosts}}} entfernt. |
|
| Zeile 26: | Zeile 14: |
| Der Rechner meldet beim Versuch sich einzuloggen das Problem und weist alle Verbindungen zurueck. == Administration == === Automatisch === Regelmäßiges Einsammeln der public-Keys und die Benachrichtigung im Falle von Veränderungen. Alle validen Keys werden zu einem {{{ssh_known_hosts}}}-File zusammengefasst und öffentlich gemacht (Webseite, um das File extern zu verbreiten; Filesystem ([[http://www.informatik.uni-bremen.de/t2/ssh/doc/ssh_known_hosts.txt|/home/config/openssh/ssh_known_hosts]]), für die interne Verbreitung). Nicht valide Keys, die aus einer Inkonsistenz her rühren oder nicht unseren Anforderungen (mindestens RSA-2048, Hostdatenbankeintrag erforderlich) genügen, werden unmittelbar aus {{{ssh_known_hosts}}} entfernt. === Nicht automatisch === Im Falle einer Inkonsistenz der public-Keys müssen die, für den betroffenen Rechner, zuständigen Techniker von Hand eingreifen ({{{ssh-check}}}), damit ihre (neuen, anderen) public-Keys wieder in {{{ssh_known_hosts}}} berücksichtigt werden können. Passende Hostkeys müssen von den Technikern selbst erzeugt werden. Wer möchte, dass sich sein Hostkey, z.B. nach einer Neuinstallation, nicht ändert, muss sich selber darum kuemmern (Da wir jedoch dauerhaft und mit hoher aktuallitaet das File {{{ssh_known_hosts}}} für alle Benutzer und Rechner vorhalten, spricht aus meiner Sicht nicht viel dagegen, dass sich HostKeys auch mal ändern können! ). === Tool === Für die Verwaltung der public Hostkeys kann das Script {{{/home/config/bin/ssh-check}}} verwendet werden: {{{./ssh-chek}}} {{{-h}}} Help<<BR>> ''kurze Info.''<<BR>><<BR>> {{{-l}}} List suspended hosts<<BR>> ''Auflistung aller gesperrten Rechner.''<<BR>><<BR>> {{{-n}}} List non trusted hosts<<BR>> ''Auflistung aller nicht-trusted Rechner, die grundsätzlich (auch gesperrte oder invalide Rechner) in {{{ssh_known_hosts}}} berücksichtigt werden.''<<BR>><<BR>> {{{-a}}} List hosts in ssh_known_hosts<<BR>> ''Auflistung aller Rechner, die aktuell in {{{ssh_known_hosts}}} vorhanden sind.''<<BR>><<BR>> {{{-x [hostname]}}} Info about host<<BR>> ''Alle ssh-relevanten Statusinformationen zu einem Rechner.''<<BR>><<BR>> {{{-e [hostname]}}} Unlock suspended host<<BR>> ''Gesperrten Rechner entsperren. (!) Wichtig: Der Hostkey, der vor der Sperrung gültig war, wird wieder aktiviert.''<<BR>><<BR>> {{{-s [hostname]}}} Lock host<<BR>> ''Rechner Sperren. Der Rechner wird bei automatischen Scans nicht mehr berücksichtigt und wird aus {{{ssh_known_hosts}}} entfernt. (!) Wichtig: Der Hostkey bleibt erhalten.''<<BR>><<BR>> {{{-i [hostname]}}} Install host<<BR>> ''Rechner in das System einfügen. Rechner, die bereits Bestandteil des Systems waren werden komplett entfernt und dann neu eingefügt.''<<BR>><<BR>> {{{-u [hostname]}}} Uninstall host<<BR>> ''Rechner aus dem System entfernen. (!) Wichtig: Trusted-Rechner kann man nicht wirklich entfernen. Trusted-Rechner haben einen gültigen/ungültigen public Key oder sind gesperrt, werden aber immer berücksichtigt.''<<BR>><<BR>> {{{-p [portnumber]}}} port != 22<<BR>> ''Verwendung eines vom Default abweichenden Ports.''<<BR>><<BR>> {{{-c}}} Comment required<<BR>> ''Kommentar beifügen.''<<BR>> '''''Beispiele:''''' '''Rechner''' {{{xyz}}} hatte wärend der '''Neuinstallation''' einen anderen Hostkey und ist deshalb automatisch gesperrt worden. Aktuell hat der Rechner wieder den alten Hostkey. ''Mit {{{ssh-check –e xyz}}} wird die Sperrung aufgehoben und der alte Hostkey wieder in {{{ssh_known_hosts}}} eingesetzt.'' <<BR>> '''Rechner''' {{{xyz}}} wurde gehackt. Nach der '''Neuinstallation''' soll der alte Hostkey durch einen '''anderen''' ersetzt werden. ''Mit {{{ssh-check –i xyz}}} wird die ssh-relevante Vergangenheit des Rechners gelöscht. Anschliessend wird der neue Hostkey gescannt und in {{{ssh_known_hosts}}} eingesetzt.'' <<BR>> '''Rechner''' {{{xyz}}} wird in {{{abc}}} '''umbenannt'''. ''Mit {{{ssh-check –u xyz}}} wird die ssh-relevante Vergangenheit des Rechners gelöscht. Mit {{{ssh-check –i abc}}} wird der Rechner in das System eingefuegt, der neue Hostkey gescannt und in {{{ssh_known_hosts}}} eingesetzt. |
Ist ein privater Schlüssel kompromittiert, d.h. möglicherweise in unbefugte Hände gelangt, muß der zugehörige öffentliche Schlüssel umgehend aus der authorized_keys Datei entfernt werden. |
Umgang mit Public Keys
Private Keys
Handling
Die privaten Keys lagern ausschließlich auf den Rechnern, auf denen sie in Gebrauch sind und werden in keinem Fall übers Netz gespielt. Der Transport der Keys kann über USB-Sticks, Disketten usw. erfolgen. Das gleiche gilt für Backups der Keys.
![/!\](/t/moin_static1911/fb3/img/alert.png "/!\"){kind=small}
Wegen der sonst nicht zu kontrollierenden Mißbrauchsgefahr sind nutzergebundene private Keys grundsätzlich mit einer Passphrase zu verschlüsseln!
Kompromittierter private Key
Ist ein privater Schlüssel kompromittiert, d.h. möglicherweise in unbefugte Hände gelangt, muß der zugehörige öffentliche Schlüssel umgehend aus der authorized_keys Datei entfernt werden.