¿Alguien tiene un script bash que envíe un correo electrónico o notifique a alguien en el caso de un inicio de sesión exitoso en un servidor ssh? Quiero ser notificado si alguien inicia sesión en mi casilla personal.

Estoy usando Ubuntu 12.04 ejecutando xfce

Advertencia: según los comentarios, esto no funciona si el usuario crea un archivo llamado ~/.ssh/rc. *

Modifique o cree /etc/ssh/sshrccon los siguientes contenidos:

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 <[email protected]>" -t "Your Name <[email protected]>" -s smtp.server.com &

Esto lo notificará de manera efectiva por correo electrónico cada vez que alguien inicie sesión a través de SSH, y el inicio de sesión se registrará en el syslog.

Nota: Necesitará el sendemailpaquete ( sudo apt-get install sendemail) para que funcione la notificación por correo electrónico.

Nota: funciona con el reenvío de puertos, pero con la opción -N no.

Advertencia: como siempre que cambia la configuración de inicio de sesión, deje abierta una sesión ssh de respaldo en segundo plano y pruebe el inicio de sesión desde un nuevo terminal.

Dado que el sshrcmétodo no funciona si el usuario tiene su propio ~/.ssh/rcarchivo, explicaré cómo hacerlo con pam_exec@adosaiguas sugirió. Lo bueno es que esto también se puede adaptar fácilmente a tipos de inicio de sesión que no sean ssh(como inicios de sesión locales o incluso todos los inicios de sesión) al engancharse a un archivo diferente /etc/pam.d/.

Primero debe poder enviar correo desde la línea de comandos. Hay otras preguntas sobre esto. En un servidor de correo probablemente sea más fácil de instalar mailx(que probablemente ya esté instalado de todos modos).

Luego necesita un archivo de script ejecutable login-notify.sh(lo puse /etc/ssh/por ejemplo) con el siguiente contenido. Puede cambiar las variables para cambiar el asunto y el contenido de la notificación por correo electrónico. No olvide ejecutar chmod +x login-notify.shpara que sea ejecutable.

#!/bin/sh

# Change these two lines:
sender="[email protected]"
recepient="[email protected]"

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

Una vez que tenga eso, puede agregar la siguiente línea a /etc/pam.d/sshd:

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

Para fines de prueba, el módulo se incluye como optional, de modo que aún puede iniciar sesión si falla la ejecución. Después de asegurarte de que funciona, puedes cambiar optionala required. Entonces el inicio de sesión no será posible a menos que la ejecución de su script de enlace sea exitosa (si eso es lo que desea).

Para aquellos de ustedes que necesitan una explicación de qué es PAM y cómo funciona, aquí hay una muy buena .

Hemos estado usando monit para monitorear procesos en nuestras cajas de linux. Monit también puede alertar por correo electrónico sobre inicios de sesión exitosos a través de ssh. Nuestra configuración de monit se ve así

 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

Nota: La configuración del servidor de correo, el formato de correo electrónico, etc., deben establecerse en el monitrcarchivo

Actualización: escribí una publicación de blog más detallada sobre esto

Ponga lo siguiente en /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

Cómo funciona el guión

/etc/profilese ejecuta en cada inicio de sesión (para usuarios de bash shell). La instrucción if solo devolverá true si el usuario ha iniciado sesión a través de ssh, lo que a su vez hará que se ejecute el bloque de código sangrado.

Luego, construimos el texto del mensaje:

• $(date)será reemplazado por la salida del datecomando
• ${USER} será reemplazado por el nombre de usuario de inicio de sesión
• $(hostname -f) será reemplazado por el nombre de host completo del sistema que está iniciando sesión

La segunda TEXTlínea se agrega a la primera, dando la dirección IP del sistema desde el cual este usuario inicia sesión. Finalmente, el texto generado se envía en un correo electrónico a su dirección.

Resumen Linux, de manera predeterminada, registrará cada inicio de sesión del sistema, ya sea mediante ssh o no, en los archivos de registro del sistema, pero a veces, particularmente para un sistema al que rara vez se accede a través de ssh, puede ser útil una notificación rápida y sucia.

En esta otra pregunta , probablemente tenga lo que está buscando. Básicamente, puede agregar una llamada al comando de correo en el script que se ejecuta cuando un usuario inicia sesión a través de ssh: /etc/pam.d/sshd

Tomé algunas de las excelentes respuestas de este hilo e hice algo que es más o menos copiar y pegar. Utiliza Mailgun para enviar los correos electrónicos para evitar cualquier problema con la configuración de STMP. Solo necesita una clave API de Mailgun y un dominio de envío.

Al iniciar sesión en SSH, el script enviará los detalles del inicio de sesión (usuario, nombre de host, dirección IP y todas las variables de entorno actuales) a una dirección de correo electrónico. Es fácil agregar otros parámetros que desea enviar al personalizar la messagevariable.

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

Adaptación de Mailgun de la respuesta de @Fritz

Después de publicar, noté que @pacharanero también escribe sobre mailgun, pero no entiendo lo que están haciendo con dig, así que publicaré mi solución también.

Si está en una máquina virtual que no tiene SMTP, es posible que deba usar algo como mailgun, sendgrid o similares. Esto funcionó para mí en Google Cloud.

Un riesgo de este enfoque es que un atacante puede obtener sus credenciales de envío de correo electrónico saliente si puede sudo suy encontrar el guión o usted deja el guión para enviar el correo electrónico legible. mailgun tiene una lista blanca de ip que debe configurar, pero eso es imperfecto para este caso de uso en particular, obviamente.

Este script debería funcionar con mailgun después de cambiar mydomain.coma su dominio real. Podrías guardar el script en /root/login-alert.sho en una ubicación más oscura.

#!/bin/bash
if [ "$PAM_TYPE" != "close_session" ]; then
    APK='api:your-mailgun-api-key-goes-here' 
    FROM='Login Alert <[email protected]>'
    TO='[email protected]'  
    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

Después de eso, puede seguir la respuesta de @Fritz para cambiar e /etc/pam.d/sshdincluir:

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

Observo que esto funciona sin permisos de lectura para los usuarios que llegan ( chmod 700 /root/login-alert.sh), por lo que los usuarios que llegan no necesitan tener acceso de lectura al script.

Este script /etc/ssh/sshrcenvía un correo electrónico y agrega un registro al registrador del sistema. Se hace una diferencia (para que pueda deshabilitarla si lo desea) entre su subred personal y la red mundial (requiere 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

Estoy usando swatchdog del paquete de muestras para monitorear cualquier línea que contenga la frase " fail " (no distingue entre mayúsculas y minúsculas) en /var/log/auth.log . Lo configuré para ejecutarlo como un simple servicio systemd.

apt install swatch

Cree un archivo de configuración /etc/swatch/swatch-auth-log.conf con el propietario root, permiso 644 -

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

El "/ Falla / i" es una expresión regular, con la "i" que indica que es sensible a mayúsculas. (Mi sendmail es un script que envía todo a una dirección fija a través de mailgun , por lo que la dirección realmente no importa).

Cree un archivo de servicio systemd /etc/systemd/system/swatch-auth-log.service con la raíz del propietario, permiso 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

Luego habilite, inicie y vea el estado del servicio:

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

Un ejemplo de informe de estado exitoso:

● 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

El servicio se iniciará automáticamente en el arranque y será supervisado por systemd .

Discusión

Originalmente utilicé una solución pam similar a la anterior, pero en /etc/pam.d/common-auth no sshd . Eso fue para atrapar ssh, sudo e inicios de sesión. Pero luego de una actualización, todas mis contraseñas dejaron de funcionar, incluso después de cambiar las contraseñas en modo de rescate. Finalmente cambié el /etc/pam.d/common-auth al original y las contraseñas volvieron a funcionar. Aquí hay una descripción en la placa Stack Exchange UNIX y Linux

Decidí que sería más seguro no tocar la configuración de seguridad difícil de entender. Y todo está en los archivos de registro de todos modos.

De hecho, acabo de modificar la respuesta de @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 <[email protected]>" &

Esto funciona en los servidores 14.04, 16.04 y Centos 6.5.x que configuré, estoy bastante seguro de que necesita asegurarse de que mta esté configurado, pero una vez hecho esto, funciona de maravilla. Siguiente paso alertas de twilio