ssh Berechtigung nur im Cron-Job verweigert


13

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

Wenn ich dieses Skript manuell über die Befehlszeile ausführe, funktioniert es einwandfrei, aber wenn es in /etc/cron.hourly abgelegt wird, schlägt es mit einem Permission denied, please try again.Fehler fehl .

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

Das System ist ein Ubuntu 12.04-Server. Ich habe auf der Remote-Seite nicht viel Zugriff auf die Fehlerbehebung, aber wie gesagt, das manuelle Ausführen von ssh oder dasselbe Bash-Skript über die Befehlszeile funktioniert.

Irgendeine Idee, warum dies passiert oder wie man es behebt?

aktualisieren

Es stellte sich heraus, dass ich mich geirrt hatte und der SSH-Schlüssel durch ein Passwort geschützt war (wobei der Schlüsselbund den SSH-Agenten lud), weshalb er in einem Skript fehlgeschlagen ist, aber nicht, wenn er von der Bash-Sitzung ausgeführt wurde. Das Hinzufügen . ~/.keychain/$HOSTNAME-shzu meinem Skript löste das Problem (danke an @grawity, der mich in die richtige Richtung wies und eine umfassende Antwort gab).


Sind Sie sicher, dass die manuelle Ausführung diesen bestimmten Schlüssel verwendet? Nach dem Deaktivieren SSH_AUTH_SOCKund KRB5CCNAMEUmgebungsvariablen erneut testen .
user1686

Danke für den Vorschlag. Ich bin mir nicht sicher, ob ich dich vollständig verstehe. Ich bin mir ziemlich sicher, dass dieser bestimmte Schlüssel verwendet wird, da ich bei manueller Ausführung einen Befehl auf dem Remote-Host verbinden / ausführen kann. Was genau sollte ich nach dem Deaktivieren dieser Variablen erneut testen?
Yoav Aner

Außerdem - ich verwende keinen ssh-agent, bin mir also nicht sicher, wie SSH_AUTH_SOCKdas zusammenhängt (obwohl ich gerne etwas probiere). Ich greife direkt auf die Schlüsseldatei zu und die Schlüsseldatei ist nicht passwortgeschützt. Wie für KRB5CCNAMEeine schnelle Suche ergab dies etwas mit Kerberos zu tun ist. Wieder - sehen Sie nicht die Verbindung zu diesem Problem, aber vielleicht fehlt mir hier etwas ...
Yoav Aner

Testen Sie natürlich Ihr Skript. Sie können nicht "ziemlich sicher sein, dass dieser bestimmte Schlüssel verwendet wird", bis Sie dies tun, da Cron-Jobs in einer anderen Umgebung als interaktive Befehle ausgeführt werden. Es wäre sogar noch besser, wenn Sie -vdiesem sshBefehl eine Option hinzufügen würden ...
user1686

Aber ich mache das. ssh -iIn beiden Fällen verwende ich den Befehl key explizit mit ... Ich werde versuchen, diese Variablen im Skript zu deaktivieren und zu sehen. Guter Vorschlag zum Hinzufügen -v- ich werde es auch hinzufügen.
Yoav Aner

Antworten:


11

Interaktive Befehle und Cron-Jobs werden in verschiedenen Umgebungen ausgeführt. In einer interaktiven Sitzung wird möglicherweise ein SSH-Agent ausgeführt oder ein Kerberos-TGT gespeichert. Aufgrund der Art und Weise ssh, wie Authentifizierungsmethoden bestellt werden, können Sie nicht sicher sein, dass Ihr Schlüssel verwendet wird, nur weil Sie die -iOption hinzugefügt haben .

  • Wenn ein SSH-Agent ausgeführt wird, versucht der sshClient immer, Agentenschlüssel zu verwenden, bevor explizit angegebene Schlüssel verwendet werden.

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

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

  1. In unset SSH_AUTH_SOCKund unset KRB5CCNAMEvor dem sshBefehl, dann manuell das modifizierte Skript ausführen.

    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 . Dadurch wird die Verwendung des angegebenen Schlüssels erzwungen .


Und wenn Sie Tipps für den Zugriff auf den Agenten von cron hinzufügen - noch besser

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

Sie haben "Schlüsselbund" erwähnt - ist dies das OS X-Programm oder das Linux-Skript? (Ich weiß nicht viel über die Architektur von Mac OS X, aber AFAIK macht es viel schwieriger, von einem Cronjob aus auf den SSH-Agenten des Benutzers zuzugreifen ...)


1
Sie können ssh-cron verwenden, um geplante SSH-Verbindungen zum Sichern von Servern einzurichten, ohne Ihre SSH-Schlüssel offenzulegen, aber den SSH-Agenten zu verwenden. superuser.com/questions/463540/...
Luchostein

5

Eine weitere Problemumgehung für dieses Problem besteht darin, cron auf ssh in der lokalen Box zu setzen, um wiederum den Befehl ssh auszuführen, anstatt die Datei oder den Befehl über ihren lokalen, absoluten Pfad auszuführen. Dies speichert den KRB5CCNAME zwischen 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

1

Sie können ssh-cron verwenden , um geplante SSH-Verbindungen zum Sichern von Servern einzurichten, ohne Ihre SSH-Schlüssel offenzulegen, aber den SSH-Agenten zu verwenden.


Die Abhängigkeiten sind in Homebrew nicht verfügbar, daher scheint die Installation kompliziert zu sein. Passwortloser Schlüssel, denke ich…: - /
Charlie Gorichanaz

-1

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

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

oder

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


1
OP versucht bereits, das Skript über auszuführen cron. Das scheint also keine wirkliche Antwort zu geben.
Bertieb
Durch die Nutzung unserer Website bestätigen Sie, dass Sie unsere Cookie-Richtlinie und Datenschutzrichtlinie gelesen und verstanden haben.
Licensed under cc by-sa 3.0 with attribution required.