Hallo Thomas, hallo Leute, Am Donnerstag, 23. Oktober 2003 15:42 schrieb Thomas Hertweck:
[scp ohne Passwort]
Ich denke, bei der ganzen Geschichte sollte man aber eines bedenken: So bequem es auch ist, man sollte genau ueberlegen, fuer welche Rech- ner und fuer welche User man so ein scp oder auch ein ssh ohne Eingabe eines Passwortes zulaesst. Wenn man naemlich quasi alle verfuegbaren Rechner innerhalb eines Netzwerkes so ausstattet und einer davon wird kompromitiert (z.B. wegen eines Security-Lochs), dann stehen alle an- deren Rechner (die womoeglich eigentlich sicher waeren, weil dort das Security-Loch nicht vorhanden ist) offen wie ein Scheunentor. Nur mal so als Gedanke...
Der Einwand ist nicht verkehrt ;-) Allerdings halte ich das Risiko für vertretbar, wenn man den Key mit einem Passwort schützt, das man dann einmalig per ssh-add eingibt. Zur Erhöhung der Sicherheit kann man ja die "lifetime" angeben (ssh-add -t xxx), dann wird der Schlüssel nach Ablauf dieser Zeit wieder gesperrt. Ein Angreifer hat dann prinzipiell zwei Möglichkeiten: a) er muss das Passwort für den Key rausbekommen, was nicht einfacher oder schwieriger ist als das Passwort für die einzelnen Rechner zu knacken. Na gut, es ist nur ein Passwort für viele Rechner - im Gegenzug dürfte der Key aber besser verschlüsselt sein ;-) b) er muss den ssh-agent socket "entführen", sprich: $SSH_AUTH_SOCK entsprechend setzen. [1] Dann kann er den Key nutzen, bis die ssh-agent-Sitzung abgelaufen ist. Andererseits: man kann ja die Aktionen, die mit dem Schlüssel auf dem Zielrechner erlaubt sind, passend einschränken - das geht beim Zugriff mit Passwort-Login AFAIK nicht. Bei passender Konfiguration erhält man also einen Sicherheitsgewinn. Gruß Christian Boltz PS: Keys _ohne_ Passwortschutz würde ich nicht empfehlen. [1] Es gäbe noch eine Möglichkeit, die Sicherheit zu erhöhen: der ssh-agent bzw. ssh könnte nachprüfen, ob er gerade im richtigen Prozess oder einem Kindprozess davon (-> pstree) aufgerufen wurde. Damit würde eine "Entführung" durch Setzen von $SSH_AUTH_SOCK wohl verhindert werden, da AFAIK ein neues Login kein Kindprozess eines bestehenden Logins sein kann. Ich weiß allerdings nicht, ob die OpenSSH-Programmierer so was basteln wollen - reicht jemand einen FeatureRequest ein? Oder gibt es sowas schon und ich habs nur noch nicht gefunden? -- Es kann dadurch , daß der Rechner ( wenn er an Trenn - zeichen umbricht [Ratti erklärt ) die falschen Stellen den Begriff erwischt , zu ganz gräß "Plenken" - lichen Effekten kommen in suse-linux] !