cron-job unter Linux Mint

[nutrix]

@nutrix wie kommst Du auf Reboot? Ich verstehe den TE so, dass er nur den Status auf seinen Servern abfragen will.

Ja, Du hast recht, hätte das Skript genauer lesen sollen.

 

[Orion66]

bevor ich das ganze neu aufbaue mal ne grundsätzliche Frage:
Was macht in meinem Fall mehr sind: Benutzer-Crontab oder Systemweite Crontab (/etc/crontab)?

 

[nutrix]

Das kommt darauf an, was Du machst. Crontab per root sind, wie gesagt, wenn nicht richtig gemacht, eine Sicherheitslücke. Per root funktioniert eben mehr, und man kann hier immer noch ein chmod oder chown hinterher hängen, damit der Benutzer dann mit den Ergebnissen von root ausgeführt was anfangen kann.

Wenn Dein System nicht allzu sicherheitskritisch aufgebaut sein muß, ist ein cronjob per root ok (z.b. Backups). Generell würde ich aber alle Prozesse immer eher Benutzern zuordnen.

 

[foofoobar]

Wirst Du zur Eingabe eines Passworts aufgefordert, egal welches, für den Key oder den Benutzer, wird das Skript mit dieser Meldung abbrechen.

"-o batchmode=yes" bricht sauber ab und bleibt nicht dumm im prompt stehen.

 

[Orion66]

Wie kann ich den Aufruf des Scripts so simulieren, wie das der Cronjob macht?
Weil wenn ich das in der Konsole als privat ausführen, erhalte ich kein Fehler.

Ergänzung (14. August 2023)

@Orion66 wie @foofoobar bereits geschrieben hat, solltest Du einen Schlüssel ohne Passwort erstellen und diesen zur Authentifizierung nutzen.

Genau das habe ich jetzt gemacht, sowohl als privat (war bereits schon Schlüssel ohne PW) und als root.

Leider hat das keine Auswirkung

 

[cbtaste420]

Genau das habe ich jetzt gemacht, sowohl als privat (war bereits schon Schlüssel ohne PW) und als root.

Leider hat das keine Auswirkung

Wie sieht der Cron-Eintrag aus?

 

[Orion66]

05 19 * * * /home/privat/RebootCheck.sh >> /var/log/cron.log 2>&1

 

[cbtaste420]

Okay, eingerichtet für Deinen Benutzer oder Root?
Kannst Du das Skript noch posten?

 

[Orion66]

Für meinen Benutzer "privat". Ich finde den Eintrag unter /var/spool/cron/crontabs/privat

Ergänzung (15. August 2023)

# Liste der Server-IP-Adressen
servers=("server1.home" "server2.home" "server2.home")

# Sende eine E-Mail mit der Zusammenfassung der Server
email_subject="Server-Reboot: Status"
email_body="Zusammenfassung der Server:\n\n"

# Durchlaufe die Liste der Server
for server in "${servers[@]}"; do
    reboot_status=$(ssh privat@$server "cat /var/run/reboot-required 2> /dev/null")
    
    if [ -n "$reboot_status" ]; then
        server_status="Reboot ausstehend !!!"
    else
        server_status="kein Reboot nötig"
    fi
    
    email_body+="$server - $server_status\n"
    echo "$server - $server_status"
done

# eMail verschicken
echo -e "$email_body" | mail -s "$email_subject" mich@meine.domain

 

[frabron]

Moin, hab mal was gegoogelt. Weil cron nicht unter einer normalen Shell läuft, sind häufig vorausgesetzte Umgebungsvariablen nicht gesezt.

Versuche mal, den -i Parameter zum ssh hinzuzügen und explizit auf deine id_rsa zu verweisen

ssh -i /path/to/.ssh/...

Es scheint da auch Probleme mit der SSH_AUTH_SOCK Umgebungsvariable zu geben, die unter Cron wohl nicht immer gesetzt ist, aber vom ssh-agent benötigt wird.

Alternativ gibt es für so Fälle auch noch ssh-cron, Google sagt, das ist unter Ubuntu verfügbar ...

Und noch eine Problemstelle: Hast du ein Passwort auf deinem Key? Das kann wohl auch zu Problemen führen, da unter Cron der Keyring nicht verfügbar / geladen ist, im Gegensatz zu einem Terminal in deiner DE ...

Links:
https://superuser.com/questions/463540/ssh-permission-denied-only-in-cron-job
https://superuser.com/questions/264...but-runs-succesfully-when-run-from-command-li
https://manpages.ubuntu.com/manpages/impish/man1/ssh-cron.1.html

 

[Art Vandelay]

Ähnliche Probleme wie hier von @frabron beschrieben hatte ich auch schon mal. Verursacht durch falsche Pfadangaben im Script. Daher immer absolute Pfade und keine relativen Pfade verwenden, da der Verzeichniskontext bei einem im cron ausgeführten Job ein anderer ist.
Aber ich kann hier im Script keine deartigen Probleme sehen.

 

[Orion66]

Versuche mal, den -i Parameter zum ssh hinzuzügen und explizit auf deine id_rsa zu verweisen

Das hat nicht geholfen.

Habe nun alle keys gelöscht, neu erstellt (ohne Passwort) und neu verteilt.
Egal was ich versuch, ich kriegs einfach nicht hin
Ich glauch, ich sehe den Wald vor lauter Bäumen nicht mehr!

 

[frabron]

Kopf hoch, ssh und Konsorten ist ein schwieriges Thema, und cron hat auch schon vielen graue Haare beschert.

Hab grade gesehen, du leitest die Ausgabe von dem ssh-Kommando nach /var/log um, hast du als normaler Benutzer da überhaupt Rechte für (denke eher nicht)? Wenn nicht, vielleicht kommt das Permission denied auch daher ... mal ins Home-Verzeichnis loggen?

 

[Orion66]

Kopf hoch, ssh und Konsorten ist ein schwieriges Thema, und cron hat auch schon vielen graue Haare beschert.

Danke. Ja, mit diesem Thema habe ich schon einige Stunden in den Sand gesetzt. Aber man lernt dabei auch was.

du leitest die Ausgabe von dem ssh-Kommando nach /var/log

Das war eigentlich nicht die Idee, sondern ein Zwischenstand meiner vielen Versuche. Soll eigentlich nach /home

45 19 * * *  privat   /home/privat/RebootCheck.sh >> /home/privat/cron.log 2>&1

aber damit erhalte ich "/bin/sh: 1: /home/privat/RebootCheck.sh: Permission denied"

 

[nutrix]

Kopf hoch, ssh und Konsorten ist ein schwieriges Thema, und cron hat auch schon vielen graue Haare beschert.

An sich ist es nicht schwierig.

Ergänzung (17. August 2023)

Der Public-Key des neuen Schlüssels muss in die .ssh/authorized_keys des Zielnutzers.
Also wenn man sich mit privat@servername verbindet, dann bei servername nach /home/privat/.ssh/authorized_keys

Ist das .ssh Verzeichnis auch nur für den Benutzer gesetzt?
chmod 700 /home/privat/.ssh
Sind alle Dateien in .ssh auf nur lesen und schreiben gesetzt?
chmod 600 /home/privat/.ssh/*

Ergänzung (17. August 2023)

Für meinen Benutzer "privat". Ich finde den Eintrag unter /var/spool/cron/crontabs/privat

Ergänzung (15. August 2023)

# Liste der Server-IP-Adressen
:

Wo ist denn das Shebang geblieben?

#!/bin/bash oder #!/bin/sh

#!/bin/bash
# Liste der Server-IP-Adressen
:

 

[frabron]

An sich ist es nicht schwierig.

Außer, wenn es schwierig ist - wie hier z.B. 😁

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

eingibst, sollte etwas in dieser Form wie bei mir herauskommen

frank@schnipsel ~> env | grep SSH
SSH_AUTH_SOCK=/run/user/1000/keyring/ssh

Und ich wette, dass diese Information im Cronjob nicht zur Verfügung steht. Sie ist aber wohl eine wichtige Information für den ssh-agent, der zentral für die Schlüsselverwaltung zuständig ist.

Schau dir diesen Post hier mal dazu an: https://superuser.com/a/1457098

Mehr Nerdshit: https://smallstep.com/blog/ssh-agent-explained/

 

[nutrix]

Ich hab ja beruflich viel mit Linux zu tun, aber sowas ist mir bisher auch noch nicht untergekommen, daß eine fehlende SSH_AUTH_SOCK Umgebungsvariable fehlen soll oder fehlte und damit die Ursache des Problems war. Aber probieren hilft über studieren.

 

[Orion66]

Ist das .ssh Verzeichnis auch nur für den Benutzer gesetzt?
chmod 700 /home/privat/.ssh

Auf meinen Zielserver sieht das so aus:

drwx------   2 privat privat     4096 Aug 20 10:07  .ssh

Sind alle Dateien in .ssh auf nur lesen und schreiben gesetzt?
chmod 600 /home/privat/.ssh/*

und so:

-rw-------  1 privat privat  277 Aug 16 20:57 authorized_keys

Wo ist denn das Shebang geblieben?

Ich habe anfänglich nur den relevanten Teil des Scripts gepostet, weil das Script ja funktioniert wenn ich es direkt ohne Probleme und Login-Aufforderung ausführen kann. Der Sehbang ist vorhanden.
Im Post #29 habe ich vergesssen die erste Zeile mitzukopieren

Wenn du im Terminal

env | grep SSH_AUTH_SOCK

Ich bekomme:

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

 

[nutrix]

Ein übler Fehler sind Schmutzzeichen in der authorized_keys, die bei der Übertragung des public keys durch copy&paste entstehen.

Kopiere mal bitte direkt den id_rsa.pub in das Zielverzeichnis unter .ssh, und mache danan

cat id_rsa.pub > authorized_keys

und teste nochmal die ssh-Verbindung.

 

[Orion66]

Kopiere mal bitte direkt den id_rsa.pub in das Zielverzeichnis unter .ssh, und mache danan

Macht leider kein Unterschied.

Ich habe grundsätzlich mit den betreffenden Servern kein Problem mit ssh & key eine Verbindung herzustellen. Ich brauche das sehr viel um Ansible-Playbook auszuführen oder direkt mit den Servern via ssh zu arbeiten.

Somit würde ich meine ssh & key Konfiguration eher ausschliessen.

Ich schätze das Problem muss in der Art und Weise wie cron auf diese Server zugreift liegen