Moin,
ich bastle immer noch an einem Rsync-Script zwecks Backup.
Es geht darum, Dateien auf einem lokalen Rechner zu einem Remoterechner zu sichern.
Bislang habe ich immer den Zielpfad vorab auf einen lokalen Ordner gemountet, und dann die Dateien gesichert. Das funktioniert solange, bis man vergisst den Pfad vorher zu mounten.
Ich könnte natürlich den Mount/Umount-Befehl auch in mein Script packen, finde ich aber "unschön".
Jetzt kann Rsync aber von Haus aus auch direkt auf einen Remotepfad sichern.
rsync /lokaler Pfad / user@remote-ip:/Zielpfad
Dabei fragt Rsync aber das Passwort des Zielrechners ab.
Jetzt habe ich aber einen passwortlosen Zugang zum Remoterechner erstellt, und wenn ich mich vom lokalen Rechner per ssh auf dem Zielrechner einlogge, klappt das jetzt auch ohne PW.
Lasse ich aber mein angepasstes Script laufen, wird wieder nach dem PW des Zielrechner gefragt.
Was habe ich hier vergessen ?
Hi,
Zitat von: Bartimaus am 22 November 2024, 11:41:35Lasse ich aber mein angepasstes Script laufen, wird wieder nach dem PW des Zielrechner gefragt.
das Script läuft mit dem gleichen User wie Dein interaktiver Test?
Gruß Otto
Ja,
aber werden Bash-Scripte nicht automatisch mit "Root-Rechten" ausgeführt ?
Wieso kommst Du darauf? Jeder User kann in seinem Kontext Bashscripte ausführen.
Also nochmal präziser Fragen:
- Arbeitest Du mit ev. sudo im Script?
- Welcher User ruft das Script auf, User fhem aus FHEM heraus? Oder aus einem Crontab?
Hintergrund: rsync braucht Zugriff auf den Private Key mit dem Du deinen "Test" durchgeführt hast. Der liegt per
default: im ~/.ssh Verzeichnis des aktiven Users und darf auch nur von dem gelesen werden.
Wenn es ein andere User ist musst Du den Key im Befehl mitgeben oder für den User per "Standard" verfügbar machen.
Erstmal zu Deinen Fragen:
- Im Script arbeite ich NICHT mit Sudo
- das Script rufe ich händisch mit "sudo bash script.sh" auf
Den PrivateKey habe ich auch mit dem User "Dietpi" erstellt, und auf den Remote/Zielserver kopiert.
Und wenn ich mich mit dem User "Dietpi" per ssh auf den Zielrechner einlogge, werde ich nicht nach dem PW gefragt.
Naja aber Du rufst (warum auch immer?) dein Script mit sudo auf. Damit arbeitest Du im root Kontext und hast per default keinen Zugriff mehr auf deine Umgebung, sprich er nimmt den private Key eventuell nicht aus Deinem Verzeichnis und darf ihn eigentlich nicht lesen (wenn es richtig gemacht ist).
Muss denn das Script mit sudo laufen?
Zitat von: Bartimaus am 22 November 2024, 14:55:24Den PrivateKey habe ich auch mit dem User "Dietpi" erstellt, und auf den Remote/Zielserver kopiert.
Wenn Du das wirklich getan hast, hast Du es überhaupt nicht verstanden!? Man kopiert nur den public Key in die Datei authorized_keys des Zielservers!!!
Du kannst dem Aufruf von rsync mit der Option -i den Standort von Deinen private Key übergeben, der muss dann aber von root gelesen werden dürfen. Und nein: root darf nicht automatisch alles lesen! ;)
Ha, danke Dir !!
Habe im Script jetzt die Option "-i" ergänzt und das ganze ohne "sudo" gestartet, schon funktioniert es.
Ich hatte mich wohl etwas falsch ausgedückt. Den Key habe ich gem. Deines Blogs wie folgt kopiert:
ssh-copy-id -i ~/.ssh/id_rsa <user>@<remote-system>
Öhh, nochmal ne Frage:
Kann man einen Server auch von 2 verschiedenen Servern "steuern" ?
Meinen BackupServer fahre ich von FHEM aus herunter (ohne PW), und von einem anderen Server sichere ich dorthin jetzt auch div. Daten.
Nachdem ich das jetzt eingestellt habe, kann ich den Server nicht mehr aus FHEM herunterfahren, weil der Key scheinbar überschrieben wurde.
Gibts dafür einen Workaroud um von 2 verschiedenen Servern ohne PW damit zu arbeiten ?
Ja natürlich. Die Datei authorized_keys auf dem Server muss dafür beide public_keys enthalten.
Entweder hast Du bei Deiner Einrichtung die datei nicht ergänzt sondern überschrieben? Oder Du hast das Keypärchen auf dem FHEM Server aus versehen neu erzeugt?
Du kannst den public Key von FHEM damit im Browser anzeigen (id_rsa oder id_ed25519 anstatt id_xxx) :
{qx(cat ~/.ssh/id_xxx.pub)}und schauen ob er am Server in der Datei steht:
cat .ssh/authorized_keys
Beachte dabei die User Zuordnung! Also schau beim richtigen User auf dem Server.
Wenn der Key nicht drin steht, kannst Du ihn einfach manuell einfügen wie hier (https://heinz-otto.blogspot.com/2020/09/ssh-mit-public-key.html)beschrieben.
Danke Dir.
Hm, im Remoteserver stehen 4 Keys, einmal aus FHEM und 3x von meinem DietPi-Server.
Der aus FHEM steht auch drin... zumindest wird er es anhand der ersten 20 Stellen sein....
user@remote-ip: Permission denied (publickey,password,keyboard-interactive).
Scheint doch was mit dem Key zu sein.
Edith: Danke für den Link, habe die Keys mal aufgeräumt und neu generiert/kopiert. Jetzt funktioniert es von beiden Servern wie gewünscht.
Liegt es an ssh oder an sudoers?
Klappt das aus der FHEM Kommandozeile (Browser) user und host ersetzen den \ und Rest belassen!
{qx(ssh user\@host echo VomAnderenHost)}Steht was im FHEM Log?
Liegt es an der known_hosts auf dem FHEM Server?
{qx(cat ~/.ssh/known_hosts)}Da musst Du den gleichen hostkey wie auf dem Backup finden...
Kann man ev. so auch in FHEM eintragen lassen.
{qx(ssh -o StrictHostKeyChecking=no user\@host echo VomAnderenHost)}
Hi,
hatte meinen Beitrag editiert ohne Deine Antwort gesehen zu haben. Hätte vorher mal F5 drücken sollen.
Ich werde Deine Tips morgen nochmal befolgen, habe den Server bereits erfolgreich via FHEM heruntergefahren ::)
Jetzt muss ich morgen nur mal prüfen, wie ich den beiden Qnaps ,,ssh copy id" beibringen kann, damit ich den rsync auch ohne pw zwischen beiden qnaps ausführen kann.
Zitat von: Bartimaus am 23 November 2024, 18:16:20,,ssh copy id" beibringen kann, damit ich den rsync auch ohne pw zwischen beiden qnaps ausführen kann.
Wie gesagt, per Hand kopieren ist keine Zauberei - man muss nur wissen was wohin - das steht im Artikel ;)
Moin,
super, ich danke Dir.
Habe den Key jetzt auf dem Zielserver eingetragen, und mein Backup-Rsync-Script (Option "-i" & user@ziel:/Pfad) angepasst.
Die Lösung mit dem vorab mounten des Zielrechners auf einen Pfad im Quellrechner hat mir nicht wirklich gefallen, und führte oft zu Fehlern. Jetzt läuft es sauber durch.
Schönen Restsonntag noch
Auch wenn es gelöst ist:
Der .ssh-Ordner wird im Home-Dir des Users eingetragen. Wie kriegt man jetzt aber das HomeDir raus? Dazu guckt man am besten auf den Rechner in der passwd-Datei nach:
Zitatgrep <username> /etc/passwd
<username>:x:1000:1000:<Name>,,,:<homedir>:/bin/bash
Natürlich muß beim grep der <username> passend ersetzt werden. Es soll passwd-Dateien von Unixen geben, die ein anderes Format haben, dieses ist mir persönlich aber noch nicht untergekommen. oder um es anders zu sagen: unter Linux ist es so ;)
Moin,
heute morgen sollte ein weiteres Backup-Rsync-Script laufen. Dies scheiterte aber wieder an "authentification failed".
Ein händischer Start des Scripts lief aber tadellos.
Da dieses Script aber über "systemd" gestartet werden soll (sobald der Remoteserver online ist), fehlten dem User "Root" aber die Rechte, da systemd scheinbar als Root ausgeführt wird. Also dem User root auf dem Remoterecchner auch die Keys übermittelt, schon lief es.
Mühsam ernährt sich das Eichhörnchen
Moin,
Zitat von: Bartimaus am 25 November 2024, 11:46:06da systemd scheinbar als Root ausgeführt wird.
Das ist nur "per default" so. Du hättest es ändern können: User= Eintrag im unit File. siehe auch https://wiki.fhem.de/wiki/Fhem.service_(systemd_unit_file)
Gruß Otto
Danke Dir, bin ich gerade über Umwege auch drauf gestoßen. Test läuft
Edith: Test abgeschlossen, funktioniert ;)
Und es ist immer wichtig, den User zu nehmen, unter dem das Script läuft.
Und generell: Im Zweifelsfalle versuchen, es nicht unter root laufen lassen (Hast Du mittlerweile auch so gemacht?)
Das Bash-Script wird über einen SystemD-Service gestartet.
Die Datei zum Service habe ich in der "Unit"-Sektion nun um den aktuellen User ergänzt. Jetzt wird das Script nicht mehr mit Root-Rechten gestartet und alles ist fein.