Ich lese gerade einen Artikel in Master Linux Now 2013 namens OpenSSH: Easy Logins und es verwendet ssh-agent damit Sie einmal eine Passphrase für Ihren Schlüssel eingeben können und sich dann frei mit einem Remote-Computer verbinden können, ohne sie erneut eingeben zu müssen, während der ssh-Agent ausgeführt wird.
Der Grund, warum ich mich überhaupt zu dem Artikel hingezogen fühlte, abgesehen davon, dass ich mein Passwort nicht millionenfach neu eingeben musste; war so, dass ich unbeaufsichtigte Backups von /auf Remote-Rechnern durchführen konnte, indem ich rsync von cron auf einem Remote-Rechner zum Server über ssh aufrief;
Ich habe einen anderen Artikel gesehen, in dem jemand einfach die Passphrase übersprungen hat, damit Cron den Schlüssel einfach zum Anmelden verwenden kann, es fühlt sich nicht richtig an, aber ist das in der Praxis in Ordnung? Ich meine, wenn jemand diese Schlüsseldatei in die Hände bekommen würde, könnte er Chaos auf der Maschine anrichten, die gesichert wird.
Es scheint mir sicherer zu sein, sicherzustellen, dass der Benutzer beim Neustart angemeldet ist, und ihn die Passphrase einmal eingeben zu lassen, wenn er sich anmeldet, um den Agenten auszuführen, und dann einfach zu warten, bis der Cron-Job mit gesperrtem Bildschirm ausgeführt wird. aber wahrscheinlich vermisse ich hier etwas, z. B. darüber, mit welchen Benutzern oder Benutzertypen Cron-Jobs ausgeführt werden.
Akzeptierte Antwort:
Schränken Sie die Befehle ein, die durch die Taste aufgerufen werden können
Wenn ein SSH-Schlüssel für irgendeine Art von automatisierter oder unbeaufsichtigter Aufgabe verwendet werden soll, sollten Sie einschränken, welche Befehle er auf einem Remote-Computer ausführen kann, unabhängig davon, welche Entscheidung Sie darüber treffen, wie und wo der Schlüssel gespeichert wird.
Verwenden Sie so etwas in ~/.ssh/authorized_keys :
command="/usr/sbin/the-backup-daemon" ssh-rsa AAAAAAAAAAAABBBBBXXXXXX.....
Auf diese Weise sollte zumindest der Schlüssel nicht in der Lage sein, wie Sie sagen, Chaos anzurichten. Es kann nur auf das zugreifen, worauf es zugreifen soll, usw. Es kann höchstwahrscheinlich immer noch Schaden anrichten, aber es sollte weniger als vollen Zugriff auf das Remote-System haben.
Sie können auch die IP-Adressen einschränken, die mit diesem Schlüssel eine Verbindung herstellen dürfen, und eine Reihe anderer SSH-Funktionen deaktivieren, z. B. die Portweiterleitung für Verbindungen, bei denen dieser Schlüssel verwendet wird:
from="10.1.2.3",no-port-forwarding,no-X11-forwarding,no-agent-forwarding,no-pty,command="/usr/sbin/the-backup-daemon" ssh-rsa AAAAAAAAAAAAXXXXXX.....
All das muss in einer einzigen Zeile in ~/.ssh/authorized_keys stehen .
Schutz des Schlüssels
Das hängt von Ihrem Bedrohungsmodell ab.
Wenn Sie befürchten, dass der Schlüssel gestohlen wird, während er „kalt“ ist, z. B. wenn der Computer, auf dem er gespeichert ist, physisch gestohlen wurde, dann möchten Sie ihn nicht ohne Passphrase an diesem Ort speichern.
Sie könnten Starten Sie nach dem Booten des Servers manuell eine Art Hintergrund-SSH-Agent, fügen Sie den Schlüssel zu diesem Agenten hinzu und zeichnen Sie den $SSH_AUTH_SOCK des Agenten auf für die zukünftige Verwendung durch den Cron-Job, aber ehrlich gesagt klingt das nach mehr Ärger, als es wert ist. Sie können den unverschlüsselten Schlüssel auch einfach in einem tmpfs speichern Dateisystem und lassen Sie den Cron-Job von dort darauf zugreifen. In jedem Fall lebt der Schlüssel nur im Speicher (wenn Sie keinen Swap oder einen verschlüsselten Swap haben). Natürlich sollten Sie chown und chmod die Datei, sodass nur der Zielbenutzer darauf zugreifen kann.
Andererseits, wenn Sie sich darüber Sorgen machen, haben Sie diesen Computer wahrscheinlich bereits mit einem verschlüsselten Root-Dateisystem und Swap (z. B. luks) eingerichtet, sodass Sie sich möglicherweise nicht darum kümmern müssen.
Wenn Sie sich Sorgen machen, dass der Schlüssel gestohlen wird, während er „heiß“ (im Speicher geladen) ist, können Sie nicht viel dagegen tun. Wenn der Cron-Job darauf zugreifen kann, kann dies auch etwas anderes tun, das denselben Zugriff erhalten hat. Es ist das, oder geben Sie die Bequemlichkeit der unbeaufsichtigten Auftragsausführung auf.
Abschließend sollten Sie einen Backup-Server als sehr privilegiertes System behandeln, da er zwangsläufig Lesezugriff auf die vollständigen Dateisysteme aller Computer erhält, die er sichert. Ihr Backup-Server sollte beispielsweise nicht aus dem Internet erreichbar sein.