[spunz]

http://www.linux-user.de/ausgabe/200...nswergirl.html

Passwortlos

Will man den Datenabgleich beispielsweise über einen Cronjob automatisieren (vgl. "Diener auf die Minute", LU 12/2000 S. 80ff.), wird die Passworteingabe zum Problem. Es lässt sich lösen, wenngleich Sicherheitsfanatiker/innen ein Auge zudrücken sollten.

Das Stichwort heißt Public-Key-Kryptographie: Man hat ein Schlüsselpaar, von dem man den einen Schlüssel geheim hält und den anderen öffentlich verteilt. Authentifizierung ist nur dann möglich, wenn beide -- geheimer und öffentlicher Schlüssel -- zusammen kommen. Wie wir der Manpage zu ssh entnehmen können, unterstützt unsere gewählte Übertragungsmethode dies.

Was wir tun müssen, ist, zunächst einmal den Schlüssel für den Rechner zu generieren, der das Backup-Skript ausführt. Beinahe hätten wir's erraten: Der Befehl dazu heißt ssh-keygen ("ssh-key generation" -- Erzeugen des ssh-Schlüssels).

[trish@lillegroenn ~]$ ssh-keygen
Generating RSA keys: ..................ooooooO.................ooooooO
Key generation complete.
Enter file in which to save the key (/home/trish/.ssh/identity): [Enter]
Enter passphrase (empty for no passphrase): [Enter]
Enter same passphrase again: [Enter]
Your identification has been saved in /home/trish/.ssh/identity.
Your public key has been saved in /home/trish/.ssh/identity.pub.
The key fingerprint is:
f7:68:22:9f:a3:be:37:7c:7f:92:c2:fb:a1:86:ff:fe trish@lillegroenn.troll.no


Wer seinen geheimen Schlüssel in der vorgeschlagenen Datei ~/.ssh/identity abspeichern will, bestätigt einfach nur mit der Enter-Taste, anderenfalls ist ein Dateiname, am besten mit Pfad fällig.

Kritisch wird es bei der Frage nach dem Passwort: Normalerweise würden wir eins setzen, um den privaten Key zu schützen, aber dann müssten wir ja auch wieder eins eingeben -- ein unendlicher Kreis. Daher beißen wir diesmal in den sauren Apfel und tippen wiederum nur Enter. Auch bei der letzten Bitte um Wiederholung des (nunmehr leeren) Passworts gilt es, nichts als Enter einzugeben. Wem der passwortlose Key nicht geheuer ist, kann die Sicherheit immerhin dadurch erhöhen, dass er oder sie des Öfteren einen neuen Key generiert und verteilt.

Den öffentlichen Schlüssel (abgespeichert mit der Endung .pub) nehmen wir jetzt und übertragen ihn auf den Backuprechner -- natürlich über SecureShell (also mit scp oder per Copy&Paste, während man mit ssh eingeloggt ist). Er muss jedenfalls in die dortige Datei ~/.ssh/authorized_keys eingetragen werden, z.B. so:

[trish@lillegroenn ~]$ cat ~/.ssh/identity.pub | ssh -v pjung@backup.linux-user.de cat - >> ~/.ssh/authorized_keys


Dieses umständliche Prozedere statt einem einfachen scp ~/.ssh/identity.pub pjung@backup.linux-user.de:~/.ssh/authorized_keys ist nötig, wenn ~/.ssh/authorized_keys auf backup.linux-user.de schon andere Schlüssel beherbergt. Durch das doppelte >> erreichen wir, dass die mit dem zweiten cat ausgegebene Standardeingabe zu ssh (symbolisiert durch ein -) ans Ende von ~/.ssh/authorized_keys angehängt wird.

Woher kommt diese Eingabe für ssh, die diese an das auszuführende Remote-Kommando cat - >> ~/.ssh/authorized_keys weitergibt? Hier ist die Pipe | verantwortlich, die die Ausgabe von cat ~/.ssh/identity.pub ins ssh-Kommando hinein geschubst.

Jetzt heißt es nur noch testen, ob das Skript tatsächlich ohne Passwort funktioniert. Wenn ja, steht einem Backup-Cronjob nichts mehr im Wege. (pju)