Hallo Ich würde gerne ein "logging" script starten wenn sich ein User auf der Ssh console anmeldet. Also eigentlich sogar nur ein "echo username >> logdatei" Habt ihr ideen wie man das einrichten könnte? Rootrechte habe ich.
/var/log/auth.log Ggf. musst du halt im Syslog noch einen zusätzlichen Eintrag vorsehen, der dir nur die von dir gewünschten Ereignisse da heraus filtert.
Könnte man hiermit versuchen: grep "Accepted password" /var/log/auth*
Ich nutze für sowas pam_exec[1]. Fehlgeschlagene Loginversuche hab ich hier als live stream: https://preview.danielabrecht.ch/loginfails/ Erfolgreiche Logins send ich mir per E-Mail. 1) https://linux.die.net/man/8/pam_exec
Philipp K. schrieb: > Könnte man hiermit versuchen: > grep "Accepted password" /var/log/auth* Und was, wenn sich die Leute gar nicht mit Passwort einloggen? ;-) Mache ich bspw. so gut wie nie.
Jörg W. schrieb: > Mache ich bspw. so gut wie nie. Hab ich nicht dran gedacht, lässt sich bestimmt auch mit Grep lösen :D Lösung steht ja oben^^.
DPA schrieb: > Ich nutze für sowas pam_exec[1]. Fehlgeschlagene Loginversuche hab > ich > hier als live stream: > https://preview.danielabrecht.ch/loginfails/ > Erfolgreiche Logins send ich mir per E-Mail. > > 1) https://linux.die.net/man/8/pam_exec Kannst du das näher erläutern wie genau du das machst? Vielen Dank!
/var/log/auth.log war schonmal der richtige tipp. Dort sehe ich jetzt wundervolle Daten. Problem nur zwei. Ich würde jetzt gerne per Script jeweils den neusten Eintrag mitbekommen und zb per Mqtt versenden. Wie also bekomme ich mit wenn in die Datei eingetragen wurde? Eine art Tail-f in anwendung
Also wenn du ein Script beim Login ausführen willst gibt es zig Möglichkeiten - hängt auch von der Distribution ab. z.Bsp. - falls es nur ein Nutzer ist - bearbeite die Datei ~/.profile und füge deine Befehle hinzu. Global kannst du es in die /etc/profile werfen. Wird dann natürlich bei JEDEM Login, nicht nur SSH ausgeführt...
Also ich würde sowas über den syslogd lösen. Dazu ist er ja da... Schreib Dir eine Regel, die auf das Logevent vom SSHD passt. Der Syslogd kann dann bspw. ein Skript triggern oder das Logevent direkt an ein mailcommando pipen... für rsyslog zum Beispiel: https://www.rsyslog.com/doc/v8-stable/configuration/modules/omprog.html
Jörg W. schrieb: > Philipp K. schrieb: >> Könnte man hiermit versuchen: >> grep "Accepted password" /var/log/auth* > > Und was, wenn sich die Leute gar nicht mit Passwort einloggen? ;-) > > Mache ich bspw. so gut wie nie. Login Informationen landen gewöhnlich in /var/log/wtmp bzw. utmp. Ausgaben von last o. lastb auswerten.
linseunspätzle schrieb: > Login Informationen landen gewöhnlich in /var/log/wtmp bzw. utmp. > Ausgaben von last o. lastb auswerten. Das Kommando "last" wäre auch mein Kandidat. Das einzig Dumme: die wtmp wird zum Monatsanfang geleert. Man kann dann noch mit
1 | last -f /var/log/wtmp.1 |
die Daten des Vormonats hervorkratzen. Wenn man mehr möchte, muss man sich wohl mit logrotate beschäftigen. /etc/logrotate.conf hilft hier weiter.
raspi schrieb: > Kannst du das näher erläutern wie genau du das machst? Ich bin grad nicht zuhause, darum kann ich gerade nicht nachsehen. Das Senden der Mails mach ich mit einem Eintrag ganz am Ende der Datei /etc/pam.d/common-session:
1 | session optional pam_exec.so seteuid /pfad/zu/script |
Das script wird dann bei session_open (anmelden), session_close (abmelden) etc. aufgerufen. Dort kann man dann was in die Richtung schreiben (ungetestet):
1 | if [ "$PAM_TYPE" != session_open ] || [ "$PAM_SERVICE" != sshd ] |
2 | then exit 0 |
3 | fi |
4 | |
5 | sendmail ... |
Die fehlgeschlagenen Loginversuche zu loggen ist etwas trickier. Hier darf man keine fehler machen. Das mache ich in der /etc/pam.d/common-auth. Dort gibt es die Zeilen:
1 | auth [success=1 default=ignore] pam_unix.so nullok_secure |
2 | auth requisite pam_deny.so |
3 | auth required pam_permit.so |
Die anpassen nach:
1 | auth [success=2 default=ignore] pam_unix.so nullok_secure |
2 | auth optional pam_exec.so expose_authtok /pfad/zu/script argumente |
3 | auth requisite pam_deny.so |
4 | auth required pam_permit.so |
Aber aufpassen, bei success=N gibt N an, wie viele Einträge bei einem erfolgreichen login übersprungen werden. Das muss auf pam_permit.so springen, sonst sperrst du dich eventuell aus. Und auf keinen fall die pam_deny.so entfernen, sonst ist jeder login versuch erfolgreich!!! Meine logging Anwendung und ein SSH patch kann man hier finden: https://github.com/Daniel-Abrecht/honeypot Der SSH patch braucht man, damit das Skript das eingegebene Passwort bekommt. Normalerweise ersetzt SSH bei ungültigen oder deaktivierten Usern vor dem Login das Passwort mit einem placeholdertext, damit der Login auch garantiert fehlschlägt, aber das Timeing gleich bleibt. Mein patch fügt statdessen einfach ein 0x01 byte vor dem Passwort ein. Die Webseite hab ich aber noch nicht hochgeladen. Eigentlich ist alles nur HTML und JS und kann man einfach so von meinem Server downloaden. Es gibt aber noch ein posix/cgi shell script, das die Daten der Seite übergibt mittels server-sent events. Im grunde ist es nur ein "echo headers" und ein 'tail -f -n 100 logfile | while IFS= read -r line; do echo "data: $line"; echo; done' oder so ähnlich.
Zesar (Gast) schrieb: >/var/log/auth.log war schonmal der richtige tipp. Dort sehe ich jetzt >wundervolle Daten. >Problem nur zwei. Ich würde jetzt gerne per Script jeweils den neusten >Eintrag mitbekommen und zb per Mqtt versenden. tail -f -n 0 /var/log/auth.log | while read line do if [[ $line = suchstring ]] #optionale Bedingung then <mqtt cmd $line> fi #optional Bedingung done Die if-BEdingung ist nur nötig, falls man die Ausführung abhängig vom Inhalt der neuen Zeile machen will. <mqtt cmd $line> ist enfach nur ein Platzhalter für deinen Code, den Du bei Erkennen einer neuen Zeile ausführen willst. Muß wohl als Root bzw. mittels su/sudo ausgeführt werden, da /var/log/auth.log wohl nur von root lesbar.
Jens G. schrieb: > tail -f -n 0 /var/log/auth.log | while read line Das zerfällt beim nächsten Logrotate. Lieber gleich an den Syslog dranhängen.
DPA (Gast) schrieb: >> Kannst du das näher erläutern wie genau du das machst? >Ich bin grad nicht zuhause, darum kann ich gerade nicht nachsehen. >Das Senden der Mails mach ich mit einem Eintrag ganz am Ende der Datei >/etc/pam.d/common-session: Dazu muß aber PAM für die Authentication aktiviert/eingerichtet sein. Ist das inzwischen default bei Linux?
Jörg W. (dl8dtl) (Moderator) schrieb:
>... Logrotate.
Auch das noch. Naja, muß man eben den rc von tail auswerten, und neu
starten lassen :-)
Frank M. schrieb: > die Daten des Vormonats hervorkratzen. Wenn man mehr möchte, muss man > sich wohl mit logrotate beschäftigen. /etc/logrotate.conf hilft hier > weiter. Wenn nur der letzte Vorgang ohne Historie interessiert der auch länger (u.U. Jahre) zurückliegen darf, lastlog. Früher pre pam, evtl. auch heute noch hat man das in /etc/login.defs festlegen können FAILLOG_ENAB, LOG_OK_LOGINS, LASTLOG_ENAB, ... ---
Jens G. schrieb: > Muß wohl als Root bzw. mittels su/sudo ausgeführt werden, da > /var/log/auth.log wohl nur von root lesbar. Sudo-Brechstange wirklich nötig? Mmn besser: die Gruppenzugehörigkeit des (nur-) lesenden users anpassen. Zesar schrieb: > Ich würde gerne ein "logging" script starten wenn sich ein User auf der > Ssh console anmeldet Ich weiss nicht was du am Ende erreichen möchtest, aber: Nur ein fauler Admin ist ein guter Admin... richte mal ein Auge auf: https://de.wikipedia.org/wiki/Fail2ban
Zesar schrieb: > Hallo > Ich würde gerne ein "logging" script starten wenn sich ein User auf der > Ssh console anmeldet. Also eigentlich sogar nur ein "echo username >> > logdatei" > Habt ihr ideen wie man das einrichten könnte? > Rootrechte habe ich. Die Leute hier im Forum rauchen manchmal gar Absonderliches. Nimm ihnen daher ihre kruden Vorschläge nicht übel. Profis schreiben ein Skript in die /etc/ssh/sshrc. Nachzulesen unter man sshd.
Diese Woche gelten die Tipps von letzte Woche nicht mehr. Mit jedem Update wird wieder ein kleines bisschen auf systemd journalctl umgestellt. 2 Tage nachdem dein Script läuft, wird /var/log/auth.log nicht mehr existieren. Solltest besser auch absonderliches Zeug rauchen und abwarten, bis die Umstellung endlich abgeschlossen ist.
Lästermaul schrieb: > Mit jedem Update wird wieder ein kleines bisschen auf systemd journalctl > umgestellt. 2 Tage nachdem dein Script läuft, wird /var/log/auth.log > nicht mehr existieren. > > Solltest besser auch absonderliches Zeug rauchen und abwarten, bis die > Umstellung endlich abgeschlossen ist. Absonderliches Zeug rauchen und abwarten ok, mir kommt systemd weder ins Haus, noch auf die Server(m/w/d).
Lästermaul schrieb: > Diese Woche gelten die Tipps von letzte Woche nicht mehr. > > Mit jedem Update wird wieder ein kleines bisschen auf systemd journalctl Die für das Logging zuständige Service Unit von systemd heisst journald...
Bitte melde dich an um einen Beitrag zu schreiben. Anmeldung ist kostenlos und dauert nur eine Minute.
Bestehender Account
Schon ein Account bei Google/GoogleMail? Keine Anmeldung erforderlich!
Mit Google-Account einloggen
Mit Google-Account einloggen
Noch kein Account? Hier anmelden.