• Willkommen im Linux Club - dem deutschsprachigen Supportforum für GNU/Linux. Registriere dich kostenlos, um alle Inhalte zu sehen und Fragen zu stellen.

[Gelöst] ssh PubKey-Authentification für bacula-Director

gehrke

Administrator
Teammitglied
Moin *,

ich habe die Notwendigkeit, vor und nach der Durchführung eines Backup-Jobs (bacula) ein Script auf dem zu sichernden System auszuführen. Das Script läuft und ich kann es manuell vom bacula-Server aus auch per ssh via PubKey-Authentification aufrufen:
Code:
[root@bacula /]# eval $(ssh-agent); ssh-add /root/.ssh/id_rsa_bacula
Agent pid 12879
Enter passphrase for /root/.ssh/id_rsa_bacula: 
Identity added: /root/.ssh/id_rsa_bacula (/root/.ssh/id_rsa_bacula)

[root@bacula /]# ssh root@j3 /root/alternative-os/mount-others.sh on
Nun soll das Script aber vom bacula-Director zeitgesteuert aufgerufen werden:
Code:
Job {
  Name = "j3-1"
  Client = j3-fd 
<...>
  RunBeforeJob = "ssh root@j3 /root/alternative-os/mount-others.sh on"
  RunAfterJob  = "ssh root@j3 /root/alternative-os/mount-others.sh off"
 }
Der Prozess:
Code:
[root@bacula /]# ps aux | grep bacula-dir
bacula    8149  0.0  0.0 976444  6592 ?        Ssl  17:18   0:07 /usr/sbin/bacula-dir -f -c /etc/bacula/bacula-dir.conf -u bacula -g bacula
Ich brauche also eine Möglichkeit, für diesen User zum Start des bacula-Servers einmalig die Passphrase interaktiv einzugeben, vermutlich durch Start das ssh-agents. An welcher Stelle kann ich das am geschicktesten in den Start eines CentOS7-Servers einbauen?

EDIT: Genauer gesagt reicht es aus, wenn ich nach dem Start des Systems den bacula-dir-Daemon manuell starte und diesem irgendwie einen aktiven agent übergeben kann. Automatisiert muss das nicht sein, auch die bacula-Services starten nicht automatisch.

TNX

cu, gehrke
 
OP
gehrke

gehrke

Administrator
Teammitglied
Start des Daemons:
Code:
[root@bacula /]# systemctl start  bacula-dir.service
Da müsste ich mich wohl einklinken. Vermutlich bin ich da mittendrin in systemd...
 
OP
gehrke

gehrke

Administrator
Teammitglied
Zur Vollständigkeit:
Code:
[root@bacula /]# cat /usr/lib/systemd/system/bacula-dir.service
[Unit]
Description=Bacula-Director, the Backup-server
Documentation=man:bacula-dir(8)
After=network.target nss-lookup.target

[Service]
Environment=CONFIG=/etc/bacula/bacula-dir.conf
EnvironmentFile=-/etc/sysconfig/bacula-dir
ExecStart=/usr/sbin/bacula-dir -f $OPTS -c $CONFIG -u $DIR_USER -g $DIR_GROUP
Restart=on-failure
#ExecStartPre=eval $(ssh-agent); ssh-add /root/.ssh/id_rsa_bacula
[Install]
WantedBy=multi-user.target
Der mittlerweile auskommentierte Eintrag 'ExecStartPre ,,,' war ein erfolgloser Versuch von mir. So geht das schon mal nicht.
 
OP
gehrke

gehrke

Administrator
Teammitglied
Sauerland schrieb:
Ich habe pub-key ohne Passphrase eingerichtet, kann mich ohne Passwort verbinden.
Das funktioniert bei mir auch. TNX

Nur ist es nicht das, was ich haben möchte. Unabhängig davon, ob ein passphrase-loses Schlüsselpaar an dieser Stelle ein vertretbares Sicherheitsrisiko ist oder nicht, würde ich gerne wissen, wie man so ein Problem sauber löst - und in diesem Fall scheint es mir notwendig, tiefer in die systemd-Mechanik einzutauchen, als ich das bislang getan habe.

Würde mich weiterhin über einen entsprechenden Tipp freuen...
TNX
 
OP
gehrke

gehrke

Administrator
Teammitglied
gehrke schrieb:
Sauerland schrieb:
Ich habe pub-key ohne Passphrase eingerichtet, kann mich ohne Passwort verbinden.
Unabhängig davon, ob ein passphrase-loses Schlüsselpaar an dieser Stelle ein vertretbares Sicherheitsrisiko ist oder nicht<...>
An dieser Stelle kann man wahrscheinlich das Risiko ganz erheblich minimieren, wenn man auf dem Zielsystem den SSH-Daemon so konfiguriert, dass exakt nur das jeweils eine benötigte Kommando ausgeführt werden darf ( 'command=...').

Beispiel:
http://www.linux-tips-and-tricks.de/de/sicherheit/107-ssh/
 
OP
gehrke

gehrke

Administrator
Teammitglied
gehrke schrieb:
Code:
Job {
  Name = "j3-1"
  Client = j3-fd 
<...>
  RunBeforeJob = "ssh root@j3 /root/alternative-os/mount-others.sh on"
  RunAfterJob  = "ssh root@j3 /root/alternative-os/mount-others.sh off"
 }
Bacula bietet für diesen Fall einen geeigneteren Mechanismus an:
Code:
  ClientRunBeforeJob = "/root/alternative-os/mount-others.sh on"
  ClientRunAfterJob  = "/root/alternative-os/mount-others.sh off"
Der angegebene Code wird dann direkt auf dem Client über den Daemon bacula-fd ausgeführt.

Das scheint mir die beste Lösung zu sein, weil dadurch jegliche Notwendigkeit für automatisierte ssh-Zugriffe elegant entschwindet. Und ich komme wenigstens dieses Mal noch um eine Einarbeitung in systemd rum...
 
Oben