☰

SSH-Berechtigung nur im Cron-Job verweigert

tag-icon • tag-icon bash ssh cron
SSH-Berechtigung nur im Cron-Job verweigert

Ich habe ein sehr seltsames Problem. Ich habe ein kleines Bash-Skript erstellt, das einen Befehl auf einem Remote-Host über SSH ausführt (unter Verwendung einer Authentifizierung mit öffentlichem Schlüssel).

Wenn ich dieses Skript manuell über die Befehlszeile ausführe, funktioniert es einwandfrei. Wenn ich es jedoch in /etc/cron.hourly platziere, schlägt es mit Permission denied, please try again.einer Fehlermeldung fehl.

  • Ich habe den Schlüssel im Skript explizit mit festgelegt ssh -i /root/.ssh/id_rsa user@remote "command";
  • das Skript wird als Root ausgeführt (ich habe echo `id` > /tmp/whoami.logzur Überprüfung ein hinzugefügt); und
  • der SSH-Schlüssel ist nicht passwortgeschützt ...

Bei dem System handelt es sich um einen Ubuntu 12.04-Server. Ich habe zur Fehlerbehebung nicht viel Zugriff auf die Remote-Seite, aber wie gesagt, das manuelle Ausführen von SSH oder desselben Bash-Skripts über die Befehlszeile funktioniert.

Irgendeine Idee, warum das passiert oder wie man es beheben kann?

aktualisieren

Es stellte sich heraus, dass ich mich geirrt hatte, und der SSH-SchlüsselWarpasswortgeschützt (mit Schlüsselbund, der den SSH-Agenten lädt), daher ist es aus einem Skript fehlgeschlagen, aber nicht beim Ausführen aus der Bash-Sitzung. Das Hinzufügen . ~/.keychain/$HOSTNAME-shzu meinem Skript hat das Problem behoben (danke an @grawity, der mich in die richtige Richtung gelenkt und eine umfassende Antwort gegeben hat).

Antwort1

Interaktive Befehle und Cron-Jobs werden in unterschiedlichen Umgebungen ausgeführt – insbesondereIn einer interaktiven Sitzung kann ein SSH-Agent ausgeführt oder ein Kerberos-TGT gespeichert sein.Aufgrund der Art und Weise, wie sshAuthentifizierungsmethoden bestellt werden,kann nichtStellen Sie sicher, dass Ihr Schlüssel nur verwendet wird, weil Sie die -iOption hinzugefügt haben.

  • Wenn ein SSH-Agent läuft, sshversucht der Client immer AgentenschlüsselVorunter Verwendung aller explizit angegebenen Schlüssel.

  • Wenn das Netzwerk Kerberos verwendet und ein Kerberos-TGT vorhanden ist, wird OpenSSH es verwendenVorVersuchen Sie die Authentifizierung mit öffentlichem Schlüssel.

Ich weiß nichts über Ihre Umgebung, aber beide Möglichkeiten sind leicht zu überprüfen:

  1. Fügen Sie vor dem Befehl „ unset SSH_AUTH_SOCKund“ hinzu.unset KRB5CCNAMEsshDannFühren Sie das geänderte Skript manuell aus.

    Dadurch wird verhindert, dass das Skript den Agenten oder die Kerberos-Tickets sieht, und es wird nur der explizit angegebene Schlüssel verwendet.

  2. Fügen Sie die -vOption hinzu ssh. Dadurch werden detailliertere Informationen zur Authentifizierung angezeigt.

Sie können -oIdentitiesOnly=yesdem sshBefehl auch etwas hinzufügen. Dadurchzwingt es, den angegebenen Schlüssel zu verwenden.

Und wenn Sie Tipps zum Zugriff auf den Agenten von Cron hinzufügen - noch besser

Dies ist im Allgemeinen nicht zu empfehlen, da der Agent normalerweise eng mit Ihrer interaktiven Anmeldesitzung verknüpft ist. Insbesondere wird er nur gestartet, wenn Sie sich anmelden, und beendet, wenn Sie sich abmelden – und er benötigt Ihr Passwort, um die SSH-Schlüssel tatsächlich freizuschalten (vorausgesetzt, sie waren passwortgeschützt).

Sie haben "Keychain" erwähnt – ist das das OS X-Programm oder das Linux-Skript? (Ich weiß nicht viel über die Architektur von Mac OS X, aber meines Wissens nach macht es dasvielschwieriger, von einem Cronjob aus auf den SSH-Agenten des Benutzers zuzugreifen …)

Antwort2

Eine weitere Problemumgehung für dieses Problem besteht darin, Cron so einzustellen, dass es per SSH auf die lokale Box zugreift, um dann den SSH-Befehl auszuführen, anstatt die Datei oder den Befehl über den lokalen, absoluten Pfad auszuführen. Dadurch wird der KRB5CCNAME zwischengespeichert und funktioniert dort, wo /path/command dies nicht tut.

# Fails:
0 * * * * /home/user/sshscript.sh

# Works:
0 * * * * /usr/bin/ssh user@localhost /home/user/sshscript.sh

#!/bin/bash
# Works:
unset SSH_AUTH_SOCK
unset KRB5CCNAME
/usr/bin/ssh user@localhost /home/user/sshscript.sh

Antwort3

Sie könnenssh-cronum geplante SSH-Verbindungen zu sicheren Servern einzurichten, ohne Ihre SSH-Schlüssel preiszugeben, aber mithilfe eines SSH-Agenten.

Antwort4

Sie können Ihr Skript oder Ihren Befehl in Crontab wie folgt ausführen:

0 * * * * bash -c -l "/home/Benutzer/sshscript.sh"

oder

0 * * * * bash -c -l "ssh root@IhrHost 'echo $HOSTNAME'"

verwandte Informationen