cron-job unter Linux Mint

[frabron]

Ich bekomme:

SSH_AUTH_SOCK=/run/user/1000/keyring/ssh

Hattest du den Post auf superuser gelesen? Mach mal wie da vorgeschlagen

Add this to the top of your crontab, e.g., SSH_AUTH_SOCK=/Users/USER/.ssh/ssh_auth_sock

und passe den Pfad halt entsprechend deines Pfades an ...

 

[Orion66]

crontab -e

SSH_AUTH_SOCK=/home/privat/.ssh/id_ed25519_ohne_pw

27 13 * * * /home/privat/RebootCheck.sh >> /home/privat/cron.log 2>&1

im Log /home/privat/cron.log dann:

/bin/sh: 1: /home/privat/RebootCheck.sh: Permission denied

 

[frabron]

Du hattest geschrieben:

SSH_AUTH_SOCK=/run/user/1000/keyring/ssh

Und jetzt schreibste das hier, passt nicht ganz, oder?

SSH_AUTH_SOCK=/home/privat/.ssh/id_ed25519_ohne_pw

Die Variable verweist nicht auf deinen Public-Key, sondern auf den keyring des ssh-agents, der benötigt wird, um deinen Public-Key zu lesen ... oder so ähnlich.

Du müsstest also die Zeile in der crontab so umschreiben:

SSH_AUTH_SOCK=/run/user/1000/keyring/ssh

Wobei ich jetzt nicht weiß, ob /run/user/... gefüllt ist, wenn du als Nutzer nicht angemeldet bist ... Versuch macht kluch

 

[Orion66]

Und jetzt schreibste das hier, passt nicht ganz, oder?

hmmm, ich war wohl ein wenig verwirrt

Nun hab ich's korrigiert:

SSH_AUTH_SOCK=/run/user/1000/keyring/ssh

Und: es funktioniert tatsächlich !

@frabron und alle anderen Beiträge: vielen Dank für die Hilfe und vorallem Geduld.

lg

 

[frabron]

Cool, freut mich, dass das jetzt klappt 👍. Sonst wären mir langsam aber auch die Ideen ausgegangen 😁
Aber bei Cron in 80% der Fälle wird entweder der Pfad zu irgendetwas nicht gefunden oder es fehlt was aus der normalen Nutzerumgebung, wie hier ne Variable.

 

[foofoobar]

SSH_AUTH_SOCK=/run/user/1000/keyring/ssh

Und: es funktioniert tatsächlich !

Ich mach mal den Spielverderber: Funzt das auch wenn du nicht angemeldet bist?

 

[Orion66]

Ich denke mal nicht. Das ist allerdings so gut wie nie der Fall.

Für diesen Fall müsste der Eintrag dann wohl in die /etc/crontab ?

 

[frabron]

Ich denke auch, das würde dann nicht mehr funktionieren. Aber dafür gibt es anscheinend

ssh-add

Hab das aber auch noch nie benutzt, von daher ohne Gewähr ...

https://man7.org/linux/man-pages/man1/ssh-add.1.html

 

[SirKhan]

Mal komplett anders gedacht, könnte man das Skript nicht in einem fast leeren Dockercontainer mit Minimal-Alpine oder Debian laufen lassen? Also einen Cronjob darin (oder besser direkt das Skript in einer for-Schleife mit langer Wartezeit).
Damit müsste man auch um das SSH_AUTH_SOCK herumkommen und wäre generell nicht mehr von Sonderheiten des Hostsystems abhängig.
Den Mailversand müsste man vermutlich auch etwas anpassen (SMTP).

 

[foofoobar]

Das ist eindeutig zu wenig Komplexität, der Container muss mindestens in einen Kubernetes-Cluster laufen.

 

[SirKhan]

Klar ist es ein wenig Kanonen auf Spatzen, aber es würde das Problem hier ziemlich sicher umgehen. Und auch im nicht angemeldeten Fall laufen

 

[Orion66]

Ich habe mal einen Versuch mit /etc/crontab gemacht:

SSH_AUTH_SOCK=/run/user/1000/keyring/ssh
21 11 * * * privat /etc/cron.d/RebootCheck.sh

Scheint nicht ganz so einfach zu sein. Im versendeten Mail erhalte ich:

Host key verification failed.

Ich nehme an, dass ich das ssh Key Paar besser unter root erstellen und verteilen muss.

 

[frabron]

Kurz, warum? Das macht ja nix anders als der Cron unter deinem User-Account ... SSH ist sehr picky, wer alles auf deine Keys zugreifen darf, normalerweise darf nur der Besitzer auf die Daten zugreifen, auch root nicht!

Und wenn du deinen Key for root erstellst, stehst du wieder vor der selben Problematik wie vorher, du verschiebst das Problem ja nur auf einen anderen Nutzer, von daher verstehe ich den Sinn der Übung nicht ganz.

Wenn es unbedingt ein anderer User sein soll als dein Nutzeraccount, macht es wahrscheinlich mehr Sinn, einen dedizierten User für's Monitoring anzulegen und den zu nutzen ... oder man nutzt eine dedizierte System-Monitoring-Lösung, die einem auch ein paar mehr Daten im Überblick präsentieren kann ...

 

[foofoobar]

Klar ist es ein wenig Kanonen auf Spatzen, aber es würde das Problem hier ziemlich sicher umgehen. Und auch im nicht angemeldeten Fall laufen

Wie konnte ich ich nur vor Jahren ein vergleichbares Problem ohne Container und ssh-agent lösen?
Und was willst du in dem Container anders machen?
Funktionieren bestimmte Sachen in Containern auf wundersame Weise die außerhalb von Containern nicht funktionieren?
Und public-keys kannst du verteilen wie du lustig bist, selbst für andere Usernamen und auch mehrere für einen User.

Ergänzung (24. August 2023)

Ich habe mal einen Versuch mit /etc/crontab gemacht:

SSH_AUTH_SOCK=/run/user/1000/keyring/ssh
21 11 * * * privat /etc/cron.d/RebootCheck.sh

Scheint nicht ganz so einfach zu sein. Im versendeten Mail erhalte ich:

Host key verification failed.

Ich nehme an, dass ich das ssh Key Paar besser unter root erstellen und verteilen muss.

Wenn dir security latte ist: "-o StrictHostKeyChecking=no"

 

[SirKhan]

Funktionieren bestimmte Sachen in Containern auf wundersame Weise die außerhalb von Containern nicht funktionieren?

Ja.

Einfach, weil es eine andere Linux-Distribution ist (z.B. Debian oder Alpine).
Oder weil man, wenn man will, auch einfach alles als root machen kann (ist ja nur innerhalb des Containers).

Ich mein, man muss es nicht verwenden. Ich wollte halt nur mal eine andere mögliche Lösung vorschlagen.

 

[nutrix]

Ich möchte nochmal, wie von mir weiter oben erwähnt, auf die SSH_AUTH_SOCK Umgebungsvariable verweisen. Wenn du im Terminal

env | grep SSH_AUTH_SOCK

Sach mal, eigentlich sollte das per Standard korrekt gesetzt sein? Üblicherweise fummelt man an diesen Einstellungen nicht weiter rum. Ich schaue hier gerade in ein Ubuntu. da taucht die Variable gar nicht auf.

 

[frabron]

Da bin ich ehrlicherweise überfragt, bei mir unter OpenSuse war sie (offensichtlich) gesetzt. Aber vielleicht hat Ubuntu da auch distributionsspezifisch was geändert ... ich hab daheim noch eine aktuelle Ubuntu-VM, da schaue ich gerne noch mal nach, wenn ich wieder zurück bin ...

 

[foofoobar]

Einfach, weil es eine andere Linux-Distribution ist (z.B. Debian oder Alpine).

Bei Sachen von ssh die schon seit Jahrzehnten funktionieren wird dir eine andere Distribution mit hoher Wahrscheinlichkeit nichts bringen.

Oder weil man, wenn man will, auch einfach alles als root machen kann (ist ja nur innerhalb des Containers).

Genau so scheiße sehen auch einige Container aus wo ich schon mal reinschauen "durfte".

Ergänzung (24. August 2023)

Da bin ich ehrlicherweise überfragt, bei mir unter OpenSuse war sie (offensichtlich) gesetzt. Aber vielleicht hat Ubuntu da auch distributionsspezifisch was geändert ... ich hab daheim noch eine aktuelle Ubuntu-VM, da schaue ich gerne noch mal nach, wenn ich wieder zurück bin ...

Dann logge dich mal per ssh oder auf der richtigen Textconsole (Ctrl-Alt-F1) ein, ist die auch dann gesetzt?