Freut mich, dass es letztlich doch noch geklappt hat.
Das mit dem Skript ist ja sogar noch flexibler. Da kannst du ja noch weitere Dinge reinpacken.
Danke, ja.
Ich war so fokussiert auf deine Lösung, dass ich nicht an einen Workaround gedacht hatte. Dabei war der so simpel ;-).
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. 
Hast du schon mal versucht das @ in der Mailadresse durch \@ zu ersetzen?
klar hatte deine varianten alle durch.
Alles anzeigenDa wird keine eMail kommen.
Einfach eine zweite Shell aufzumachen triggert in der Regel nichts, weil das kein weiterer echter ssh-Login ist. Da sollte es eigentlich auch keinen entsprechenden Eintrag in der auth.log geben. Das springt nur an, wenn du dich z.B. mit deinem client erneut verbindest, also mit Passwort oder key über ssh anmeldest
EDIT:
Offenbar macht du das ja aber.
Dann liegt es doch nur am Mailversand
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.
Alles anzeigenDu kannst ja auch mal versuchen mail direkt aufzurufen:
watchfor /sshd.*Accepted.*/
exec mail -s "test" mail@domain.tld
(oder mit Pfad /usr/bin/mail)
Oder mal was anderes mit ecex ausprobieren, statt zu versuchen emails zu senden, um das Problem einzugrenzen. (Evtl. auch mal nach was anderem suchen)
Schade, dass es bei dir solche Probleme gibt.
Bei mir hatte das auf Anhieb geklappt...
btw:
Dir ist klar, dass der service nur die neuen Zeilen im log scannt, die nach dem Starten von swatchdog neu hinzukommen?
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?
/Accepted password/ <-- probiert. Auch nix. Ich glaub ich lass es für heute... 
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
Ahja, das findet sich in meiner /etc/mail.rc:
set mta=/usr/bin/msmtp
set sendmail=/usr/bin/msmtp
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:
watchfor /sshd.*Accepted.*/
mail=meinemail@gmail.com,subject=SSH loginWenn ich es so schreibe, bekommen ich keinen Fehler mehr und Status sieht so aus:
● swatch-login.service - swatchdog - monitor ssh passwort logins
Loaded: loaded (/etc/systemd/system/swatch-login.service; enabled; vendor preset: enabled)
Active: active (running) since Fri 2020-10-16 20:59:03 CEST; 3s ago
Main PID: 9367 (swatchdog)
Tasks: 3 (limit: 4915)
Memory: 25.9M
CGroup: /system.slice/swatch-login.service
├─9367 /usr/bin/perl /usr/bin/swatchdog -c /root/auth_watch_config -t /var/log/auth.log
├─9368 /usr/bin/perl /.swatchdog_script.9367
└─9370 /usr/bin/tail -n 0 -F /var/log/auth.logMail 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:
systemd[1]: Started swatchdog - monitor ssh passwort logins.
swatchdog[8986]: Global symbol "@gmail" requires explicit package name (did you forget to declare "my @gmail"?) at /.s
swatchdog[8986]: Execution of /.swatchdog_script.8986 aborted due to compilation errors.
systemd[1]: swatch-login.service: Succeeded.Alles anzeigenHier mal, wie ich das mit swatchdog unter Ubuntu 20.04 gelöst habe:
Swatchdog installieren:
$ sudo apt install swatch
config-file fürs ssh-Login in /root erstellen :
/root/auth_watch_config :
Codewatchfor /sshd.*Accepted.*/ mail address=meinemail@meinedomain,subject="SSH login on Schubidu"
Service erstellen, damit das auch nach reboot weiterläuft:
/etc/systemd/system/swatch-login.service :
Code[Unit] Description=swatchdog - monitor ssh passwort logins [Service] ExecStart=/usr/bin/swatchdog -c /root/auth_watch_config -t /var/log/auth.log [Install] WantedBy=multi-user.target
Service starten:
Code$ sudo systemctl daemon-reload $ sudo systemctl enable swatch-login $ sudo systemctl start swatch-login
Man kann swatchdog dann natürlich auch noch andere Dinge überwachen lassen.
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
sudo systemctl daemon-reload
sudo systemctl enable swatch-login
sudo systemctl start swatch-loginpgrep 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. 
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:
A message that you sent could not be delivered to one or more of its
recipients. This is a permanent error. The following address(es) failed:
meinemail@gmail.com
Mailing to remote domains not supportedUnter rDNS in der netcup ccp Konsole ist folgendes eingetragen:
v2202xxxxxxxxxxxxxxxx.ultrasrv.de/etc/hostname beinhaltet folgendes:
v2202xxxxxxxxxxxxxxxx/etc/hosts beinhaltet folgendes:
127.0.0.1 localhost
127.0.1.1 v2202xxxxxxxxxxxxxxxx.ultrasrv.de v2202xxxxxxxxxxxxxxxx
# The following lines are desirable for IPv6 capable hosts
::1 localhost ip6-localhost ip6-loopback
ff02::1 ip6-allnodes
ff02::2 ip6-allrouters
xxx.xxx.xxx.xxx v2202xxxxxxxxxxxxxxxx.ultrasrv.de v2202xxxxxxxxxxxxxxxxReporting-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
Ein paar Tipps zur Absicherung deines neuen Systems:
- Sudo-User erstellen und PermitRootLogin in der /etc/ssh/sshd_config auf "no" oder "prohibit-password" stellen
- 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
- Firewall konfigurieren (z.B. mittels ufw): nur die Ports freigeben, die benötigt werden
- Regelmäßig Updates installieren
Willkommen bei NetCup
Danke
Hat mir auf alle Fälle weitergeholfen! Wollte ich einfach als Rückmeldung hier lassen ;).
