Ssh-verbindung mit crontab automatisieren

1603
geotheory

Ich habe Schwierigkeiten gehabt, mit gsh einen git-Push-Prozess mit ssh zu automatisieren, und es ist schwierig, einen Schlüssel mit dem ssh-Agenten einzurichten. Beginnen Sie mit einem einfachen Skript, um den Agenten zu testen:

# set paths (all examples) source /etc/profile export PATH=$PATH:/Users/myusername/.ssh  eval "$(ssh-agent)" > ssh_agent.txt /usr/bin/ssh-add -l >> ssh_agent.txt

..was gibt folgendes aus:

Agent pid 16062 The agent has no identities.

Der Agent ist also aktiv. Jetzt den Schlüssel hinzufügen und prüfen, ob er beim Agenten registriert ist. In iTerm2 manuell funktioniert das ok:

/usr/bin/ssh-add /Users/myusername/.ssh/id_rsa 2048 [key fingerprint] /Users/myusername/.ssh/id_rsa (RSA)

Ich versuche dies innerhalb eines Crontab-Jobs mit diesem Skript zu replizieren:

/usr/bin/ssh-add /Users/myusername/.ssh/id_rsa /usr/bin/ssh-add -l >> ssh_agent.txt

..was berichtet The agent has no identitiesin die Datei, und über "You have mail in /var/mail/myusername":

[email metadata] Enter passphrase for /Users/myusername/.ssh/id_rsa:

Der Schlüssel versucht also zu laden, fängt jedoch an der Passphrasen-Eingabeaufforderung an. Hier möchte ich expectdie Passphrase verwenden, wie in dieser Antwort von unix.stackexchange beschrieben (die anscheinend unter OSX funktionieren sollte):

#!/usr/bin/expect -f /usr/bin/ssh-add /Users/myusername/.ssh/id_rsa expect "Enter passphrase for /Users/myusername/.ssh/id_rsa:" send "mypassphrase\n"; interact

Die E-Mail-Fehlerantwort lautet:

Enter passphrase for /Users/myusername/.ssh/id_rsa:  couldn't read file "Enter passphrase for /Users/myusername/.ssh/id_rsa:": no such file or directory /Users/myusername/test/crontest.sh: line 17: send: command not found /Users/myusername/test/crontest.sh: line 18: interact: command not found

Also habe ich eine alternative Konfiguration basierend auf dieser SO-Antwort versucht :

#!/usr/bin/expect -f expect -c " /usr/bin/ssh-add /Users/myusername/.ssh/id_rsa expect \"Enter passphrase for /Users/myusername/.ssh/id_rsa: \" send \"mypassphrase\n\"; interact "

.. und erhalten Sie den folgenden Mail-Fehlerbericht:

invalid command name "/usr/bin/ssh-add" while executing "/usr/bin/ssh-add /Users/myusername/.ssh/id_rsa" Could not open a connection to your authentication agent.

Ich verstehe das Problem hier nicht - der SSH-Agent funktioniert und der Schlüssel scheint zugänglich zu sein. Was ist das Problem mit der Verbindung? Ich habe andere Konfigurationen expectohne Erfolg ausprobiert . Sehr dankbar für Hilfe.

1
NB `eval" $ (ssh-agent) "muss in ein Arbeitsskript aufgenommen werden, da dieses tatsächlich den Agenten initiiert (http://stackoverflow.com/a/17848593/1156245). geotheory vor 9 Jahren 0

2 Antworten auf die Frage

1
Anthony Geoghegan

Ich würde es nicht empfehlen, in einem cron-Job ssh-addoder expectin einem cron-Job zu laufen, da es übermäßig kompliziert ist, ihn in der begrenzten Umgebung auszuführen, in der cron seine Jobs ausführt, und ich möchte keine Passwörter in der crontab speichern.

Anstelle Ihres regulären SSH-Schlüssels würde ich einen neuen Schlüssel erstellen, der nur dazu verwendet wird, den Befehl auszuführen, den Sie mit cron ausführen möchten. Ich würde den Schlüssel ohne Passphrase konfigurieren und dessen Besitz / Berechtigungen ändern (0600), sodass nur mit der effektiven Benutzer-ID, unter der der Cron-Job ausgeführt wird, darauf zugegriffen werden kann, dh der ID der Benutzer, deren Crontab gerade verwendet wird verarbeitet.

In Ihrem speziellen Fall muss der git pushneue Schlüssel auf Ihren Git-Server hochgeladen werden. Die meisten Git-Server sollten in der Lage sein, mehrere öffentliche SSH-Schlüssel zu akzeptieren.

Im Allgemeinen ist es für automatisierte Prozesse am besten, spezifische Schlüssel ohne Passphrasen zu erstellen. Ein eingeschränkter Satz zulässiger Befehle wird dann auf dem Remote-SSH-Server konfiguriert, indem der Zeile in der authorized_keysDatei Optionspaare vorangestellt werden, z.

command="automated-task.sh",client=my.local.host,no-pty,no-agent-forwarding,no-port-forwarding ssh-rsa AAA…public…part…of…specific…keypair automated_user@server

Haftungsausschluss: Ich habe mehr Erfahrung mit GNU / Linux als OS X, aber AFAIK, die obigen Informationen sollten für alle * nix-Systeme gelten.

Das funktioniert gut. Danke Anthony Würden Sie sagen, dass der Standard-OSX chmod 600 für einen privaten Schlüssel ausreicht? geotheory vor 9 Jahren 0
@geotheory Freut mich zu hören. 600 klingt genau richtig. Anthony Geoghegan vor 9 Jahren 1
Ich habe gerade meine Antwort mit den Dateiberechtigungen aktualisiert. Anthony Geoghegan vor 9 Jahren 0
1
Anthony Geoghegan

Alternative Antwort

Ich dachte nur, ich schaue mir Ihre expectSkripte genauer an und bemerkte, dass ihnen der spawnBefehl fehlte :

#!/usr/bin/expect -f spawn /usr/bin/ssh-add /Users/myusername/.ssh/id_rsa expect "Enter passphrase for /Users/myusername/.ssh/id_rsa:" send "mypassphrase\n"; interact

Aus dem expectHandbuch:

spawn [args] programm [args]

Erzeugt einen neuen Prozess, in dem Programmrunden ausgeführt werden. Stdin, stdout und stderr sind mit Expect verbunden, so dass sie von anderen Expect-Befehlen gelesen und geschrieben werden können. Die Verbindung wird durch Schließen unterbrochen, oder wenn der Prozess selbst einen der Dateikennungen schließt.

Ich habe "Spawn: Befehl nicht gefunden", was aussieht, als wäre bash ein falscher Interpreter, was die Gründe für die zweite Methode erklärt, die ich ausprobiert habe. Also habe ich diese Version mit 'spawn' ausprobiert, die auf quälende Weise zurückkommt: `spawn / usr / bin / ssh-add /Users/myusername/.ssh/id_rsa Passphrase für /Users/myusername/.ssh/id_rsa eingeben: Dennoch "Der Agent hat keine Identitäten", so ist immer noch etwas falsch. geotheory vor 9 Jahren 0

Verwandte Probleme