Jak skonfigurować powiadomienie e-mail, gdy logowanie do ssh zakończy się pomyślnie?


56

Czy ktoś ma skrypt bash, który wyśle ​​wiadomość e-mail lub powiadomi kogoś w przypadku udanego logowania na serwerze ssh? Chcę otrzymać powiadomienie, jeśli ktoś zaloguje się do mojej skrzynki osobistej.

Używam Ubuntu 12.04 z systemem Xfce

Odpowiedzi:


46

Ostrzeżenie: zgodnie z komentarzami nie działa to, jeśli użytkownik utworzy plik o nazwie ~/.ssh/rc. *

Zmodyfikuj lub utwórz /etc/ssh/sshrcza pomocą następującej zawartości:

ip=`echo $SSH_CONNECTION | cut -d " " -f 1`

logger -t ssh-wrapper $USER login from $ip
echo "User $USER just logged in from $ip" | sendemail -q -u "SSH Login" -f "Originator <from@address.com>" -t "Your Name <your.email@domain.com>" -s smtp.server.com &

To skutecznie powiadomi Cię e-mailem za każdym razem, gdy ktoś zaloguje się za pośrednictwem SSH, a login zostanie zalogowany w syslog.

Uwaga: Do działania powiadomienia e-mail potrzebujesz sendemailpakietu ( sudo apt-get install sendemail).

Uwaga: działa z przekierowaniem portów, ale z opcją -N nie.


Czy to działa również, jeśli klient nie zażąda TTY? Np. ssh -NTylko przekierowanie portów.
gertvdijk

Czy to działa również, gdy korzystamy z Gmaila jako serwera SMTP?
user155073

To wymaga ostrzeżenia : To nie działa, jeśli użytkownik utworzy plik o nazwie, ~/.ssh/rcwięc jest to całkiem bezużyteczne ze względów bezpieczeństwa. Odpowiedź @adosaiguas dotycząca pam_execjest poprawna.
Fritz

2
@mchid: Jeśli zastanowisz się nad pytaniem „Chcę otrzymać powiadomienie, jeśli ktoś zaloguje się do mojej skrzynki osobistej”. , to może być do zaakceptowania. Jeśli masz tylko jedno konto użytkownika. W przeciwnym razie musisz to zrobić dla wszystkich kont, w tym dla każdego nowo dodanego konta. I idealnie, upewnij się, że użytkownicy nie mogą modyfikować ani usuwać swoich ~/.ssh/rcplików. Korzystanie z ogólnosystemowej metody opartej na pamjest po prostu bardziej niezawodne i bezpieczniejsze, ponieważ tylko rootmożna się z tym pograć. Tak więc odpowiedź brzmi: sshrdmetody działają dobrze dla systemów z jednym użytkownikiem, ale pammetoda działa niezawodnie dla wszystkich systemów.
Fritz

70

Ostrzeżenie: jak zawsze po zmianie konfiguracji logowania, pozostaw otwartą sesję tworzenia kopii zapasowych w tle i przetestuj logowanie z nowego terminala.

Ponieważ sshrcmetoda nie działa, jeśli użytkownik ma własny ~/.ssh/rcplik, wyjaśnię, jak to zrobić za pomocą pam_exec@adosaiguas. Dobrą rzeczą jest to, że można to łatwo dostosować do typów logowania innych niż ssh(np. Lokalne loginy lub nawet wszystkie loginy) poprzez podłączenie do innego pliku /etc/pam.d/.

Najpierw musisz mieć możliwość wysyłania poczty z wiersza poleceń. Istnieją inne pytania na ten temat. Na serwerze pocztowym jest prawdopodobnie najłatwiejszy do zainstalowania mailx(i tak już prawdopodobnie jest już zainstalowany).

Następnie potrzebujesz pliku skryptu wykonywalnego login-notify.sh(umieszczam go /etc/ssh/na przykład) o następującej treści. Możesz zmienić zmienne, aby zmienić temat i treść powiadomienia e-mail. Nie zapomnij wykonać, chmod +x login-notify.shaby był wykonywalny.

#!/bin/sh

# Change these two lines:
sender="sender-address@example.com"
recepient="notify-address@example.org"

if [ "$PAM_TYPE" != "close_session" ]; then
    host="`hostname`"
    subject="SSH Login: $PAM_USER from $PAM_RHOST on $host"
    # Message to send, e.g. the current environment variables.
    message="`env`"
    echo "$message" | mailx -r "$sender" -s "$subject" "$recepient"
fi

Gdy to zrobisz, możesz dodać następujący wiersz /etc/pam.d/sshd:

session optional pam_exec.so seteuid /path/to/login-notify.sh

Do celów testowych moduł jest dołączony jako optional, abyś mógł nadal się logować, jeśli wykonanie się nie powiedzie. Po upewnieniu się, że działa, możesz zmienić optionalna required. W takim przypadku logowanie nie będzie możliwe, chyba że wykonanie skryptu przechwytującego zakończyło się powodzeniem (jeśli tego właśnie chcesz).

Dla tych z Was, którzy potrzebują wyjaśnienia, czym jest PAM i jak działa, oto bardzo dobre .


1
Mówi: /etc/ssh/login-notify.sh failed: exit code 13zaraz po zalogowaniu :(
FelikZ

3
Dzięki, działa świetnie. Upewnij się tylko, że UsePAMustawiłeś yesopcję w swoim sshd_config.
Nicolas BADIA,

2
Uwaga dla mnie lub innych osób, które są nowicjuszami w Selinux. Wystąpił błąd uprawnień, gdy pam_exec uruchomił skrypt. Później dowiedziałem się, że był nieprawidłowo oznaczony dla Selinux. Sklonowałem skrypt do / bin /, który zostanie automatycznie oznaczony jako unconfined_u:object_r:bin_t:s0. Potem ja chmod +x /bin/login-notify.shi to działa.
RedGiant

3
/etc/pam.d/login <- dla logowań tty
Fernando André

2
@ 4wk_ Dzięki za podpowiedź. Zamieniłem go na link do archiwum internetowego, więc powinien działać ponownie.
Fritz

9

Używamy Monit monitorować procesy na naszych linuxowych. Monitor może również powiadamiać e-mailem o udanych logowaniach przez ssh. Nasza konfiguracja monitora wygląda następująco

 check file ssh_logins with path /var/log/auth.log  
     # Ignore login's from whitelist ip addresses
     ignore match "100.100.100.1"    
     # Else, alert
     if match "Accepted publickey" then alert

Uwaga: konfigurację serwera pocztowego, format wiadomości e-mail itp. Należy ustawić w monitrcpliku

Aktualizacja: Napisałem bardziej szczegółowy post na ten temat


7

Wprowadź następujące dane /etc/profile:

if [ -n "$SSH_CLIENT" ]; then 
    TEXT="$(date): ssh login to ${USER}@$(hostname -f)" 
    TEXT="$TEXT from $(echo $SSH_CLIENT|awk '{print $1}')" 
    echo $TEXT|mail -s "ssh login" you@your.domain 
fi

Jak działa skrypt

/etc/profilejest wykonywany przy każdym logowaniu (dla użytkowników powłoki bash). Instrukcja if zwróci wartość true tylko wtedy, gdy użytkownik zaloguje się przez ssh, co z kolei spowoduje uruchomienie bloku kodu z wcięciem.

Następnie budujemy tekst wiadomości:

  • $(date)zostanie zastąpiony przez wynik datepolecenia
  • ${USER} zostanie zastąpiony nazwą użytkownika
  • $(hostname -f) zostanie zastąpiony pełną nazwą hosta, do którego logowany jest system

Druga TEXTlinia dodaje się do pierwszej, podając adres IP systemu, z którego loguje się ten użytkownik. Na koniec wygenerowany tekst jest wysyłany w wiadomości e-mail na Twój adres.

Podsumowanie Linux domyślnie rejestruje każde logowanie do systemu, czy to przez ssh, czy nie, w plikach dziennika systemu, ale czasami - szczególnie w przypadku systemu, do którego dostęp jest rzadko uzyskiwany za pośrednictwem ssh - przydatne może być szybkie i nieprzyzwoite powiadomienie.


2

W tym drugim pytaniu prawdopodobnie masz to, czego szukasz. Zasadniczo możesz dodać wywołanie do polecenia mail w skrypcie, który jest uruchamiany, gdy użytkownik loguje się za pośrednictwem ssh: /etc/pam.d/sshd


2

Wziąłem kilka doskonałych odpowiedzi z tego wątku i stworzyłem coś, co można mniej więcej skopiować i wkleić. Używa Mailgun do wysyłania wiadomości e-mail, dzięki czemu oszczędzasz wszelkich problemów z konfiguracją STMP. Potrzebujesz tylko klucza API Mailgun i domeny wysyłającej.

Po zalogowaniu SSH skrypt wyśle ​​szczegóły logowania (użytkownik, nazwa hosta, adres IP i wszystkie bieżące zmienne środowiskowe) na adres e-mail. Łatwo jest dodać inne parametry, które chcesz wysłać, dostosowując messagezmienną.

#!/bin/sh

# this script is triggered on SSH login and sends an email with details of the login
# such as user, IP, hostname, and environment variables

# script should be placed somewhere on the server, eg /etc/ssh
# to trigger on SSH login, put this line in /etc/pam.d/sshd:
#   session optional pam_exec.so seteuid /etc/ssh/snippet-for-sending-emails-on-SSH-login-using-PAM.sh

# Script settings
MAILGUN_API_KEY=
MAILGUN_DOMAIN=
SENDER_NAME=
SENDER_EMAIL_ADDRESS=
RECIPIENT_EMAIL_ADDRESS=

if [ "$PAM_TYPE" != "close_session" ]; then
    host=$(hostname)
    ip=$(dig +short myip.opendns.com @resolver1.opendns.com) # gets public IP
    # Message to send, e.g. the current environment variables.
    subject="SSH login - user:$USER pam-host:$PAM_RHOST host:$host ip:$ip" \
    message=$(env)
    curl -s --user '$MAILGUN_API_KEY' \
        https://api.mailgun.net/v3/$MAILGUN_DOMAIN/messages \
        -F from='$SENDER_NAME <$SENDER_EMAIL_ADDRESS>' \
        -F to=$RECIPIENT_EMAIL_ADDRESS \
        -F subject="$subject" \
        -F text="${subject} ${message}"
fi

To jest najlepsza odpowiedź moim zdaniem. Jest to proste i nie wymaga wysyłania wiadomości e-mail z urządzenia, które z pewnością trafi do folderu ze spamem, chyba że zostanie odpowiednio skonfigurowany.
JayD3e

2

Adaptacja mailguna odpowiedzi @Fritz

Po opublikowaniu zauważyłem, że @pacharanero pisze również o mailgunie, ale nie rozumiem, co robią z kopaniem, więc opublikuję również moje rozwiązanie.

Jeśli korzystasz z maszyny wirtualnej, która nie ma SMTP, być może będziesz musiał użyć czegoś takiego jak mailgun, sendgrid lub tym podobne. To działało dla mnie w Google Cloud.

Jednym z zagrożeń związanych z tym podejściem jest to, że osoba atakująca może uzyskać poświadczenia wychodzące wiadomości e-mail, jeśli może sudo sui znajdzie skrypt, lub jeśli skrypt zostanie wysłany jako czytelny. Mailgun ma białą listę adresów IP, którą powinieneś skonfigurować, ale to oczywiście nie jest idealne w tym konkretnym przypadku użycia.

Ten skrypt powinien działać z pocztą po przejściu mydomain.comna rzeczywistą domenę. Możesz zapisać skrypt w /root/login-alert.shbardziej niejasnej lokalizacji.

#!/bin/bash
if [ "$PAM_TYPE" != "close_session" ]; then
    APK='api:your-mailgun-api-key-goes-here' 
    FROM='Login Alert <mailgun@mg.mydomain.com>'
    TO='me@mydomain.com'  
    SUBJECT="Login: $PAM_USER @ mydomain.com from $PAM_RHOST"
    DATE=$(date)
    TEXT="At $DATE a login occurred for $PAM_USER on mydomain.com from $PAM_RHOST"
    curl -s --user $APK \
     https://api.mailgun.net/v3/mg.mydomain.com/messages \
     -F from="$FROM" \
     -F to="$TO" \
     -F subject="$SUBJECT" \
     -F text="$TEXT"
fi

Następnie możesz postępować zgodnie z odpowiedzią @Fritz, aby zmienić, /etc/pam.d/sshdaby uwzględnić:

session optional pam_exec.so seteuid /root/login-alert.sh

Zauważam, że działa to bez uprawnień odczytu dla przybywających użytkowników ( chmod 700 /root/login-alert.sh), więc przybywający użytkownicy nie muszą mieć dostępu do odczytu skryptu.


1

Skrypt ten /etc/ssh/sshrcwysyła wiadomość e-mail i dodaje dziennik do rejestratora systemu. Wprowadzono różnicę (więc możesz ją wyłączyć, jeśli chcesz) między osobistą podsiecią a siecią (wymaga sudo apt-get install mailutils).

SUBNET="192.168.0"

IP=`echo $SSH_CONNECTION | cut -d " " -f 1`
CURRENT_SUBNET="$(echo $IP|cut -d'.' -f1-3)"
if [ "$CURRENT_SUBNET" = "$SUBNET" ]; then
        msg="This message comes from same subnet! User $USER just logged in from $IP"
        echo $msg|mail -s "$msg" root
else
        msg="This message comes from different subnet! User $USER just logged in from $IP"
        echo $msg|mail -s "$msg" root
fi

logger -t ssh-wrapper $USER login from $IP

1

Używam programu swatchdog z pakietu swatch do monitorowania wszelkich wierszy zawierających wyrażenie „ fail ” (bez rozróżniania wielkości liter) w /var/log/auth.log . Skonfigurowałem go tak, aby działał jako prosta usługa systemowa.

apt install swatch

Utwórz plik konfiguracyjny /etc/swatch/swatch-auth-log.conf z rootem właściciela, uprawnieniem 644 -

watchfor /fail/i
  pipe /usr/local/sbin/sendmail -t auth.log@xxx.com

„/ Nie / i” jest wyrażeniem regularnym, z „ja”, co wskazuje, że nie uwzględnia wielkości liter. (Mój sendmail to skrypt wysyłający wszystko na ustalony adres za pośrednictwem skrzynki pocztowej , więc adres tak naprawdę nie ma znaczenia).

Utwórz plik usługi systemd /etc/systemd/system/swatch-auth-log.service z rootem właściciela, uprawnieniem 644 -

[Unit]
Description=monitor /var/log/auth.log, send fail notices by mail

[Service]
ExecStart=/usr/bin/swatchdog -c /etc/swatch/swatch-auth-log.conf -t /var/log/auth.log

[Install]
#WantedBy=multi-user.target
WantedBy=pre-network.target

Następnie włącz, uruchom i wyświetl status usługi -

sudo systemctl enable swatch-auth-log.service
sudo systemctl start swatch-auth-log.service
sudo systemctl status swatch-auth-log.service

Przykład udanego raportu o stanie -

 swatch-auth-log.service - monitor /var/log/auth.log, send fail notices by mail
   Loaded: loaded (/etc/systemd/system/swatch-auth-log.service; enabled; vendor preset: enabled)
   Active: active (running) since Thu 2019-01-31 21:41:52 PST; 17min ago
 Main PID: 27945 (swatchdog)
    Tasks: 3 (limit: 4915)
   CGroup: /system.slice/swatch-auth-log.service
           ├─27945 /usr/bin/perl /usr/bin/swatchdog -c /etc/swatch/swatch-auth-log.conf -t /var/log/auth.log
           ├─27947 /usr/bin/perl /.swatchdog_script.27945
           └─27949 /usr/bin/tail -n 0 -F /var/log/auth.log

Jan 31 21:41:52 ub18 systemd[1]: Started monitor /var/log/auth.log, send fail notices by mail.
Jan 31 21:41:52 ub18 swatchdog[27945]: *** swatchdog version 3.2.4 (pid:27945) started at Thu Jan 31 21:41:52 PST 2019

Usługa zostanie automatycznie uruchomiona podczas rozruchu i będzie monitorowana przez systemd .


Dyskusja

Pierwotnie użyłem rozwiązania pam podobnego do powyższego, ale w /etc/pam.d/common-auth nie sshd . To było złapanie ssh, sudo i loginów. Ale potem po aktualizacji wszystkie moje hasła przestały działać, nawet po zmianie haseł w trybie ratunkowym. W końcu zmieniłem /etc/pam.d/common-auth z powrotem na oryginalny i hasła znów działały. Oto opis na płycie Stack Exchange UNIX i Linux

Uznałem, że bezpieczniej będzie nie dotykać trudnych do zrozumienia ustawień bezpieczeństwa. I tak wszystko jest w plikach dziennika.


0

Właśnie zmodyfikowałem odpowiedź @ SirCharlo

ip=`echo $SSH_CONNECTION | cut -d " " -f 1`

logger -t ssh-wrapper $USER login from $ip
echo "User $USER just logged in from $ip" | mail -s "SSH Login" "who to <who-to@youremail.com>" &

Działa to na serwerach 14.04, 16.04 i Centos 6.5.x, które skonfigurowałem, jestem prawie pewien, że musisz upewnić się, że mta jest skonfigurowany, ale kiedy to zrobisz, działa to uroczo. Kolejny krok powiadomienia Twilio

Korzystając z naszej strony potwierdzasz, że przeczytałeś(-aś) i rozumiesz nasze zasady używania plików cookie i zasady ochrony prywatności.
Licensed under cc by-sa 3.0 with attribution required.