Comment configurer une alerte email quand une connexion ssh est réussie?


56

Est-ce que quelqu'un a un script bash qui va envoyer un email ou informer quelqu'un dans le cas d'une connexion réussie à un serveur ssh? Je souhaite être averti si quelqu'un se connecte à ma boîte personnelle.

J'utilise Ubuntu 12.04 sous xfce

Réponses:


46

Attention: selon les commentaires, cela ne fonctionnera pas si l'utilisateur crée un fichier nommé ~/.ssh/rc. *

Modifiez ou créez /etc/ssh/sshrcavec le contenu suivant:

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 &

Cela vous avertira par courrier électronique chaque fois que quelqu'un se connectera via SSH, et le login sera enregistré dans le syslog.

Remarque: vous aurez besoin du sendemailpackage ( sudo apt-get install sendemail) pour que la notification par courrier électronique fonctionne.

Remarque: fonctionne avec la redirection de port, mais pas avec l'option -N.


Cela fonctionne-t-il également si le client ne demande pas de téléscripteur? Par exemple, ssh -Navec uniquement un transfert de port.
gertvdijk

cela fonctionne-t-il également lorsque nous utilisons gmail en tant que serveur smtp?
user155073

Cela nécessite un avertissement : cela ne fonctionnera pas si l’utilisateur crée un fichier appelé ~/.ssh/rc, il est donc très inutile comme mesure de sécurité. La réponse de @adosaiguas concernant pam_execest la bonne.
Fritz

2
@ mchid: Si vous considérez la question "Je veux être averti si quelqu'un se connecte à ma boîte personnelle." , alors cela pourrait être acceptable. Si vous avez un seul compte utilisateur. Sinon, vous devez le faire pour tous les comptes, y compris chaque compte nouvellement ajouté. Et idéalement, vous devez vous assurer que les utilisateurs ne peuvent pas modifier ou supprimer leur ~/.ssh/rcfichier. L'utilisation d'une méthode basée sur l'ensemble du système pamest simplement plus fiable et plus sûre, car elle seule rootpeut la gâcher. La réponse est donc la suivante: les sshrdméthodes fonctionnent correctement pour les systèmes mono-utilisateur, mais la pamméthode fonctionne de manière fiable pour tous les systèmes.
Fritz

70

Avertissement: comme toujours lorsque vous modifiez la configuration de connexion, laissez une session de sauvegarde ssh ouverte en arrière-plan et testez la connexion à partir d'un nouveau terminal.

Puisque la sshrcméthode ne fonctionne pas si l'utilisateur a son propre ~/.ssh/rcfichier, j'expliquerai comment procéder, pam_execcomme suggéré par @adosaiguas. La bonne chose est que cela peut également être facilement adapté à des types de connexion autres que ssh(tels que les connexions locales ou même toutes les connexions) en se connectant à un autre fichier dans /etc/pam.d/.

Vous devez d’abord pouvoir envoyer du courrier à partir de la ligne de commande. Il y a d'autres questions à ce sujet. Sur un serveur de messagerie, il est probablement plus facile à installer mailx(ce qui est probablement déjà fait).

Ensuite, vous avez besoin d’un fichier de script exécutable login-notify.sh(je le mets /etc/ssh/par exemple) avec le contenu suivant. Vous pouvez modifier les variables pour modifier l'objet et le contenu de la notification par courrier électronique. N'oubliez pas d'exécuter chmod +x login-notify.shpour le rendre exécutable.

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

Une fois que vous avez cela, vous pouvez ajouter la ligne suivante à /etc/pam.d/sshd:

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

À des fins de test, le module est inclus en tant que optional, afin que vous puissiez toujours vous connecter si l'exécution échoue. Après vous être assuré que cela fonctionne, vous pouvez le remplacer optionalpar required. Dans ce cas, la connexion ne sera possible que si l'exécution de votre script de raccordement est réussie (si c'est ce que vous voulez).

Pour ceux d'entre vous qui ont besoin d'une explication de ce qu'est PAM et de son fonctionnement, en voici une très bonne .


1
Il dit: /etc/ssh/login-notify.sh failed: exit code 13juste après la connexion :(
FelikZ

3
Merci, ça marche très bien. Assurez-vous simplement que vous avez UsePAMdéfini le paramètre yesdans votre sshd_config.
Nicolas BADIA

2
Juste une note pour moi-même ou d'autres personnes qui sont nouvelles à Selinux. J'ai reçu une erreur d'autorisation lorsque pam_exec a exécuté le script. Plus tard, j'ai découvert qu'il était incorrectement étiqueté pour Selinux. J'ai cloné le script dans / bin / qui sera automatiquement étiqueté unconfined_u:object_r:bin_t:s0. Alors moi chmod +x /bin/login-notify.shet ça marche.
RedGiant

3
/etc/pam.d/login <- pour les connexions par tty
Fernando André le

2
@ 4wk_ Merci pour cet indice. Je l'ai remplacé par un lien vers Internet Archive, il devrait donc fonctionner à nouveau maintenant.
Fritz le

9

Nous utilisons monit pour surveiller les processus sur nos boîtes Linux. monit peut également alerter par e-mail les connexions réussies via ssh. Notre configuration monit ressemble à ceci

 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

Remarque: La configuration du serveur de courrier, le format de courrier électronique, etc. doivent être définis dans le monitrcfichier.

Mise à jour: a écrit un article de blog plus détaillé à ce sujet.


7

Mettez ce qui suit dans /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

Comment fonctionne le script

/etc/profileest exécuté à chaque connexion (pour les utilisateurs du shell bash). L'instruction if ne renvoie true que si l'utilisateur s'est connecté via ssh, ce qui entraîne l'exécution du bloc de code en retrait.

Ensuite, nous construisons le texte du message:

  • $(date)sera remplacé par la sortie de la datecommande
  • ${USER} sera remplacé par le nom d'utilisateur de l'utilisateur
  • $(hostname -f) sera remplacé par le nom d'hôte complet du système en cours de connexion

La deuxième TEXTligne s'ajoute à la première, donnant l'adresse IP du système à partir duquel cet utilisateur se connecte. Enfin, le texte généré est envoyé par courrier électronique à votre adresse.

Résumé Linux enregistrera par défaut chaque connexion système, que ce soit par ssh ou non, dans les fichiers journaux du système, mais parfois - en particulier pour un système rarement utilisé via ssh - une notification rapide et incorrecte peut être utile.


2

Dans cette autre question, vous avez probablement ce que vous recherchez. En gros, vous pouvez ajouter un appel à la commande mail dans le script exécuté lorsqu'un utilisateur se connecte via ssh: /etc/pam.d/sshd


2

J'ai tiré quelques-unes des excellentes réponses de ce fil de discussion pour en faire quelque chose de plus ou moins copier-coller. Il utilise Mailgun pour envoyer les courriels, ce qui vous évite tout problème de configuration du protocole STMP. Vous avez juste besoin d'une clé API Mailgun et d'un domaine d'envoi.

Lors de la connexion SSH, le script envoie les détails de la connexion (utilisateur, nom d’hôte, adresse IP et toutes les variables d’environnement actuelles) à une adresse électronique. Il est facile d'ajouter d'autres paramètres à envoyer en personnalisant 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

C'est la meilleure réponse à mon avis. C'est simple et ne nécessite pas l'envoi d'un courrier électronique depuis la machine, qui finira sûrement dans le dossier de courrier indésirable s'il n'est pas correctement configuré.
JayD3e

2

Mailgun adaptation de @Fritz answer

Après avoir posté, j'ai remarqué que @pacharanero parlait aussi de mailgun, mais je ne comprends pas ce qu'ils font avec dig, alors je vais aussi poster ma solution.

Si vous utilisez une machine virtuelle qui n’a pas le protocole SMTP, vous devrez peut-être utiliser quelque chose comme mailgun, sendgrid, etc. Cela a fonctionné pour moi sur Google Cloud.

L’un des risques de cette approche est qu’un attaquant peut obtenir votre identifiant d’envoi de courrier électronique sortant s’il le peut sudo suet trouver le script ou vous laisser le script pour envoyer le courrier en lecture. mailgun a une liste blanche d'ip que vous devriez configurer, mais c'est imparfait pour ce cas d'utilisation particulier, évidemment.

Ce script devrait fonctionner avec mailgun une fois que vous avez changé mydomain.comde domaine. Vous pouvez enregistrer le script dans /root/login-alert.shun endroit plus obscur.

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

Après cela, vous pouvez suivre @Fritz answer to change /etc/pam.d/sshdto include pour inclure:

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

Je remarque que cela fonctionne sans autorisation de lecture pour les utilisateurs arrivés ( chmod 700 /root/login-alert.sh); les utilisateurs qui arrivent n'ont donc pas besoin d'un accès en lecture au script.


1

Ce script /etc/ssh/sshrcenvoie un courrier électronique et ajoute un journal à l'enregistreur système. Une différence est faite (vous pouvez donc la désactiver si vous le souhaitez) entre votre sous-réseau personnel et le World Wide Web (obligatoire 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

J'utilise swatchdog à partir du package swatch pour contrôler les lignes contenant la phrase " fail " (insensible à la casse) dans /var/log/auth.log . Je l'ai configuré pour l'exécuter comme un simple service systemd.

apt install swatch

Créez un fichier de configuration /etc/swatch/swatch-auth-log.conf avec le propriétaire root, permission 644 -

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

Le "/ fail / i" est une expression rationnelle, le "i" indiquant qu'il est insensible à la casse. (Mon sendmail est un script qui envoie tout à une adresse fixe via mailgun , l'adresse n'a donc pas d'importance).

Créez un fichier de service systemd /etc/systemd/system/swatch-auth-log.service avec le propriétaire root, autorisation 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

Puis activez, démarrez et affichez l’état du service -

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

Un exemple de rapport de statut réussi -

 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

Le service sera automatiquement lancé au démarrage et surveillé par systemd .


Discussion

A l’origine, j’utilisais une solution pam similaire à celle ci-dessus, mais dans /etc/pam.d/common-auth pas sshd . C'était pour attraper ssh, sudo et logins. Mais après une mise à jour, tous mes mots de passe ont cessé de fonctionner, même après modification des mots de passe en mode de secours. Finalement, j'ai remplacé le fichier /etc/pam.d/common-auth par son nom d'origine et les mots de passe ont à nouveau fonctionné. Voici une description de la carte Stack Exchange UNIX & Linux

J'ai décidé qu'il serait plus sûr de ne pas toucher aux paramètres de sécurité difficiles à comprendre. Et tout est dans les fichiers journaux de toute façon.


0

Je viens de modifier @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>" &

Cela fonctionne sur les serveurs 14.04, 16.04 et Centos 6.5.x que j'ai configurés. Je suis presque certain que vous devez vous assurer que mta est configuré, mais une fois que cela est fait, cela fonctionne. Prochaine étape twilio alerts

En utilisant notre site, vous reconnaissez avoir lu et compris notre politique liée aux cookies et notre politique de confidentialité.
Licensed under cc by-sa 3.0 with attribution required.