SSH Password vs. Key und Schlüsselhandling


#1

Continuing the discussion from Geschwindigkeitsprobleme in der Domäne 06:

Das stimmt IMHO so pauschal nicht.

Ein hinreichend langes Kennwort ist praktisch nicht unsicherer als ein SSH Schlüssel, glaube ich.

Das ganze hängt wohl stark davon ab wie der jeweilige Nutzer (oder Admin!) seine Secrets verwaltet. Eine SSH Private Key der selbst ohne Kennwort auf der Platte rumliegt und vermutlich in diversen Backups und mehreren Rechnern steckt kann auch stark gefährdet sein. Wer Kennworte verwendet (und diese jeweils nur einmal pro System nutzt und diese hinreichend stark macht) wird wohl um einen Password Safe nicht herumkommen. Dieser aus dann auch wieder angreifbar (wie der SSH private key).

Es wird viel über “richtigen Umgang mit Kennwörtern” geschrieben aber ich lese wenig z “richtigem Umgang mit SSH Keys”. Hat da jemand brauchbare Quellen?

Wenn ich so drüber nachdenke macht es ggf. auch Sinn Hinweise zum Schlüsselhandling in die Admin Bibel (aka Selbstverpflichtung) aufzunehmen


#2

Dem stimme ich so zu.

Bzgl. der Vereinbarung des Adminteams, da steht meiner Erinnerung nach drin, dass ein Passwort auf den Schlüssel gesetzt sein muss und dass es nicht ausreicht die Schlüsseldatei verschlüsselt zu speichern.


#3

ssh root@meinserver.de -> DNS “infiltriert” -> du ignorierst known_hosts oder verbindest dich zum ersten mal zum server -> du tippst dein passwort ein -> badabing jemand anderes hat dein passwort. Ein szenario, das in offnenen netzen wie freifunk durchaus passieren kann. (weil anders als beim pub/priv key auth verfahren der schlüssel übertragen wird, du musst also authentizität und sicherung des transportweges sicherstellen).

Daher würde ich diese beiden verfahren nicht als gleichwertig bezeichnen.


zum sichern des schlüssels: ich meine mich zu erinnern, dass wir sogar eine mindestlänge des passworts definiert haben.


Gibt es ein gutes Dokument, dass die Essentials bei der Verwendung von SSH Keys (auch unter Windoof) erklärt? Das sollten wir irgendwo mal referenzieren. (Könnte das auch anderweitig gebrauchen; ich werde beruflich immer mal wieder gebeten Private Keys für andere zu erstellen. Oder ich bekomme nach der Bitte meinen Public Key auf einen Server zu schmeißen den private key des anderen zugeschickt, per email, unverschlüsselt). Ich denke wir dürfen hier durchaus mal etwas Aufklärungsarbeit leisten.


Vielleicht habe ich dich falsch verstanden, daher: Nein, “SSH Keys” sind nicht by default sicherer als Passwörter. Man kann sich auch mit SSH Keys doof anstellen (s. o.).


#4

Um an den SSH-Key zu kommen brauche ich aber physischen oder Remote zugriff auf deinen Rechner, an dein Passwort komm ich durch MitM oder ähnliches einfacher. Best Practices ist afaik: SSH NUR mit SSH-key, SSH-Key hat immer(!) ein Passwort (>=10 Zeichen). So als minimalen Standard finde ich das angemessen.


#5

Eine weitere Regel für sicheren SSH-Zugriff: Der Rootzugriff per SSH darf nicht erlaubt sein. Wenn rootzugriff nötig ist dann bitte mit sudo und auf dem Zielsystem ein sicheres Passwort. Bei wirklich kritischen Systemen den Zugriff auf bestimmte Hosts limitieren oder ein Jumpgateway benutzen. Den SSH-Port zu ändern kann Sicherheit weiter erhöhen. Auch Tools wie Failtoban oder Portknocking können die Sicherheit erhöhen.

Gruß Alex


#6

@Froozen: Auf den Routern gibt es nur einen Benutzer - root.

Davon, dass sudo mehr Sicherheit bietet, bin ich nicht wirklich überzeugt. Insbesondere mit Ansible muss dann sowieso das sudo-Passwort abgeschaltet sein. Es ist halt nachvollziehbarer, wer was gemacht hat.


#7

Ich schon, aber es muss richtig gelebt werden. Sonst ist es ja für viele nicht mehr “su root”


#8

Was man anhand des verwendeten SSH Key für Login auch feststellen könnte.
-> Wie sieht es aus mit Logging von Admin Aktivitäten im allgemeinen? Deployment auditd?


#9

Mir ist nicht bekannt, dass da derzeit jemand dran arbeitet.


#10

Der @FanLin hatte da mal was auf den alten Systemen eingerichtet, ich bezweifle aber dass das noch aktiv ist.


#11

Da wurde (damals) nur mitgelogt, wer sich wann eingelogt hat und jeder hatte seine eigene HISTORY.