Предупреждение: Как всегда при изменении конфигурации входа в систему оставьте резервное копирование ssh сессией открытый в фоновом режиме и протестируйте вход в систему от нового терминала.

Начиная с sshrc метод не работает, если у пользователя есть их собственное ~/.ssh/rc файл, я объясню, как сделать это с pam_exec как @adosaiguas предложенный. Хорошая вещь состоит в том, что это может также быть легко адаптировано для входа в систему в типы кроме ssh (такие как локальные логины или даже все логины) путем сцепления в другой файл в /etc/pam.d/.

Сначала необходимо смочь отправить почту от командной строки. Существуют другие вопросы об этом. На почтовом сервере является, вероятно, самым легким установить mailx (который, вероятно, уже установлен так или иначе).

Затем Вам нужен исполняемый файл сценария login-notify.sh (Я вставил его /etc/ssh/ например) со следующим содержанием. Можно заменить переменные для смены темы темы и содержания уведомления по электронной почте. Не забывайте выполняться chmod +x login-notify.sh сделать это исполняемым файлом.

#!/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

После того как у Вас есть это, можно добавить следующую строку к /etc/pam.d/sshd:

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

Для тестирования модуль включен как optional, так, чтобы можно было все еще войти в систему, если выполнение перестало работать. После того, как Вы удостоверились, что это работает, можно измениться optional кому: required. Затем вход в систему не будет возможен, если выполнение Вашего сценария рычага не будет успешно (если, именно это Вы хотите).

Для тех из Вас нуждающийся в объяснении того, что PAM и как он работает, вот очень хорошее.

Мы использовали monit для управляющих процессов на наших полях Linux. monit может также предупредить по электронным письмам на успешных логинах по ssh. Наш конфигурация monit похожа на это

 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

Примечание: mailserver конфигурация, почтовый формат и т.д. должен быть установлен в monitrc Обновление файла

: Записал более подробное сообщение в блоге на этом

Вставьте следующее /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

Как сценарий работает

/etc/profile выполняется при каждом входе в систему (для пользователей оболочки удара). Если оператор только возвратит true, если пользователь зарегистрировался на пути ssh, который в свою очередь заставит блок кода с отступом быть выполненным.

Затем, мы затем создаем текст сообщения:

• $(date) будет заменен выводом date команда
• ${USER} будет заменен именем для входа в систему пользователя
• $(hostname -f) будет заменен полным именем хоста вошедшей системы

Второе TEXT строка добавляет к первому, давая IP-адрес системы, от которой входит этот пользователь. Наконец, сгенерированный текст отправляется в электронном письме в Ваш адрес.

Сводный Linux, по умолчанию, запишет каждый системный вход в систему, может ли ssh или нет, в системных файлах журнала, но иногда – особенно для системы, к которой редко получают доступ через ssh – быстрое и грязное уведомление быть полезным.

В этот другом вопрос Вы, вероятно, имеете то, что Вы ищете. В основном можно добавить вызов к почтовая команда в скрипте, который запущен, когда пользователь регистрируется на пути ssh:/etc/pam.d/sshd

Я использую swatchdog от пакета образца для контроля для любых строк, содержащих фразу "сбой" (нечувствительный к регистру) в /var/log/auth.log. Я настроил его для выполнения его как простой systemd сервис.

apt install swatch

Создайте файл конфигурации/etc/swatch/swatch-auth-log.conf с корнем владельца, разрешением 644-

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

"/fail/i" является regexp, с "i", указывающим на это, нечувствительно к регистру. (Мой sendmail является сценарием, отправляющим все в фиксированный адрес через mailgun, таким образом, адрес действительно не имеет значения).

Создайте systemd сервисный файл/etc/systemd/system/swatch-auth-log.service с корнем владельца, разрешением 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

Затем включите, запустите и просмотрите состояние сервиса-

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

Пример успешного отчета о состоянии-

● 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

Сервис будет автоматически запускаться при начальной загрузке и контролироваться systemd.

Обсуждение

Первоначально я использовал pam решение, подобное вышеупомянутому, но в/etc/pam.d/common-auth не sshd. Это должно было поймать ssh, sudo, и логины. Но затем после обновления все мои пароли прекратили работать, даже после изменения паролей в спасательном режиме. В конечном счете я изменился/etc/pam.d/common-auth назад на оригинал, и пароли работали снова. Вот описание на плате Stack Exchange UNIX & Linux

Я решил, что будет более безопасно не затронуть трудный понять настройки безопасности. И все находится в файлах журнала так или иначе.

Я на самом деле только что изменил ответ @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>" &

, Это работает над 14,04, 16.04 и Centos 6.5.x серверы у меня есть установка, я вполне уверен, необходимо удостовериться, что mta настроен, но после того как это сделано, это работает очарование. Затем ступите twilio предупреждения

Я взял некоторые превосходные ответы от этого потока и сделал что-то, что является более или менее copy-pasteable. Это использует Mailgun для отправки электронных писем, таким образом, Вы сэкономлены любые проблемы с установкой STMP. Вам просто нужны ключ API Mailgun и передающий домен.

После входа в систему SSH сценарий отправит детали входа в систему (пользователь, имя хоста, IP-адрес и все текущие переменные среды) на адрес электронной почты. Легко добавить другие параметры, которые Вы хотели бы отправить путем настройки message переменная.

#!/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

Этот сценарий в /etc/ssh/sshrc посылает электронное письмо и добавляет журнал к системному регистратору. Значение имеется (таким образом, можно отключить его, если Вы хотите) между Вашей персональной подсетью, и Всемирная паутина (требует 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

Адаптация Mailgun ответа @Fritz

После регистрации я заметил, что @pacharanero также пишет о mailgun, но я не понимаю то, с чем они делают, роют, таким образом, я отправлю свое решение также.

Если Вы находитесь на VM, который не имеет SMTP, Вы, возможно, должны были бы использовать что-то как mailgun, sendgrid, и т.п. Это работало на меня на Google Cloud.

Один риск этого подхода состоит в том, что взломщик может получить Ваши учетные данные отправки исходящей почты, если они могут sudo su и найдите сценарий, или Вы оставляете сценарий для отправки читаемого электронного письма. mailgun имеет IP белый список, который необходимо настроить, но это несовершенно для этого конкретного варианта использования, очевидно.

Этот сценарий должен работать с mailgun после изменения mydomain.com к Вашему фактическому домену. Вы могли сохранить сценарий в /root/login-alert.sh или некоторое более неясное местоположение.

#!/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

После этого можно следовать ответу @Fritz на изменение /etc/pam.d/sshd включать:

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

Я отмечаю, что это работает без полномочий чтения на прибывающих пользователей (chmod 700 /root/login-alert.sh) у так прибывающих пользователей не должно быть доступа для чтения к сценарию.

Это работает для меня:

1- Найдите папку пользователя (корневая для меня):

echo  ~root

2- создайте или отредактируйте файл «.bashrc» в корневой папке:

nano root/.bashrc

(замените «root» своим пользователем папка)

3- добавьте следующие строки:

# ssh mail notification
echo 'NOTIFICATION - Acces SSH en ROOT sur `hostname` le:' `date` `who` | mail -s "NOTIFICATION - Connexion en ROOT via SSH depuis: `who | cut -d"(" -f2 | cut -d")" -f1`" myemail@domain.com

Просто замените (скрыто) на свой адрес электронной почты.

Повторите с другими пользователями, если их несколько.

Источник: http://blogmotion.fr/systeme/notification-connexion-ssh-4246