Cfxtrjtrk

I'm currently using the pam plugin to authenticate openvpn clients. It is working fine. I'm using duplicate certificates but need to do subsequent checks on the host - a home-brew Pulse Secure hostchecker.

I've tried client-connect, up, etc but it's not working. I might be going about it all wrong. Both client-connect and up give me:

WARNING: Failed running command (): external program exited with error status: 1

The script I want to send to the client looks for the existence of a 'secret' file. The real world implementation will look for 10 files but I wanted to keep it simple. In conclusion, I need to authenticate AND look for this file in order to allow a connection. Ideally the client gets a message like "Not an approved platform.". Is this possible when I can't have users modify their ovpn file?

hostcheck.sh (777 permissions)

cat hostcheck.sh

#!/bin/sh



if [ -f /etc/secretfile ] ; then 

    exit 0

else

    exit 1

fi



exit 1

server.conf

duplicate-cn

plugin /usr/lib64/openvpn/plugins/openvpn-plugin-auth-pam.so login

#auth-user-pass-verify /etc/openvpn/hostcheck.sh via-file

script-security 2 

#client-connect /etc/openvpn/hostcheck.sh

up /etc/openvpn/hostcheck.sh

username-as-common-name

#tmp-dir /dev/shm

tmp-dir /tmp

First, have you tried running the script from the command line? Does it return exit 1? Have you tried debugging your if statement? Does /etc/secretfile exist? If it doesn't, the script is doing what you're asking it to do. What are the permissions for the secretfile? If the user can't access it, then it may not "exist" to them.

Lock a user account via expiry

Instead of putting the file there, or removing it, could you just lock the account?

Lock the account when you don't want the user to access the machine:

usermod username -e 1999-01-01

When you want to allow access, unlock the account:

usermod username -e

Here, we use something native to Linux authentication (vs our own, custom scripts) to solve the problem, which should help prevent additional security risks. You could shiv this in as you described if you really wanted or needed to do so. For example, lock/unlock the account, using a cron job, or by polling for the files, vs complicating auth upon connection.

Restrict via blacklist/whitelist groups in pam

If you don't want users accessing the entire system, vs restricting individual users, you have other options, such as disabling SSH entirely, limiting SSH connection to a whitelist CIDR block, or most simply and in-line with your goals, using pam against a specific group.

/etc/pam.d/system-auth

auth required pam_listfile.so onerr=fail item=group sense=allow file=/etc/login.group.allowed

/etc/login.group.allowed

wheel

sudo

In this example, we only allow users in wheel or sudo to login. This will allow you to disable login to most users, while letting some admins access, or revoke all access if you so choose. You'll want to make sure this is owned by root and has something like 644 permissions to prevent unauthorized writes (modeled after /etc/password permissions).

Use two-factor, one-time passwords (OTP) in pam

This is just a cool, alternative that could help restrict access based on a list of users with access to OTP secrets. The pam_oath module is easy to set up, and supports FOSS clients, such as Authenticator. This example shows user-based OTP, but can be adjusted for groups, similar to the previous example. You'll need oath-toolkit and want qrencode.

touch /etc/users.oath

chown 600 /etc/users.oath # Will contain sensitive information

vim /etc/pam.d/sshd

#%PAM-1.0

#auth     required  pam_securetty.so     #disable remote root

#auth      include   system-remote-login

auth      required  pam_oath.so usersfile=/etc/users.oath window=30 digits=6

account   include   system-remote-login

password  include   system-remote-login

session   include   system-remote-login

With each user:

USER=myusername

SECRET=$(head -10 /dev/urandom | sha512sum | cut -b 1-30)

echo "HOTP/T30/6 ${USER} - ${SECRET}" >> /etc/users.oauth

QR_SECRET=$(oauthtool -v -d6 ${SECRET} | grep "Base32 secret" | awk '{print $3}')

qrencode -o ${USER}-OTP-secret.png $QR_SECRET

This will only allow key-based authentication, followed by the requirement of entering the one-time password at login. There are command line OTP generators, but typically QR codes are used bring in the credentials. The SECRET and QR_SECRET and resulting image file should all be treated as confidential and ultimately be deleted after setting up the OTP client.