cron-job unter Linux Mint

[Orion66]

Hi, stecke wiedermal im Thema crontab fest:

Ich habe ein bash script, welches von LinuxMint aus auf verschiedenen Server den Reboot-Status abfragt:

for server in "${servers[@]}"; do
    reboot_status=$(ssh privat@$server "cat /var/run/reboot-required 2> /dev/null")

privat ist der User auf den Zielserver wie auch auf Linux Mint

Das manuelle Ausführen des Scripts auf der Konsole funktioniert.

Nun soll dieses aber regelmässig via cron ausgeführt werden:

crontab -e

Eintrag:

30 10 * * * /home/privat/RebootCheck.sh >> /home/privat/cron.log 2>&1

Dabei kommt es zum Fehler bei der Anmeldung an den Servern:

Permission denied, please try again.
privat@server1.home: Permission denied (publickey,password).

Ich kann den Fehler nicht finden!
Habt ihr eine Idee?

lg

 

[Hörbört]

hast du dein Script ausführbar gemacht?

chmod +x /home/privat/RebootCheck.sh

Nachtrag: Ich sehe gerade, dass die Fehlermeldung doch eher darauf hindeutet, dass ssh bei der Authentifizierung scheitert (wer richtig liest ist im Vorteil).
Hat der user unter dem dein crobjob ausgeführt wird auch die Zugriffsrechte auf die entsprechenden private keys?

 

[_roman_]

Mit welchen Rechten und User wird da Zugegriffen?

Es steht ja, Permission denied

Ergänzung (14. August 2023)

Ich gehe davon aus, wenn steht bash script, dass der User es dann auch als solches ausführt.
Rest
guter hinweis
wären wir beim allerschlimmsten

chmod 777 .... usw. ....

Welcher User, wem gehört der Ordner, Subordner, das File, welche attribute, änderbar mit chmod

 

[foofoobar]

https://en.wikipedia.org/wiki/Shebang_(Unix) nicht vergessen.

 

[0x8100]

ein "ssh -v" gibt zum debuggen ein paar mehr infos, z.b. welcher key benutzt wird (oder ob es irgendwelche probleme damit gibt)

 

[cbtaste420]

Das manuelle Ausführen des Scripts auf der Konsole funktioniert.

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

 

[Orion66]

Hat der user unter dem dein crobjob ausgeführt wird auch die Zugriffsrechte auf die entsprechenden private keys?

Das ist eine gute Frage: unter welchem User wird der cronjob ausgeführt? Ich ging davon aus, dass es ein Benutzer-Crontab ist, weil ich den Job nicht in /etc/crontab finden kann. Wenn der Job als User "privat" ausgeführt wird, sollte es doch klappen, da ich das Script auf der Konsole manuell erfolgreich ausführen kann.

Das sind die Berechtigungen
Script: Eigentürmer (privat) = lesen + schreiben + ausführen
Key: Eigentürmer (privat) = lesen + schreiben

https://en.wikipedia.org/wiki/Shebang_(Unix) nicht vergessen.

Shebang ist vorhanden:

#!/bin/bash

 

[SirKhan]

Machst du das crontab -e mit oder ohne sudo? Weil mit sudo wird das Skript dann als root ausgeführt, ohne als angemeldeter Nutzer (soweit ich weiß).
Entsprechend wird dann von /root/.ssh/ oder von /home/<user>/.ssh/ die id_*-Dateien verwendet, um sich mittels SSH auf den anderen Rechnern zu authentifizieren.

Ansonsten könnte man noch den Eintrag ändern in sowas wie:

30 10 * * * /usr/bin/su -c "/home/privat/RebootCheck.sh >> /home/privat/cron.log 2>&1" -s /bin/bash <user>

Wobei <user> mit dem tatsächlichen Usernamen geschrieben werden muss.

Ergänzung (14. August 2023)

su startet das Skript dabei quasi als anderer User.

Usage:
 su [options] [-] [<user> [<argument>...]]

Change the effective user ID and group ID to that of <user>.
A mere - implies -l.  If <user> is not given, root is assumed.

Options:
 -m, -p, --preserve-environment      do not reset environment variables
 -w, --whitelist-environment <list>  don't reset specified variables

 -g, --group <group>             specify the primary group
 -G, --supp-group <group>        specify a supplemental group

 -, -l, --login                  make the shell a login shell
 -c, --command <command>         pass a single command to the shell with -c
 --session-command <command>     pass a single command to the shell with -c
                                   and do not create a new session
 -f, --fast                      pass -f to the shell (for csh or tcsh)
 -s, --shell <shell>             run <shell> if /etc/shells allows it
 -P, --pty                       create a new pseudo-terminal

 -h, --help                      display this help
 -V, --version                   display version

 

[foofoobar]

Shebang ist vorhanden:

#!/bin/bash

Ok, dann war das erste Listing nicht vollständig.
Gerade noch mal draufgeschaut, wahrscheinlich läuft im Kontext deiner interaktiven Session ein ssh-agent oder ähnliches. Bau dir ein Schlüssel-pärchen ohne passphrase und nutze diesen key auf Client-Seite mit "ssh -i ...." und bau den key auf der Gegenstelle in die authorized_keys mit forced command rein.

 

[nutrix]

Das ist eine gute Frage: unter welchem User wird der cronjob ausgeführt? Ich ging davon aus, dass es ein Benutzer-Crontab ist, weil ich den Job nicht in /etc/crontab finden kann.

Korrekt. Crontab wird immer unter dem Benutzer ausgeführt, wo Du angemeldet bist.

Reboot erfordert root Rechte. Daher gibts 2 Lösungen

• Script unter root Benutzer über crontab ausführen, dabei sollte aus Sicherheitsgründen nur root diese Datei lesen dürfen!
• Benutzer per sudoers ohne Kennwort root werden lassen (Sicherheitslücke!), dann klappt auch sudo per crontab ohne weitere Nachfrage

 

[Orion66]

Machst du das crontab -e mit oder ohne sudo?

ohne sudo

Wenn ich crontab -e öffne und speichere, erhalte ich "crontab: installing new crontab".
Aber wo wird die crontab gespeichert?

Ansonsten könnte man noch den Eintrag ändern in sowas wie:

30 10 * * * /usr/bin/su -c "/home/privat/RebootCheck.sh >> /home/privat/cron.log 2>&1" -s /bin/bash <user>

Wobei <user> mit dem tatsächlichen Usernamen geschrieben werden muss.

Führt zum Fehler "Passwort: su: Legitimierungsfehler"

 

[nutrix]

Eben, weil - wie ich oben schrieb - Du keinen reboot als normaler Benutzer durchführen darfst.

Du kannst übrigens auch per sudoers unter /etc/sudoers.d/benutzername nur den reboot ohne Kennwort freigeben.

benutzername ALL = NOPASSWD: /bin/reboot

 

[cbtaste420]

Aber wo wird die crontab gespeichert?

Unter /var/spool/cron
Für su ohne Passwort muss das Cron-Skript von Root ausgeführt werden, da sonst wieder nach einem Passwort gefragt wird.
@nutrix wie kommst Du auf Reboot? Ich verstehe den TE so, dass er nur den Status auf seinen Servern abfragen will.
@Orion66 wie @foofoobar bereits geschrieben hat, solltest Du einen Schlüssel ohne Passwort erstellen und diesen zur Authentifizierung nutzen.
Die von @SirKhan gegebenen Hinweise zur Ausführung von su benötigen Root-Rechte, entsprechend dann sudo crontab -e ausführen, damit der Eintrag für root angelegt wird.

 

[guzzisti]

Für mich grad nicht offensichtlich:
Warum brauchst Du in der Crontab den Umweg über su?

 

[cbtaste420]

Die Schleife ist unnötig, wurde aber oben weiter vorgeschlagen und erzeugt ggf. jetzt Folgefehler.

 

[0x8100]

Rebooterfordert root Rechte.

das reboot kommando wird doch gar nicht gebraucht hier? somit ist kein sudo/root notwendig. es geht doch nur darum, dass remote per ssh ein "cat" ausgeführt wird.

 

[Orion66]

Ich möchte nur wissen, auf welchen Server ein Reboot ausstehend ist (nach automatischen Updates). Den Reboot muss ich manuell machen, da die Server mit mit LUKS verschlüsselt sind und die PW Eingabe bei Start verlangen

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

Ich werde das mal versuchen umzubauen

 

[cbtaste420]

Den Reboot muss ich manuell machen, da die Server mit mit LUKS verschlüsselt sind und die PW Eingabe bei Start verlangen

Eignetlich nicht -> https://www.cyberciti.biz/security/how-to-unlock-luks-using-dropbear-ssh-keys-remotely-in-linux/

 

[Orion66]

Klingt interessant. Ich merk mir das mal. Aktuell mache ich das übers Webinterface vom ESXi. Ist recht einfach.
Brauche einfach die Info dass Reboots ausstehend sind.

Ergänzung (14. August 2023)

Gerade noch mal draufgeschaut, wahrscheinlich läuft im Kontext deiner interaktiven Session ein ssh-agent oder ähnliches. Bau dir ein Schlüssel-pärchen ohne passphrase und nutze diesen key auf Client-Seite mit "ssh -i ...." und bau den key auf der Gegenstelle in die authorized_keys mit forced command rein.

Soll der neue Schlüssel mit root@Servername oder mit privat@servername verbunden werden?
Dies frage ich mich, weil ich beim ersten Verbinden ja gefragt werde: "
This key is not known by any other names
Are you sure you want to continue connecting (yes/no/[fingerprint])? "

Bisher habe ich das jeweils mit privat@servername gemacht.

 

[SirKhan]

Soll der neue Schlüssel mit root@Servername oder mit privat@servername verbunden werden?

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
Der lokale Benutzername ist dabei egal.

Oder umgekehrt, wenn der Public-Key in /home/privat/.ssh/authorized_keys von servername steht, dann privat@servername, wenn es in /root/.ssh/authorized_keys steht, dann root@servername.
(Natürlich Standardhomeordner vorausgesetzt).