Konfiguration mit Lsyncd synchronisieren

Hallo!

Heute möchte ich euch ein Tool vorstellen mit dem man relativ einfach, sicher und in nahezu realzeit Konfiguration auf andere Systeme und umgekehrt synchronisieren kann. Das Tool hoert auf den Namen Live Syncing (Mirror) Daemon, oder kurz gefasst Lsyncd.

Als erstes möchte ich etwas auf die Magie von Lsyncd eingehen, damit man einen Eindruck bekommt wie das Tool arbeitet und was für Möglichkeiten sich ergeben. Lsyncd verwendet unter Linux inotify und unter MacOS FSEvents um Änderungen am Verzeichnissbaum zu beobachten. Anhand dieses “Monitorings” kann Lsyncd feststellen, ob Änderungen im zur synchronisation bestimmten Verzeichnis passiert sind. Ist dies der Fall, startet Lsyncd die synchronisation mit den zuvor entsprechend gesetzten Parametern. Die Parameter sind z.B. welches Verzeichniss von soll wohin repliziert werden und welches Protokoll soll dafür genutzt werden z.B. rsync.

Kommen wir zum interessanteren Teil die Installation und Konfiguration von Lsyncd. In den meisten Distributionen ist Lsyncd bereits als fertiges Paket vorzufinden. Für die demonstration verwende ich eine CentOS 7.x Maschine in VirtualBox auf einem Laptop.

Vorbereitung/Installation (CentOS 7.x)

Zunächst installieren wir das lsyncd Paket mittels YUM und generieren bzw. verteilen anschließend unseren SSH-Key den wir später für Lsyncd nutzen.

[root@lsyncdemo ~]# yum install lsyncd
[root@lsyncdemo ~]# ssh-keygen -t ed25519
Generating public/private ed25519 key pair.
Enter file in which to save the key (/root/.ssh/id_ed25519): /root/.ssh/id_lsync
Enter passphrase (empty for no passphrase): 
Enter same passphrase again: 
Your identification has been saved in /root/.ssh/id_lsyync.
Your public key has been saved in /root/.ssh/id_lsyync.pub.
The key fingerprint is:
SHA256:ntsHfyqPkwffQ3IPMUkZ6kIOMdSBqVhREwgag7V1TgI root@lsyncdemo
The key's randomart image is:
+--[ED25519 256]--+
| oE.+.+=B=.. .o |
|. * =o o+. .o |
| o o... . .. . |
| . . + . + |
| S o . o |
| . .o.. + |
| o * = o |
| o+.= + .|
| . o*oo . |
+----[SHA256]-----+
[root@lsyncdemo ~]# ssh-copy-id -i /root/.ssh/id_lsync i2node01

Konfiguration

Nun kommen wir zur Konfiguration unseres Lsyncd, hierfür existiert genau eine Konfigurationsdatei unter /etc/ (equivalenter pfad osx) mit dem Namen lsyncd.conf. Für unser Beispiel synchronisiere ich Verzeichnis mit Konfiguration auf meinen Icinga2 Master (i2node01).

[root@lsyncdemo ~]# vi /etc/lsyncd.conf
<...
- sync{default.rsyncssh, source="/var/www/html", host="localhost", targetdir="/tmp/htmlcopy/"} //Beispiel Konfiguration entfernen

+ sync{ //Icinga Configuration
+  default.rsync, //Wir nutzen rsync zum Synchronisieren
+  source="/home/mdeparade/icinga2/scripts", //Das Quellverzeichnis
+  target="i2node01:/etc/icinga2/scripts", //Das Zielverzeichnis
+  rsync={rsh ="/usr/bin/ssh -l root -i /root/.ssh/id_lsync", owner = true, perms = true,}
+ }
...>

Kurze Erläuterung: Die letzte Zeile unserer Konfiguration gibt rsync noch ein paar Informationen mit: Wir bauen einen SSH-Tunnel als Benutzer root auf, mit dem SSH-Key “id_lsync”, anschließend sagen wir noch das alle Berechtigungen der Dateien/Verzeichnisse erhalten bleiben sollen.

Abschluss

Nachdem wir Lsyncd mit Konfiguration versorgt haben, können wir diesen direkt starten und Überprüfen ob unser Synchronisation auch ordnungsgemaess funktioniert:

[root@lsyncdemo ~]# cat /etc/lsyncd.conf
----
-- User configuration file for lsyncd.
--
-- Simple example for default rsync, but executing moves through on the target.
--
-- For more examples, see /usr/share/doc/lsyncd*/examples/
--
sync{
default.rsync,
source="/home/mdeparade/icinga2/scripts",
target="i2node01:/etc/icinga2/scripts",
rsync={rsh ="/usr/bin/ssh -l root -i /root/.ssh/id_lsync", owner = true, perms = true,} 
}
[root@lsyncdemo ~]# systemctl enable lsyncd --now
[root@lsyncdemo ~]# systemctl status lsyncd
● lsyncd.service - Live Syncing (Mirror) Daemon
 Loaded: loaded (/usr/lib/systemd/system/lsyncd.service; enabled; vendor preset: disabled)
 Active: active (running) since Fri 2018-04-09 10:49:36 BST; 1s ago
 Main PID: 1477 (lsyncd)
 CGroup: /system.slice/lsyncd.service
 └─1477 /usr/bin/lsyncd -nodaemon /etc/lsyncd.conf

Apr 09 10:49:36 lsyncdemo systemd[1]: Started Live Syncing (Mirror) Daemon.
Apr 09 10:49:36 lsyncdemo systemd[1]: Starting Live Syncing (Mirror) Daemon...
[root@lsyncdemo ~]# ll /home/mdeparade/icinga2/scripts
total 4
-rw-r--r--. 1 root root 5 Apr 09 10:52 test.conf
[root@lsyncdemo ~]# ssh -i /root/.ssh/id_lsync -l root 192.168.56.11 ls /etc/icinga2/scripts
test.conf
[root@lsyncdemo ~]# exit
logout
Connection to blog.netways.de closed.

Eindrücke aus Bayern: Die Alpen

Max Deparade

Autor: Max Deparade

Max ist seit Januar als Consultant bei NETWAYS und unterstützt tatkräftig unser Professional Services Team. Zuvor hat er seine Ausbildung zum Fachinformatiker für Systemintegration bei der Stadtverwaltung in Regensburg erfolgreich absolviert. Danach hat der gebürtige Schwabe, der einen Teil seiner Zeit auch in der Oberpfalz aufgewachsen ist ein halbes Jahr bei einem Managed Hosting Provider in Regensburg gearbeitet, ehe es ihn zu NETWAYS verschlagen hat. In seiner Freizeit genießt Max vor allem die Ruhe, wenn er nicht gerade fieberhaft auf sein neues Macbook wartet.

Benutzername und Kennwort war gestern: SSH-Key

Heute möchten wir euch zeigen wie man die Authentifizierung gegen ein OpenSSH-Server mittels SSH-Key realisiert.

Unser Schlüsselpärchen erzeugen wir mit dem Befehl ssh-keygen und übergeben die Option -t rsa und -b 4096.  Die Option -t definiert welcher Algorithmus und -b welche Schlüssellänge genutzt werden soll:

root@icinga2-node1a:~# ssh-keygen -t rsa -b 4096
Generating public/private rsa key pair.
Enter file in which to save the key (/root/.ssh/id_rsa):
Enter passphrase (empty for no passphrase):
Enter same passphrase again:
Your identification has been saved in /root/.ssh/id_rsa.
Your public key has been saved in /root/.ssh/id_rsa.pub.
The key fingerprint is:
-cutted output- root@icinga2-node1a
The key's randomart image is:
+---[RSA 4096]----+
| .... .=. . |
| o o.+oo.+. . |
| . + o+oE. . |
| . o.o + |
| S. + . |
| . .. |
| . |
| |
| |
+-----------------+
root@icinga2-node1a:~#

Wir sehen in der Ausgabe den Punkt “Enter passphrase”, dort sollte man unbedingt ein Kennwort vergeben. Da es sonst dem Szenario gleich kommen würde, dass wir unsere EC-Karte ohne PIN betreiben!

Alternativ kann man die Schlüssel auch mit einer Elliptische-Kurven-Kryptografie erzeugen. Hierzu bietet sich die Elliptische-Kurve ed25519 an, die ab OpenSSH 6.5 unterstützt wird:

root@icinga2-node1a:~# ssh-keygen -t ed25519
Generating public/private ed25519 key pair.
Enter file in which to save the key (/root/.ssh/id_ed25519):
Enter passphrase (empty for no passphrase):
Enter same passphrase again:
Your identification has been saved in /root/.ssh/id_ed25519.
Your public key has been saved in /root/.ssh/id_ed25519.pub.
The key fingerprint is:
-cutted output- root@icinga2-node1a
The key's randomart image is:
+--[ED25519 256]--+
| . |
| o |
| . E |
| o + o |
| = S o . |
| + + + . |
| +.* o |
| ..+* |
|.o.o oo |
+-----------------+
root@icinga2-node1a:~#

 

Sofern man den Pfad während der Generierung nicht verändert hat findet man die Zertifikate unter:

root@icinga2-node1a:~# ls -la ~/.ssh/
total 28
drwx------ 2 root root 4096 Jan 26 12:26 .
drwx------ 5 root root 4096 Jan 25 17:04 ..
-rw------- 1 root root 464 Jan 26 12:09 id_ed25519
-rw-r--r-- 1 root root 101 Jan 26 12:09 id_ed25519.pub
-rw------- 1 root root 3326 Jan 26 12:26 id_rsa
-rw-r--r-- 1 root root 745 Jan 26 12:26 id_rsa.pub
-rw-r--r-- 1 root root 666 Jan 25 10:29 known_hosts
root@icinga2-node1a:~#

 

Für die Verteilung unseres Öffentlichen Schlüssels wird bereits einen Befehl mitgeliefert:

root@icinga2-node1a:~# ssh-copy-id netways@icinga2-node1b
The authenticity of host 'icinga2-node1b (192.168.56.12)' can't be established.
ECDSA key fingerprint is -cutted output-
Are you sure you want to continue connecting (yes/no)? yes
/usr/bin/ssh-copy-id: INFO: attempting to log in with the new key(s), to filter out any that are already installed
/usr/bin/ssh-copy-id: INFO: 1 key(s) remain to be installed -- if you are prompted now it is to install the new keys
netways@icinga2-node1b's password:

Number of key(s) added: 1

Now try logging into the machine, with: "ssh 'netways@icinga2-node1b'"
and check to make sure that only the key(s) you wanted were added.

root@icinga2-node1a:~#

 

Direkt im Anschluss kann man testen ob der Verbindungsaufbau mittels SSH-Key funktioniert:

root@icinga2-node1a:~# ssh netways@icinga2-node1b
Enter passphrase for key '/root/.ssh/id_rsa':

The programs included with the Debian GNU/Linux system are free software;
the exact distribution terms for each program are described in the
individual files in /usr/share/doc/*/copyright.

Debian GNU/Linux comes with ABSOLUTELY NO WARRANTY, to the extent
permitted by applicable law.
You have new mail.
Last login: Wed Jan 24 18:22:11 2018 from 192.168.56.1
netways@icinga2-node1b:~$

 

Im letzten Schritt müssen wir unserem OpenSSH-Server die Anmeldung per Benutzername und Kennwort abgewöhnen. Hierzu editieren wir folgenden Optionen in unserer OpenSSH-Server Konfiguration:

icinga2-node3b:~# vi /etc/ssh/sshd_config

--- #PasswordAuthentication yes
+++ PasswordAuthentication no

--- #AuthorizedKeysFile %h/.ssh/authorized_keys
+++ AuthorizedKeysFile %h/.ssh/authorized_keys

--- PermitRootLogin no
+++ PermitRootLogin without-password

icinga2-node3b:~# service sshd restart

Sobald der Neustart des OpenSSH-Servers abgeschlossen ist, wird nur noch die Anmeldung per SSH-Key akzeptiert. Wenn man sich jetzt regulär verbindet, wird zwar zunächst eine Verbindung aufgebaut, jedoch bei der Übergabe des Benutzernamens die Verbindung mit der Meldung “publickey” beendet.

Max Deparade

Autor: Max Deparade

Max ist seit Januar als Consultant bei NETWAYS und unterstützt tatkräftig unser Professional Services Team. Zuvor hat er seine Ausbildung zum Fachinformatiker für Systemintegration bei der Stadtverwaltung in Regensburg erfolgreich absolviert. Danach hat der gebürtige Schwabe, der einen Teil seiner Zeit auch in der Oberpfalz aufgewachsen ist ein halbes Jahr bei einem Managed Hosting Provider in Regensburg gearbeitet, ehe es ihn zu NETWAYS verschlagen hat. In seiner Freizeit genießt Max vor allem die Ruhe, wenn er nicht gerade fieberhaft auf sein neues Macbook wartet.