Icinga2 check by ssh

Icinga führt die checks über ssh aus und dies verlangt im Normalfall das Passwort vom Benutzer, mit dem wir uns anmelden wollen. Dies umgehen wir, indem wir ein privaten Schlüssel erzeugen und den öffentlichen Schlüssel mit dem Client teilen. Der User, mit dem die Icinga Instanz läuft, muss auch auf dem Remote Host angelegt werden. Ermitteln wir die laufenden Icinga Prozesse, sehen wir, dass unsere Instanz mit dem nagios Benutzer läuft. Legen wir diesen Benutzer nun auf dem Client an. Um weiter fortfahren zu können, müssen wir uns als nagios auf dem Server anmelden. Der Shell Zugriff ist aber meist für […]

rsync over ssh

Ich bin gerade dabei mich intensiv mit Deep Learning zu beschäftigen. Als Werkzeug dient mir dazu Anaconda und Jupyter Notebook. Dabei hatte ich die Idee, Jupyter Notebook auch dann noch zu benutzen, wenn ich gerade nicht zuhause bin. Wollte aber trotz alledem überall mit den gleichen Daten arbeiten. Von Zuhause würde ich auf das NAS zugreifen, welches nicht von Außen erreichbar ist und auch nicht soll. Wenn ich unterwegs bin, muss ich also zwangsweise einen anderen Weg einschlagen.  Hier kommt mein vServer zum Einsatz, den ich als Cloud hinter einem VPN benutze. Dort läuft ebenfalls Anaconda mit Jupyter Notebook(Ich könnte […]

SSH Verbindung mit privaten/öffentlichen Schlüssel

Üblicherweise kennt man einen SSH Login mit Passwort. Was ist aber, wenn es erforderlich ist, eine Verbindung ohne Password herzustellen? Hier kommt die Schlüssel-Authentifizierung ins Spiel. Bei dieser Art der Authentifizierung wird mit Schlüsseln gearbeitet. Genauer gesagt dem öffentlich- und dem privaten Schlüssel.  Wollen wir z.B., dass Server1 sich ohne Passwort Abfrage auf dem Server2 anmelden kann, so erstellen wir auf Server1 einen privaten, samt öffentlichen Schlüssel. Server2 müssen wir den öffentlichen Schlüssel mitteilen. Schauen wir uns das untere Bild mal genauer an. Server1 möchte eine SSH Verbindung nach Server2 aufbauen. Server2 schickt eine Random Antwort, die Server1 mit einer […]

SSH Email bei Client Verbindung

Mein vServer hat zurzeit den SSH Port offen. Dieser befindet sich zwar nicht mehr standardmäßig auf dem Port 22, um sogenannte Bots größtenteils vom Server zu halten, allerdings wollte ich bei jedem Connect informiert werden, damit ich im Falle einer Kompromittierung direkt reagieren kann. Der Port kann in der /etc/ssh/sshd_config angepasst werden. Die eigentliche Mail Benachrichtigung, in der es in diesem Beitrag auch geht, muss in pam.d eingerichtet werden. Eine, wie ich finde gute Seite, die pam.d beschreibt, ist https://web.archive.org/web/20180303034326/http://www.tuxradar.com/content/how-pam-works Kommen wir weiter zu den Änderungen der Datei. Öffnen wir die ssh Datei mit einem beliebigen Editor, in meinem Fall […]