3

I modified /etc/pam.d/common-auth to run a bash script when a login fails or when a login is successful and it works for successful logins but not failed login attempts when trying to ssh. Once I am already on the server and try use sudo both scripts will run for both failed authentication and success. Why won't login-failed-notify.sh excecute during a failed ssh login attempt? I added the following to the default /etc/pam.d/common-auth file.

# here are the per-package modules (the "Primary" block)
auth    [success=2 default=ignore]      pam_unix.so nullok_secure
# here's the fallback if no module succeeds
auth optional pam_exec.so seteuid /etc/ssh/failed-login-notify.sh
auth    requisite                       pam_deny.so
auth optional pam_exec.so seteuid /etc/ssh/login-notify.sh
# prime the stack with a positive return value if there isn't one already;
# this avoids us returning an error just because nothing sets a success code
# since the modules above will each just jump around
auth    required                        pam_permit.so
# and here are more per-package modules (the "Additional" block)
auth    optional                        pam_cap.so
# end of pam-auth-update config

My bash scripts have no logic, they simply send a get request when they are run.

Here is my login-notify.sh, failed-login-notify.sh is exactly the same but says failed in the text.

#!/bin/sh
CURL='/usr/bin/curl'
RVMHTTP="http://192.168.1.100/update.php?ip=$PAM_HOST&server=192.168.1.101&status=success"
CURLARGS="-f -s -S -k"
raw="$($CURL $CURLARGS $RVMHTTP)"

Here is /etc/pam.d/sshd

# PAM configuration for the Secure Shell service

# Standard Un*x authentication.
@include common-auth

# Disallow non-root logins when /etc/nologin exists.
account required        pam_nologin.so

# Uncomment and edit /etc/security/access.conf if you need to set complex
# access limits that are hard to express in sshd_config.
# account  required     pam_access.so

# Standard Un*x authorization.
@include common-account

# SELinux needs to be the first session rule.  This ensures that any
# lingering context has been cleared.  Without this it is possible that a
# module could execute code in the wrong domain.
session [success=ok ignore=ignore module_unknown=ignore default=bad]        pam_selinux.so close

# Set the loginuid process attribute.
session required        pam_loginuid.so

# Create a new session keyring.
session    optional     pam_keyinit.so force revoke

# Standard Un*x session setup and teardown.
@include common-session

# Print the message of the day upon successful login.
# This includes a dynamically generated part from /run/motd.dynamic
# and a static (admin-editable) part from /etc/motd.
session    optional     pam_motd.so  motd=/run/motd.dynamic noupdate
session    optional     pam_motd.so # [1]

# Print the status of the user's mailbox upon successful login.
session    optional     pam_mail.so standard noenv # [1]

# Set up user limits from /etc/security/limits.conf.
session required        pam_limits.so

# Read environment variables from /etc/environment and
# /etc/security/pam_env.conf.
session required        pam_env.so
# In Debian 4.0 (etch), locale-related environment variables were moved to
# /etc/default/locale, so read that as well.
session required        pam_env.so      user_readenv=1 envfile=/etc/default/locale

# SELinux needs to intervene at login time to ensure that the process starts
# in the proper default security context.  Only sessions which are intended
# to run in the user's context should be run after this.
session [success=ok ignore=ignore module_unknown=ignore default=bad]        pam_selinux.so open

# Standard Un*x password updating.
@include common-password
  • Please share all of the lines in the auth stack. It makes no sense that failed-login-notify.sh is firing on successful authentication – Andrew B Feb 14 '16 at 0:40
  • Sorry if that was unclear, I have another file called login-notify.sh that fires on successful authentication. failed-login-notify.sh is only firing when trying to use sudo and typing the wrong password but login-notify.sh will fire when logging in via ssh and using sudo – Matkey Feb 14 '16 at 1:30
  • Thanks. To confirm though, there are no auth lines above this? I need the whole picture. – Andrew B Feb 14 '16 at 1:36
  • Sorry, added all the lines in the file to make it clearer. – Matkey Feb 14 '16 at 1:41
  • Thanks. No line skips in /etc/pam.d/sshd either? (success=N) – Andrew B Feb 14 '16 at 1:44

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Browse other questions tagged or ask your own question.