Linux: welches Skript beim Login?

[TS]

Hello,

leider schwimme ich gerade mal wieder. Da war doch mal 'was?

Welches (Bash)-Skript wird bei Linux (hier Debian) bei jedem Login aufgerufen?

für den einzelen User wäre es .bashrc, oder? Ich brauche aber eine übergeordnete Ebene, die auch nur von Root geändert werden kann und sofort für alle Accounts gilt.

Liebe Grüße
Tom S.

[dedlfix]

Tach!

Welches (Bash)-Skript wird bei Linux (hier Debian) bei jedem Login aufgerufen?

für den einzelen User wäre es .bashrc, oder? Ich brauche aber eine übergeordnete Ebene, die auch nur von Root geändert werden kann und sofort für alle Accounts gilt.

Selber Dateiname, aber ohne . und in /etc. Und /etc/profile gibt es auch noch.

dedlfix.

[TS]

Hello,

Welches (Bash)-Skript wird bei Linux (hier Debian) bei jedem Login aufgerufen?

für den einzelen User wäre es .bashrc, oder? Ich brauche aber eine übergeordnete Ebene, die auch nur von Root geändert werden kann und sofort für alle Accounts gilt.

Selber Dateiname, aber ohne . und in /etc. Und /etc/profile gibt es auch noch.

soweit ich das bisher identifizieren konnte, habe ich mir jetzt ein Skript in /etc/profile.d/login-mail.sh angelegt.

Das funktioniert soweit für alle Accounts.

Fragt sich jetzt "nur" noch, ob sich dessen Ausführung beim Login (übers Netz) noch irgendwie unterdrücken lässt, oder ob es zuverlässig zuerst ausgeführt wird, bevor die Shell für den Benutzer zur Verfügung gestellt wird?

Liebe Grüße
Tom S.

[Christian Kruse]

Hallo TS,

Fragt sich jetzt "nur" noch, ob sich dessen Ausführung beim Login (übers Netz) noch irgendwie unterdrücken lässt, oder ob es zuverlässig zuerst ausgeführt wird, bevor die Shell für den Benutzer zur Verfügung gestellt wird?

Wenn du schnell genug SIGINT sendest (z.B. über Ctrl-C), dann kann die Ausführung der Initialisierungs-Skripte unterbrochen werden. Du musst die Signale noch abfangen.

Alternativ kannst du auch mit ForceCommand experimentieren. Das kann man in die sshd_config eintragen:

Match User *
    ForceCommand /path/to/script.sh

LG,
CK

[TS]

Hello Christian,

danke für den Tipp.

Scheint aber wohl so, dass ich damit noch nicht zum vollständigen Erfolg komme...
Habe da mit deinen Stichworten noch mehr Lesestoff gefunden.

Liebe Grüße
Tom S.

[TS]

Hello,

leider hänge ich da immer noch, die richtige Stelle zu finden.
WEnn sich jemand mit seinem Filezilla-Client ohne Password, also mit private-/public-Key anmeldet, bekomme ich das nicht mit, weil ja keine Shellparameter geladen werden.

Wo ist da die zentrale Stelle, die ich anzapfen muss?

Liebe Grüße
Tom S.

[rolf]

Wo ist da die zentrale Stelle, die ich anzapfen muss?

Das aus dem User-Context heraus zu machen, ist der falsche Ansatz; ich würde einfach /var/log/auth.log überwachen (lassen).

[TS]

Hello,

Wo ist da die zentrale Stelle, die ich anzapfen muss?

Das aus dem User-Context heraus zu machen, ist der falsche Ansatz; ich würde einfach /var/log/auth.log überwachen (lassen).

Soweit war ich ja schon mal. Aber inotify ist mir einfach zu heftig dafür.
Wenn Root infected/affected ist, ist es vermutlich sowieso 2 Sekunden später zu spät :-O

Liebe Grüße
Tom S.

[rolf]

Das aus dem User-Context heraus zu machen, ist der falsche Ansatz; ich würde einfach /var/log/auth.log überwachen (lassen).

Soweit war ich ja schon mal. Aber inotify ist mir einfach zu heftig dafür.

Wer spricht denn von inotify, gibt keinen Grund sowas selber zu machen: rsyslogd kann auch Mails schreiben, es existieren diverse Tools zum Monitoring von Logs, etc.

Wenn Root infected/affected ist, ist es vermutlich sowieso 2 Sekunden später zu spät :-O

Was ist das eigentlich Ziel der ganzen Aktion?

[TS]

Hello,

Das aus dem User-Context heraus zu machen, ist der falsche Ansatz; ich würde einfach /var/log/auth.log überwachen (lassen).

Soweit war ich ja schon mal. Aber inotify ist mir einfach zu heftig dafür.

Wer spricht denn von inotify, gibt keinen Grund sowas selber zu machen: rsyslogd kann auch Mails schreiben, es existieren diverse Tools zum Monitoring von Logs, etc.

nun habe ich wieder tagelang weitergesucht und gelesen. Dass der rsyslogd das von Haus aus kann, ohne dass dafür ein Logeintrag verloren geht, konnte ich bisher nicht finden.

Kannst Du mir zeigen, wie es geht? die Messages an /var/log/auth.log gleichzeitig an einen Mailempfänger senden, wenn sie ein gültiges Auth eines bestimmten Users oder einer Gruppe von Usern beschreiben?

Gefunden habe ich allerdings immer wieder den Verweis auf ommail. Brauche ich das zwingend dafür?

Liebe Grüße
Tom S.

[TS]

Hello,

rsyslogd kann auch Mails schreiben, es existieren diverse Tools zum Monitoring von Logs, etc.

trotz Versuches, diese Doku zu rsyslogd zu verstehen, bin ich leider noch nicht weiter, wie ich den Filter realisieren kann und ob ich noch zusätzliche Module benötige (ommail) :-(

Die ganzen Konfigurationskürzel sind doch sehr eigen und kryptisch.

Meine rsyslog-Verfsion ist 5.8.11

Liebe Grüße
Tom S.

[rolf]

trotz Versuches, diese Doku zu rsyslogd zu verstehen, bin ich leider noch nicht weiter, wie ich den Filter realisieren kann und ob ich noch zusätzliche Module benötige (ommail) :-(

Die ganzen Konfigurationskürzel sind doch sehr eigen und kryptisch.

Meine rsyslog-Verfsion ist 5.8.11

Dabei kann ich dir leider nicht mehr helfen; damit kann ich nicht testen und die Syntax hat sich mitlerweile geändert. Mit einem aktuellen rsyslogd funktioniert es eines der Beispiele nach http://www.rsyslog.com/doc/v8-stable/configuration/modules/ommail.html anzupassen und nach /etc/rsyslog.d/test.conf zu kopieren.

[TS]

Hello,

trotz Versuches, diese Doku zu rsyslogd zu verstehen, bin ich leider noch nicht weiter, wie ich den Filter realisieren kann und ob ich noch zusätzliche Module benötige (ommail) :-(

Die ganzen Konfigurationskürzel sind doch sehr eigen und kryptisch.

Meine rsyslog-Verfsion ist 5.8.11

Dabei kann ich dir leider nicht mehr helfen; damit kann ich nicht testen und die Syntax hat sich mitlerweile geändert. Mit einem aktuellen rsyslogd funktioniert es eines der Beispiele nach http://www.rsyslog.com/doc/v8-stable/configuration/modules/ommail.html anzupassen und nach /etc/rsyslog.d/test.conf zu kopieren.

Wirklich schade. Das scheint erst mit ommail so zu funktionieren (einrichtbar zu sein), wie ich es brauche. Und das arbeitet noch nicht mit Version 5.8.11 zusammen.
Bei 5.8.11 gibt es nur omusrmsg und das kann scheinbar noch keine Bedingungen auswerten, wie z. B.

if $msg contains 'sshd\[d{1,6}\]: Accepted password for .* from' then :ommail:;mailBody

bzw. würe ich ... Accepted publickey ... auch noch benötigen.

Scheint aber nicht zu funktionierern. Für jeden gegenteiligen Tipp wäre ich dankbar. Bitte dann auch gerne per Mail [e-mail], wenn der Thread schon zu alt geworden sein sollte.

Sonst muss ich leider bis zum Update des Hosts warten oder doch was mit inotify basteln :-(

Liebe Grüße
Tom S.

[TS]

Hello,

kommt hier noch ein Tipp zum Vorschlag, oder muss ich die Hoffnung der (teilweisen) Erleuchtung leider abschreiben? :-)

Liebe Grüße
Tom S.