Posts by wirsansoizburg

    Alternative könnte ich ein bash script starten?

    @aRaphael - danke für deine Unterstützung.

    Hab es jetzt so wie oben beschrieben gelöst. Hab mir ein Script gemacht, mit welchem ich mail Command calle. Das Script wird mit exec so wie in deine Anleitung aufgerufen und das funktioniert. Erhalte auch die Mail aufgrund des Logins korrekt mit der Regular Expression. :)

    Genau - meinte ich mit Shell. Connecte mich einfach nochmal per Putty rauf und es wird getriggered. Ja, liegt an der Mail. Versand klappt aber, d.h. ich muss am Command was machen. Alternative könnte ich ein bash script starten?

    basics beibringen

    Definier das mal bitte. Ich bin über eure Hilfe dankbar. Aber ich würde auch nicht fragen - wenn ich es nicht selber schon länger vorher auf diverse Arten probiert und mich ein wenig eingelesen hätte. :-)

    Bzgl. Sicherheit hab ich schon einiges eingerichtet und mich an

    https://www.thomas-krenn.com/d…hern-cheat-sheet-v1.0.pdf

    gehalten.


    exec mail -s "test" mail@domain.tld

    oder mail -s "test" mail@domain.tld


    Beide senden erst, wenn ich "< /dev/null" anfüge. Ansonsten muss ich mit "." bestätigen und noch "cc" angeben.

    Aber mit "< /dev/null" funktioniert es.


    @neue Zeilen: ja, sobald ich die Config angepasst und den Service neu gestartet habe, checke ich den Status. Wenn alles okay ist, starte ich eine zweite Shell und prüfe meine Mail. Damit sollten neue Zeilen im Log generiert werden und die Suche den Key finden. Geprüft hab ich die Logs parallel dazu.


    Ja schon komisch, aber ich werde noch ein paar weitere Versuche starten.


    Hab jetzt noch folgendes getestet, damit ich mein Mail Problem verifizieren kann:

    exec touch /tmp/foo.bar


    Folder war leer. Zweite Mal per Shell verbunden und siehe da, die Datei wurde angelegt.


    D.h. Service läuft, gefunden wird der Suchcode, aber Mail ist das Problem. "< /dev/null" <-- kann ich das vielleicht auch anders lösen?

    Dann müsste es /sshd*Accepted*/heißen. Alternativ kannst du es auch nur nach /Accepted/ suchen lassen

    Hatte ich beides zwischenzeitlich getestet. Dann muss es am "mail" liegen. Sehe ich da irgendwo ein log zum swatchdog?

    Die Varianten von @aRaphael habe ich soweit durch, wirklich starten lässt sich das Service nur mit deinem Vorschlag. Müsste der in der Shell auch funktionieren?

    mail=meinemail@gmail.com,subject=SSHlogin

    Thx für die Rückmeldungen.


    Das mit "address" hatte ich soweit erkannt - zumindest kam kein Fehler mehr in der Config und Service startet.


    2 Fragen:

    1. Sollte "mail=meinemail@gmail.com,subject=SSHlogin" auch normal in der Shell funktionieren? Das tut es leider nicht, sondern nur mit dieser Schreibweise:

    echo "Inhalt der E-Mail" | mail -s "Betreff" meinemail@gmail.com


    2. An das Suchmuster (@Bensen) hatte ich bereits gedacht, aber ich bin mit den regular expressions noch nicht so vertraut bei dieser Konfiguration.

    Folgendes finde ich im Log-File: sshd[9562]: Accepted password würde das mit /sshd.*Accepted.*/ matchen?


    * ist egal welches Zeichen und wie oft, oder?

    Sollte ich dann nicht nach /sshd*Accepted*/ suchen?

    Bin einen Schritt weiter:

    Code
    1. watchfor /sshd.*Accepted.*/
    2. mail=meinemail@gmail.com,subject=SSH login

    Wenn ich es so schreibe, bekommen ich keinen Fehler mehr und Status sieht so aus:


    Code
    1. ● swatch-login.service - swatchdog - monitor ssh passwort logins
    2. Loaded: loaded (/etc/systemd/system/swatch-login.service; enabled; vendor preset: enabled)
    3. Active: active (running) since Fri 2020-10-16 20:59:03 CEST; 3s ago
    4. Main PID: 9367 (swatchdog)
    5. Tasks: 3 (limit: 4915)
    6. Memory: 25.9M
    7. CGroup: /system.slice/swatch-login.service
    8. ├─9367 /usr/bin/perl /usr/bin/swatchdog -c /root/auth_watch_config -t /var/log/auth.log
    9. ├─9368 /usr/bin/perl /.swatchdog_script.9367
    10. └─9370 /usr/bin/tail -n 0 -F /var/log/auth.log


    Mail erhalte ich dennoch keine. :(

    Das Kannst du aber so nicht in die config-Datei von swatchdog einfügen.

    Das muss schon den entsprechenden Syntax haben, damit swatchdog damit was anfangen kann. Das ist ja kein Shellbefehl, der da drin steht.

    Was sagt

    sudo service swatch-login status

    ?

    Hab das Service jetzt zum Laufen bekommen. Aber nur mit meinem Mailscript und das funktioniert, wie Du schon schreibst, so nicht.


    Nutze ich: mail address=meinemail@gmail.com,subject="SSH login on Schubidu"


    Erhalte ich folgendes mit sudo service swatch-login status:

    Code
    1. systemd[1]: Started swatchdog - monitor ssh passwort logins.
    2. swatchdog[8986]: Global symbol "@gmail" requires explicit package name (did you forget to declare "my @gmail"?) at /.s
    3. swatchdog[8986]: Execution of /.swatchdog_script.8986 aborted due to compilation errors.
    4. systemd[1]: swatch-login.service: Succeeded.

    Hab jetzt versucht, deine Anleitung nachzubauen.

    Aber irgendwie bekomme ich keine Mail.

    Das Mail Statement sieht bei mir etwas anders aus: echo "Hier steht Text" | mail -s "SSH Login" mailadresse@gmail.com

    Führe ich das normal in der Shell aus, erhalte ich die Mail.


    In /etc/systemd/system/ findet sich swatch-login.service mit folgenden Rechten:

    -rw-r--r-- 1 root root 183 Oct 16 10:48 swatch-login.service


    Folgendes hab ich ausgeführt

    Code
    1. sudo systemctl daemon-reload
    2. sudo systemctl enable swatch-login
    3. sudo systemctl start swatch-login

    pgrep findet mir aber swatch-login nicht.


    Kann es sein, dass der Service nicht läuft? Wo ist mein Fehler? Danke für deine Hilfe!

    Danke für euren Input.

    Hatte mich da an diese Anleitung (https://www.thomas-krenn.com/d…rung_eines_Debian_Servers) etwas gehalten.

    Freue mich aber über Tipps, wie es besser geht :-).

    Hab jetzt zwar 2h benötigt, um msmtp zum Laufen zu bekommen, aber das werden wahrscheinlich klassische Anfängerfehler gewesen sein, und, dass ich bei Google zuerst ein App Password generieren musste. :pinch:


    Jetzt sehe ich mir mal Swatchdog von aRaphael an :)

    Danke euch nochmals!

    EInen Mailserver hast du aber schon komplett installiert und konfiguriert?

    Danke für deine Antwort.

    Bin mir nicht sicher, ob ich einen einrichten möchte. Das bietet wieder einer Angriffsfläch, oder? Ich würde lieber den SMTP von Google einrichten. Aber das scheint nicht geklappt zu haben.


    Jetzt versuche ich es mit dieser Anleitung:

    https://kb.novaordis.com/index…_via_a_Google_SMTP_Server


    Aber bei den Zertifikaten hänge ich noch ein wenig.

    Danke für die Anleitung.

    Ich hab nur ein Problem mit dem Mailversand auf meinem Root Server.


    echo "Hello World" | mailx -s "Testmail" meinemail@gmail.com


    ...liefert mir per "cat /var/mail/username" folgendes:


    Code
    1. A message that you sent could not be delivered to one or more of its
    2. recipients. This is a permanent error. The following address(es) failed:
    3. meinemail@gmail.com
    4. Mailing to remote domains not supported


    Unter rDNS in der netcup ccp Konsole ist folgendes eingetragen:

    Code
    1. v2202xxxxxxxxxxxxxxxx.ultrasrv.de


    /etc/hostname beinhaltet folgendes:

    Code
    1. v2202xxxxxxxxxxxxxxxx


    Code
    1. /etc/hosts beinhaltet folgendes:
    2. 127.0.0.1       localhost
    3. 127.0.1.1       v2202xxxxxxxxxxxxxxxx.ultrasrv.de v2202xxxxxxxxxxxxxxxx
    4. # The following lines are desirable for IPv6 capable hosts
    5. ::1     localhost ip6-localhost ip6-loopback
    6. ff02::1 ip6-allnodes
    7. ff02::2 ip6-allrouters
    8. xxx.xxx.xxx.xxx  v2202xxxxxxxxxxxxxxxx.ultrasrv.de v2202xxxxxxxxxxxxxxxx


    Reporting-MTA: dns; v2202xxxxxxxxxxxxxxxx.ultrasrv.de


    Was habe ich falsch eingestellt? Kann mir hier jemand weiterhelfen? Danke!

    Das hast du hoffentlich sofort danach wieder geändert :P


    Ein paar Tipps zur Absicherung deines neuen Systems:

    1. Sudo-User erstellen und PermitRootLogin in der /etc/ssh/sshd_config auf "no" oder "prohibit-password" stellen
    2. SSH-Key generieren, öffentlichen Key in der ~/.ssh/authorized_keys des Sudo-Users ablegen und PasswordAuthentication in der /etc/ssh/sshd_config auf "no" ändern, oder alternativ ein seeeehr sicheres Passwort für den Sudo-User vergeben
    3. Firewall konfigurieren (z.B. mittels ufw): nur die Ports freigeben, die benötigt werden
    4. Regelmäßig Updates installieren

    Willkommen bei NetCup :)

    Danke :)

    Hat mir auf alle Fälle weitergeholfen! Wollte ich einfach als Rückmeldung hier lassen ;).