Warning: As always when you change the login configuration, leave a backup ssh session open in the background and test the login from a new terminal.

Since the sshrc method doesn't work if the user has their own ~/.ssh/rc file, I'll explain how to do this with pam_exec as @adosaiguas suggested. The good thing is that this can also be easily adapted to login types other than ssh (such as local logins or even all logins) by hooking into a different file in /etc/pam.d/.

First you need to be able to send mail from the command line. There are other questions about this. On a mail server it's probably easiest to install mailx (which is probably already installed anyway).

Then you need an executable script file login-notify.sh (I put it in /etc/ssh/ for example) with the following content. You can change the variables to change the subject and content of the e-mail notification. Don't forget to execute chmod +x login-notify.sh to make it executable.

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

Once you have that, you can add the following line to /etc/pam.d/sshd:

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

For testing purposes, the module is included as optional, so that you can still log in if the execution fails. After you made sure that it works, you can change optional to required. Then login won't be possible unless the execution of your hook script is successful (if that is what you want).

For those of you in need of an explanation of what PAM is and how it works, here is a very good one.

We have been using monit to monitor processes on our linux boxes. monit can also alert by emails on successful logins over ssh. Our monit config looks like this

 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

Note: The mailserver configuration, email format etc. should be set in monitrc file

Update:
Wrote a more detailed blog post on this

Put the following in /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

How the script works

/etc/profile is executed at every login (for bash shell users). The if statement will only return true if the user has logged in via ssh, which in turn will cause the indented code block to be run.

Next, we then build the text of the message:

• 
  $(date) will be replaced by the output of the date command


• 
  ${USER} will be replaced by the user’s login name


• 
  $(hostname -f) will be replaced by the full hostname of the system being logged into

The second TEXT line adds to the first, giving the IP address of the system this user is logging in from. Finally, the generated text is sent in an email to your address.

Summary Linux will, by default, record every system login, whether by ssh or not, in the system log files, but sometimes – particularly for a system that is seldom accessed via ssh – a quick and dirty notification can be useful.

In this other question you probably have what you are looking for.
Basically you can add a call to the mail command in the script that is run when a user logs in via ssh: /etc/pam.d/sshd

I've taken some of the excellent answers from this thread and made something that is more-or-less copy-and-pasteable. It uses Mailgun to send the emails so you are spared any issues with setting up STMP. You just need a Mailgun API key and a sending domain.

Upon SSH login, the script will send details of the login (user, hostname, IP address, and all current environment variables) to an email address. It's easy to add other parameters you'd want to send by customising the message variable.

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

This script in /etc/ssh/sshrc sends an email and adds a log to system logger. A difference is made (so you can disable it if you want) between your personal subnet and the world wide web (requires 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 adaptation of @Fritz answer

After posting I noticed @pacharanero also writes about mailgun, but I don't
understand what they are doing with dig, so I'll post my solution as well.

If you are on a VM that doesn't have SMTP, you might need to use something like mailgun, sendgrid, or the like. This worked for me on Google Cloud.

One risk of this approach is that an attacker may get your outgoing email sending credentials if they can sudo su and find the script or you leave the script for sending email readable. mailgun has an ip whitelist you should set up, but that's imperfect for this particular use case, obviously.

This script should work with mailgun after you change mydomain.com to your actual domain. You could save the script in /root/login-alert.sh or some more obscure location.

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

After that you can follow @Fritz answer to change /etc/pam.d/sshd to include:

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

I note this works with no read permissions for arriving users (chmod 700 /root/login-alert.sh) so arriving users do not need to have read access to the script.

I've actually just modified @SirCharlo answer

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>" &

This works on 14.04, 16.04 and Centos 6.5.x servers I've setup, I'm pretty sure you need to ensure mta is configured, but once that is done, this works a charm. Next step twilio alerts

I'm using swatchdog from the swatch package to monitor for any lines containing the phrase "fail" (case insensitive) in /var/log/auth.log. I set it up to run it as a simple systemd service.

apt install swatch

Create a configure file /etc/swatch/swatch-auth-log.conf with owner root, permission 644 --

watchfor /fail/i

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

The "/fail/i" is a regexp, with the "i" indicating it is case insensitive. (My sendmail is a script sending everything to a fixed address via mailgun, so the address doesn't really matter).

Create a systemd service file /etc/systemd/system/swatch-auth-log.service with owner root, permission 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

Then enable, start, and view the status of the service --

sudo systemctl enable swatch-auth-log.service

sudo systemctl start swatch-auth-log.service

sudo systemctl status swatch-auth-log.service

An example of a successful status report --

● 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

The service will be automatically started at boot and monitored by systemd.

Discussion

Originally I used a pam solution similar to the above, but in /etc/pam.d/common-auth not sshd. That was to catch ssh, sudo, and logins. But then after an update all my passwords stopped working, even after changing the passwords in rescue mode. Eventually I changed the /etc/pam.d/common-auth back to the original and passwords worked again. Here is a description on the Stack Exchange UNIX & Linux board

I decided it would be safer not to touch difficult to understand security settings. And everything is in the log files anyway.