On both Centos/Redhat 64-bit and SLES 64-bit, I started with a default "/configure --prefix=/usr" and the libduo and pkgconfig stuff ended up being installed in /usr/lib -- and login_duo ended up with a missing shared library at runtime. When I changed the configure to "./configure --prefix=/usr --libdir=/usr/lib64" then things worked. The README file should say a few words about this.

As far as I can see, login_duo doesn't clear environment variables before performing HTTPS requests. Have a look at these things in lib/https.c:

    if (!RAND_status()) {
            if ((p = getenv("RANDFILE")) != NULL) {
                    RAND_load_file(p, 8192);
            } else {
                    ctx->errstr = "No /dev/random, EGD, or $RANDFILE";
                    return (HTTPS_ERR_LIB);
            }
    }

and

    if ((p = getenv("http_proxy")) != NULL) {
            if (strstr(p, "://") != NULL) {
                    if (strncmp(p, "http://", 7) != 0) {
                            ctx->errstr = "http_proxy must be HTTP";
                            return (HTTPS_ERR_CLIENT);
                    }
                    p += 7;
            }
            p = strdup(p);

            if ((ctx->proxy = strchr(p, '@')) != NULL) {
                    *ctx->proxy++ = '\0';
                    ctx->proxy_auth = p;
            } else {
                    ctx->proxy = p;
            }
            strtok(ctx->proxy, "/");

            if ((ctx->proxy_port = strchr(ctx->proxy, ':')) != NULL) {
                    *ctx->proxy_port++ = '\0';
            } else {
                    ctx->proxy_port = "80";
            }
    }

This means that on systems without /dev/urandom, every user can cause duo_unix to read files in the context of the duo helper user and to then send data derived from these files to a user-specified host.

The pam_duo RPM generated by the spec file needs to generate and install the SELinux module on supported EL servers.

Hi,

This seems to work on EL6; no clue there. Sort of related to issue #70.

You need to open a port for the proxy. I guess, you may ONLY need a port for that proxy? Oh, yeah, that seems to be true.

So for my case, with a proxy on port 8000, I needed this:

require {
    type soundd_port_t;
    type sshd_t;
    class tcp_socket name_connect;
};

allow sshd_t soundd_port_t:tcp_socket name_connect;

Because in the byzantine world of SELinux soundd_port = port 8000. Your miles will vary dependy, and maybe people should just stick with http_port_t which covers tcp 80, 81, 443, 488, 8008, 8009, 8443, 9000. Who came up with 9000? That's no more crazy than 8000.

Hopefully there is a more general way to handle this, or perhaps it just needs to be documented for people trying to use proxies.

When logging in using ssh with pam_duo, we used to see the following behavior:

Authenticated with partial success.
Autopushing login request to phone...

At which point you'd see the confirmation request on your phone.

Now, we see the following:

Authenticated with partial success.

Notice that the autopushing login request message is missing until after the user logs in, then we see

Autopushing login request to phone...
Success. Logging you in...

I'd like to enable autopush on our systems, but it hangs for a long time and then just aborts when I've switched my phone to airplane mode (to simulate bad reception).

Could the autopush implementation be changed in the following way?

1. Send an autopush notification to my phone, but don't hang while waiting for the reply.
2. Show the usual prompt (1. Push, 2. Phone call, 3. SMS passcode) that allows me to use a passcode if everything else fails.
3. If the phone replies to the original autopush, stop waiting for user input and act according to the reply.
4. If the phone doesn't reply, do whatever the user chose from the prompt.

I'm currently working on an internal CLI tool that will eventually be open-sourced and one issue that I've encountered with Duo unix (and also encountered previously with other terminal 2fa solutions) is an elegant way to spawn non-interactive terminal commands that may require 2fa.

I'm going to use the tool I'm working on as an example. It performs a bunch of actions on a self-hosted git server protected by duo_unix. When a user doesn't have an active session and executes a command, the command will basically hang. There are two possible solutions here that I can think of but I want a better user experience. The first solution is to provide the user with instructions on how to put an ~/.autopush file in the home folder for their user on the authentication servers. This signals to duo to use the primary 2fa method for that user. The second approach is to spawn all commands that may require authentication with stdio inherited. This is also problematic for three reasons

• the moment you forward fds 0, 1 and 2 to the child process you lose the ability to intercept and parse the stdout and stderr from that process
• the user experience for your tool becomes noticeably worse because you expose all the noisy output from your child_process that you may want to suppress.
• you lose the ability to effectively parallelize tasks since all of them would be inheriting and working with the same file descriptors.

What I'd really like to see is:

• duo_unix detects when it is being run in a non-interactive terminal session and behaves more appropriately (perhaps there is an implicit autopush when detected)
• A way to effectively test tools that have to work with duo_unix. In the course of developing this CLI tool, it was impractical to create the circumstances that lead to the 2fa prompt more than once per day. This meant that it took me a lot longer to test out if any of my hypothesized workarounds worked as desired. The ability to view active sessions and terminate an active session (either via the web or programmatically would be nice for being able to create circumstances where I'll be prompted to log in again.

In the syslog output for login_duo or pam, I would like to know the method used for either success or failure, ie "Push", "Phone", or "SMS", with syslog output like:

login_duo: Successful Duo login via Push for 'joeblow' from '1.2.3.4'

or

sshd[2349]: Successful Duo login via SMS for 'joeblow' from 'somewhere.com'

Would this be possible in the next release please?

Now that I have systems with duo_unix deployed in a production environment and it all works, occasionally when ssh'ing to a server I do not get prompted by duo_unix to authenticate myself but get a shell prompt immediately.

I do have failmode set to "safe" so if there is some problem in the system or network I can still get in.

My problem is that I did not get any message in syslog (or on the screen when I ran duo_unix -d manually) when this problem is happening. I assume there is some service or network failure happening between my servers and duosecurity, but I do not know that.

Shouldn't all failures be logged?

In my shell I override the ssh(8) command with a Bash function that first copies my shell profiles to the target machines using rsync(1)-over-ssh and then executes the actual ssh command to log into the remote machine.

When I log into a Duo-enabled ssh server, this means I get prompted twice to log in each time.

But as a practical matter, this is not necessary if the token has not rotated between login attempts.

What do you think about the following feature? (It can be optional, of course.)

• Making pam_duo set the DUO_TOKEN environment variable to the most-recently-used token, if good
• Allowing the user to write the token stored in the environment variable to $HOME/.duo_token and delete it from her environment
• Making pam_duo attempt to read the token from $HOME/.duo_token (after ensuring the file is mode 0600), and, if still good, allowing the user to pass token validation without re-entering the token or pushing to the mobile device

There is a small amount of security risk in storing the token in the user's environment, but since it's rotated every 30 seconds, I think the risk is minimal.

I tried to create a Homebrew formula for duo_unix but ran into some issues, mostly around the fact that make install needs to run as root, which Homebrew doesn't like; a number of the post-compile tasks seem to get squirrelly.

Here's what i have so far: https://gist.github.com/1048092

Edit: formula works now (gist updated), but it still complains at the end with the error, Error: Failed to fix install names, which i think is related to installing as root.

On an Ubuntu 8.04 without the ca-certificates package,

Jul  1 11:13:12 xxx login_duo: Allowed Duo login for 'yyy' on failure: Problem with the SSL CA cert (path? access rights?)

This is sorta out of the bailiwick of autoconf, and to be honest, I have no idea how this system has been around this long without ca-certificates being installed, but it's probably worth mentioning somewhere. :-)

Between 1.8 and 1.9.6, a bunch of symbols got removed from libduo.3. Due to missing symbols, the library version (3) needs to be bumped:

MISSING: 1.9.6-1# _BIO_wait@Base 1.7
MISSING: 1.9.6-1# _duo_preauth@Base 1.7
MISSING: 1.9.6-1# _duo_prompt@Base 1.7
MISSING: 1.9.6-1# bson_append32@Base 1.5
MISSING: 1.9.6-1# bson_append64@Base 1.5
MISSING: 1.9.6-1# bson_append@Base 1.5
MISSING: 1.9.6-1# bson_append_binary@Base 1.5
MISSING: 1.9.6-1# bson_append_bool@Base 1.5
MISSING: 1.9.6-1# bson_append_bson@Base 1.5
MISSING: 1.9.6-1# bson_append_byte@Base 1.5
MISSING: 1.9.6-1# bson_append_code@Base 1.5
MISSING: 1.9.6-1# bson_append_code_w_scope@Base 1.5
MISSING: 1.9.6-1# bson_append_date@Base 1.5
MISSING: 1.9.6-1# bson_append_double@Base 1.5
MISSING: 1.9.6-1# bson_append_element@Base 1.5
MISSING: 1.9.6-1# bson_append_finish_object@Base 1.5
MISSING: 1.9.6-1# bson_append_int@Base 1.5
MISSING: 1.9.6-1# bson_append_long@Base 1.5
MISSING: 1.9.6-1# bson_append_new_oid@Base 1.5
MISSING: 1.9.6-1# bson_append_null@Base 1.5
MISSING: 1.9.6-1# bson_append_oid@Base 1.5
MISSING: 1.9.6-1# bson_append_regex@Base 1.5
MISSING: 1.9.6-1# bson_append_start_array@Base 1.5
MISSING: 1.9.6-1# bson_append_start_object@Base 1.5
MISSING: 1.9.6-1# bson_append_string@Base 1.5
MISSING: 1.9.6-1# bson_append_string_base@Base 1.5
MISSING: 1.9.6-1# bson_append_symbol@Base 1.5
MISSING: 1.9.6-1# bson_append_time_t@Base 1.5
MISSING: 1.9.6-1# bson_append_undefined@Base 1.5
MISSING: 1.9.6-1# bson_buffer_destroy@Base 1.5
MISSING: 1.9.6-1# bson_buffer_finish@Base 1.5
MISSING: 1.9.6-1# bson_buffer_init@Base 1.5
MISSING: 1.9.6-1# bson_copy@Base 1.5
MISSING: 1.9.6-1# bson_destroy@Base 1.5
MISSING: 1.9.6-1# bson_empty@Base 1.5
MISSING: 1.9.6-1# bson_ensure_space@Base 1.5
MISSING: 1.9.6-1# bson_fatal@Base 1.5
MISSING: 1.9.6-1# bson_fatal_msg@Base 1.5
MISSING: 1.9.6-1# bson_find@Base 1.5
MISSING: 1.9.6-1# bson_from_buffer@Base 1.5
MISSING: 1.9.6-1# bson_init@Base 1.5
MISSING: 1.9.6-1# bson_iterator_bin_data@Base 1.5
MISSING: 1.9.6-1# bson_iterator_bin_len@Base 1.5
MISSING: 1.9.6-1# bson_iterator_bin_type@Base 1.5
MISSING: 1.9.6-1# bson_iterator_bool@Base 1.5
MISSING: 1.9.6-1# bson_iterator_bool_raw@Base 1.5
MISSING: 1.9.6-1# bson_iterator_code@Base 1.5
MISSING: 1.9.6-1# bson_iterator_code_scope@Base 1.5
MISSING: 1.9.6-1# bson_iterator_date@Base 1.5
MISSING: 1.9.6-1# bson_iterator_double@Base 1.5
MISSING: 1.9.6-1# bson_iterator_double_raw@Base 1.5
MISSING: 1.9.6-1# bson_iterator_init@Base 1.5
MISSING: 1.9.6-1# bson_iterator_int@Base 1.5
MISSING: 1.9.6-1# bson_iterator_int_raw@Base 1.5
MISSING: 1.9.6-1# bson_iterator_key@Base 1.5
MISSING: 1.9.6-1# bson_iterator_long@Base 1.5
MISSING: 1.9.6-1# bson_iterator_long_raw@Base 1.5
MISSING: 1.9.6-1# bson_iterator_more@Base 1.5
MISSING: 1.9.6-1# bson_iterator_next@Base 1.5
MISSING: 1.9.6-1# bson_iterator_oid@Base 1.5
MISSING: 1.9.6-1# bson_iterator_regex@Base 1.5
MISSING: 1.9.6-1# bson_iterator_regex_opts@Base 1.5
MISSING: 1.9.6-1# bson_iterator_string@Base 1.5
MISSING: 1.9.6-1# bson_iterator_string_len@Base 1.5
MISSING: 1.9.6-1# bson_iterator_subiterator@Base 1.5
MISSING: 1.9.6-1# bson_iterator_subobject@Base 1.5
MISSING: 1.9.6-1# bson_iterator_time_t@Base 1.5
MISSING: 1.9.6-1# bson_iterator_type@Base 1.5
MISSING: 1.9.6-1# bson_iterator_value@Base 1.5
MISSING: 1.9.6-1# bson_malloc@Base 1.5
MISSING: 1.9.6-1# bson_numstr@Base 1.5
MISSING: 1.9.6-1# bson_oid_from_string@Base 1.5
MISSING: 1.9.6-1# bson_oid_gen@Base 1.5
MISSING: 1.9.6-1# bson_oid_generated_time@Base 1.5
MISSING: 1.9.6-1# bson_oid_to_string@Base 1.5
MISSING: 1.9.6-1# bson_print@Base 1.5
MISSING: 1.9.6-1# bson_print_raw@Base 1.5
MISSING: 1.9.6-1# bson_size@Base 1.5
MISSING: 1.9.6-1# ctx@Base 1.7
MISSING: 1.9.6-1# ga_free@Base 1.7
MISSING: 1.9.6-1# ga_init@Base 1.7
MISSING: 1.9.6-1# ga_match@Base 1.7
MISSING: 1.9.6-1# ga_match_pattern_list@Base 1.7
MISSING: 1.9.6-1# http_errno_description@Base 1.7
MISSING: 1.9.6-1# http_errno_name@Base 1.7
MISSING: 1.9.6-1# http_method_str@Base 1.7
MISSING: 1.9.6-1# http_parser_execute@Base 1.7
MISSING: 1.9.6-1# http_parser_init@Base 1.7
MISSING: 1.9.6-1# http_should_keep_alive@Base 1.7
MISSING: 1.9.6-1# https_close@Base 1.7
MISSING: 1.9.6-1# https_geterr@Base 1.7
MISSING: 1.9.6-1# https_init@Base 1.7
MISSING: 1.9.6-1# https_open@Base 1.7
MISSING: 1.9.6-1# https_recv@Base 1.7
MISSING: 1.9.6-1# https_send@Base 1.7
MISSING: 1.9.6-1# ini_parse@Base 1.5
MISSING: 1.9.6-1# initialBufferSize@Base 1.5
MISSING: 1.9.6-1# match_pattern@Base 1.7
MISSING: 1.9.6-1# match_pattern_list@Base 1.7
MISSING: 1.9.6-1# set_bson_err_handler@Base 1.5
MISSING: 1.9.6-1# strlcpy@Base 1.5
MISSING: 1.9.6-1# urlenc_decode@Base 1.5
MISSING: 1.9.6-1# urlenc_encode@Base 1.5

When setting http_proxy to http://username:[email protected] the username + password is not being sent to the proxy.

I changed the following line in https.c and proxy auth then worked for me:

https.c
line 344

BIO_puts(b64, ctx->proxy_auth);

changed to

BIO_write(b64, ctx->proxy_auth, strlen(ctx->proxy_auth));

Per the Linux PAM Module Writers Guide in chapter 5 it describes how modules should use syslog. Per this programming note all logging should be of facility-type LOG_AUTHPRIV. The PAM module provided with duo_unix does not log in this fashion, resulting in log output from this module not being properly logged with the rest of the PAM syslog output. Logging should be updated so that logging matches conventions of the PAM implementation.

Linux PAM Reference: http://linux-pam.org/Linux-PAM-html/mwg-see-programming-syslog.html

drop_privs only drops uid and gid, but not supplementary group IDs, I think. If I read the code correctly, this means that code might be running in the context of the DUO_PRIVSEP_USER with supplementary groups that grant access to critical areas of the system. (Maybe even to sudo if the user is in the wheel group or so? I have no idea whether sudo just checks the gids of a process or also checks whether the user is a member of the group...)

How about adding a line like this to the unprivileged auth child?

if (setgroups(0, NULL)) { die(...); }

This is a small script I wrote real quick to force two factor auth on systems that you don't have root access on. It doesn't rely on the mechanism from authorized_keys. This is done for 2 reasons.

1. I wanted two factor to kick in no matter what. Authorized_keys file only works when using a private key.
2. The command defined in authorized_keys can be overridden with a command specified from ssh when you connect.

Instead I take advantage of the file rc in the same folder. This file is ran right before the login shell is loaded. It also happens to run before any forced commands from the ssh command that the user loaded so it can't be bypassed easily. Last but not least it doesn't rely on the usage of private keys so it works on any login attempt.

Save the following in $HOME/.ssh/rc

$HOME/sbin/login_duo -c $HOME/etc/duo/login_duo.conf
if [ $? -ne 0 ] ; then echo "You are not authorized! Bye Bye!"; pkill -SIGHUP -t $SSH_TTY; fi

The first line just calls login_duo. Uses the config from the home folder.
The second line is a typical conditional. I don't know all the exit codes. Only tested for a typical approve/deny scenario. A non-zero exit code means that it wasn't approved so it echos a message and kills the session. This script does rely on pkill to be available which should be on most systems but if it doesn't you will have to substitute it. $SSH_TTY gets set to the current login terminal even before the shell kicks in. I tested this on NetBSD. And yes while I mention that Duo Security actually works on NetBSD as well.

Environment available before the login shell.
HOME, IFS, LOGNAME, MAIL, OPTIND, PATH, PS1, PS2, PS4, PWD, SHELL, SHLVL, SSH_CLIENT, SSH_CONNECTION, SSH_TTY, TERM, USER

The actual list might vary a bit for you but it should be similar.

The source code uses accept_env but the man page says accept_env_var. Which one should be correct for using DUO_PASSCODE env variable.

EDIT:
In either case pam complains that the option isn't valid... :(

I've attempted it to build duo_unix from the 1.5 tarball, and everything appeared okay -- full build output is here: https://gist.github.com/921319

However, I get the following error when attempting to test:

# login_duo echo AWESOME
login_duo: error while loading shared libraries: libduo.so.1: cannot open shared object file: No such file or directory

Here is some additional info about the system:

# uname -a
Linux XXX 2.6.35.4-x86_64-linode16 #1 SMP Mon Sep 20 16:03:34 UTC 2010 x86_64 GNU/Linux
# cat /etc/lsb-release 
DISTRIB_ID=Ubuntu
DISTRIB_RELEASE=10.04
DISTRIB_CODENAME=lucid
DISTRIB_DESCRIPTION="Ubuntu 10.04.1 LTS"
# dpkg -l | egrep 'openssl|libcurl|libpam'
ii  libcurl3                        7.19.7-1ubuntu1                                 Multi-protocol file transfer library (OpenSS
ii  libcurl3-gnutls                 7.19.7-1ubuntu1                                 Multi-protocol file transfer library (GnuTLS
ii  libcurl4-openssl-dev            7.19.7-1ubuntu1                                 Development files and documentation for libc
ii  libpam-modules                  1.1.1-2ubuntu5                                  Pluggable Authentication Modules for PAM
ii  libpam-runtime                  1.1.1-2ubuntu5                                  Runtime support for the PAM library
ii  libpam0g                        1.1.1-2ubuntu5                                  Pluggable Authentication Modules library
ii  libpam0g-dev                    1.1.1-2ubuntu5                                  Development files for PAM
ii  openssl                         0.9.8k-7ubuntu8.6                               Secure Socket Layer (SSL) binary and related
ii  openssl-blacklist               0.5-2                                           list of blacklisted OpenSSL RSA keys

Apologies if this issue tracker is a bad place for this type of support -- please let me know if there is a more appropriate forum.

Hi,

When trying to install the duo_unix 1.6 - I am getting this error:

duo_unix-1.6]# ./configure
checking for a BSD-compatible install... /usr/bin/install -c
checking whether build environment is sane... yes
checking for a thread-safe mkdir -p... /bin/mkdir -p
checking for gawk... gawk
checking whether make sets $(MAKE)... yes
checking whether to enable maintainer-specific portions of Makefiles... no
checking build system type... Invalid configuration i686-pc-linux-': machinei686-pc-linux' not recognized
configure: error: /bin/sh autotools/config.sub i686-pc-linux- failed

I would appreciate a tip on how to resolve this ?

Thanks

A quick test of a setup here with:

• test user set up with both iOS client and a hardware token (Yubikey).
• system runs CentOS 6.5 with duo_unix-1.9.11-0.i386 and /etc/pam.d/sshd set up to require duo authentication, configured with autopush.

When the phone is offline the login process fails to fall back to using a hardware token.

There should be some configurable timeout when using autopush so that the attempt is broken off if the client device does not respond within N seconds, and fall back to any other device available (in this case the Yubikey).

If testing with autopush off this works (i.e. select 1 for push or enter passcode), but having autopush and a timeout would cause a lot less friciton for users.

-A

Hello,

I'm building duo_unix for openSUSE/SLES via the OpenSUSE Build Service and the rpmlint checks which evaluate the packages is throwing the following warning for libduo.so.3.0.0. See the build log for the complete build output.

https://build.opensuse.org/package/live_build_log/home:deadpoint/duo_unix/openSUSE_13.1/x86_64

[ 14s] libduo3.x86_64: W: shared-lib-calls-exit /usr/lib64/libduo.so.3.0.0 exit@GLIBC_2.2.5
[ 14s] This library package calls exit() or _exit(), probably in a non-fork()
[ 14s] context. Doing so from a library is strongly discouraged - when a library
[ 14s] function calls exit(), it prevents the calling program from handling the
[ 14s] error, reporting it to the user, closing files properly, and cleaning up any
[ 14s] state that the program has. It is preferred for the library to return an
[ 14s] actual error code and let the calling program decide how to handle the
[ 14s] situation.

Unable to complete linking by ld for SmartOS/Duo_Unix-1.7 combination. It is running inside a zone.

System Details:

[root@bare /home/admin/MYDUO/duo_unix-1.7]# uname -a
SunOS bare.joyent.us 5.11 joyent_20110813T221858Z i86pc i386 i86pc Solaris

[root@bare /home/admin/MYDUO/duo_unix-1.7]# pkgin search openssl
openssl-0.9.8qnb3 = Secure Socket Layer and cryptographic library

Detailed Message for root cause of error

./configure

make clean all

....
/bin/sh ../libtool --tag=CC --mode=link gcc -g -O2 -Wall -D_FORTIFY_SOURCE=2 -fstack-protector -no-undefined -version-info 3:0:0 -o libduo.la -rpath /usr/local/lib bson.lo duo.lo groupaccess.lo http_parser.lo https.lo ini.lo match.lo urlenc.lo ../compat/libcompat.la -L/usr/lib -lssl -lcrypto -lnsl
libtool: link: gcc -shared -fPIC -DPIC -Wl,-z -Wl,text -Wl,-h -Wl,libduo.so.3 -o .libs/libduo.so.3.0.0 .libs/bson.o .libs/duo.o .libs/groupaccess.o .libs/http_parser.o .libs/https.o .libs/ini.o .libs/match.o .libs/urlenc.o -Wl,-z -Wl,allextract ../compat/.libs/libcompat.a -Wl,-z -Wl,defaultextract -L/usr/lib -lssl -lcrypto -lnsl -lc -O2

Undefined symbol ==> __stack_chk_fail_local
first referenced in file ==> .libs/bson.o (symbol scope specifies local binding)

ld: fatal: symbol referencing errors. No output written to .libs/libduo.so.3.0.0
collect2: ld returned 1 exit status
make[2]: *** [libduo.la] Error 1
make[2]: Leaving directory /home/admin/MYDUO/duo_unix-1.7/lib' make[1]: *** [all-recursive] Error 1 make[1]: Leaving directory/home/admin/MYDUO/duo_unix-1.7'
make: *** [all] Error 2

Any clue on possible solution? Thanks!

Cheers!
Michael Leow

It's unnecessary to make this helper setuid root. Instead, you could split it into two executables: The first one is invoked as an ssh forced command or so and does not have anything like a setuid flag. To check whether the request is valid, it invokes a second binary – and that binary is setuid DUO_PRIVSEP_USER.

It would be ideal for login_duo to display the motd after the login request is verified.

The accept_env_factor option should work with PAM, just like it does with login_duo.

--with-pam doesn't respect --prefix path

libtool: install: install -o root -g wheel -m 555 -s .libs/login_duo /usr/loca/sbin/login_duo
<snip>
libtool: install: /usr/bin/install -c -o root -g wheel .libs/pam_duo.so /usr/lib/pam_duo.so

When compiling on Solaris 10/amd64/Solaris Studio compiler, the configure script does not include "-lnsl -lsocket" and both are required to successfully link the binary.

It would be great if configure could do this automatically. As a workaround, simply defining this works:

LIBS="-lnsl -lsocket"

This is against version 1.9.13.

I was attempting to do a user-level install (I don't have root on one of the servers) and I found that some libtool and install-sh entries were not respecting the prefix at all. Checking the makefiles I found they were using DESTDIR but this isn't defined at all. I don't know enough about makefiles to fix this myself in the input files so I'm just letting you know. I can edit the Makefile after the fact though.

I am attempting to set up Duo TFA for a VPS with two interfaces, eth0, which is a direct internet connection and tap_vpn, which is a virtual network adapter for VPN purposes and gets internet from eth0 (iptables forwarding). My problem is caused by duo_unix using both eth0 and tap_vpn to communicate to the Duo Security servers, causing issues with push notification spam. Killing the tap_vpn interface stops the spam, but this is not ideal.

I'm not sure what the exact cause of the push notification spam (simply connecting to the ssh server when either login_duo or pam_duo is setup is enough to cause push spam until the Duo account is locked out)

I just spent a few hours trying to debug login_duo failing silently because of what turned out to be a firewall issue. There was no error message from login_duo at all; it just exited, silently. Worse still, it permitted all logins. I would much rather the system fail in a secure way than an insecure way. I already have a backchannel for logging into the system when duo prevents other logins (and in fact used this already this evening in the course of debugging).

configure doesn't check for openssl-devel, but without the openssl headers, make will fail to compile.

This is on a fedora 14 system.

It'd be great if (on a Mac), someone could run brew install duo_unix to install Duo Unix. Then brew doctor would stop yelling at me about manually added files to /usr/local/lib.

I hear @mstanislav is a packaging wizard... :)

Please consider the following changes to syslogging in pam_duo.c:

i: diff -c pam_duo.c.orig pam_duo.c
*** pam_duo.c.orig Mon Jun 25 11:06:09 2012
--- pam_duo.c Mon Jun 25 11:07:12 2012

*** 326,332 ****
code = duo_login(duo, user, ip, flags,
cfg.pushinfo ? cmd : NULL);
if (code == DUO_FAIL) {
! _log(LOG_WARNING, "Failed Duo login",
user, ip, duo_geterr(duo));
if ((flags & DUO_FLAG_SYNC) == 0) {
pam_info(pamh, "%s", "");
--- 326,332 ----
code = duo_login(duo, user, ip, flags,
cfg.pushinfo ? cmd : NULL);
if (code == DUO_FAIL) {
! _log(LOG_WARNING, "Failed PAM Duo login",
user, ip, duo_geterr(duo));
if ((flags & DUO_FLAG_SYNC) == 0) {
pam_info(pamh, "%s", "");

*** 337,361 ****
/* Terminal conditions _/
if (code == DUO_OK) {
if ((p = duo_geterr(duo)) != NULL) {
! _log(LOG_WARNING, "Skipped Duo login",
user, ip, p);
} else {
! _log(LOG_INFO, "Successful Duo login",
user, ip, NULL);
}
pam_err = PAM_SUCCESS;
} else if (code == DUO_ABORT) {
! _log(LOG_WARNING, "Aborted Duo login",
user, ip, duo_geterr(duo));
pam_err = PAM_ABORT;
} else if (cfg.failmode == DUO_FAIL_SAFE &&
(code == DUO_CONN_ERROR ||
code == DUO_CLIENT_ERROR || code == DUO_SERVER_ERROR)) {
! _log(LOG_WARNING, "Failsafe Duo login",
user, ip, duo_geterr(duo));
pam_err = PAM_SUCCESS;
} else {
! log(LOG_ERR, "Error in Duo login",
user, ip, duo_geterr(duo));
pam_err = PAM_SERVICE_ERR;
}
--- 337,361 ----
/ Terminal conditions */
if (code == DUO_OK) {
if ((p = duo_geterr(duo)) != NULL) {
! _log(LOG_WARNING, "Skipped PAM Duo login",
user, ip, p);
} else {
! _log(LOG_INFO, "Successful PAM Duo login",
user, ip, NULL);
}
pam_err = PAM_SUCCESS;
} else if (code == DUO_ABORT) {
! _log(LOG_WARNING, "Aborted PAM Duo login",
user, ip, duo_geterr(duo));
pam_err = PAM_ABORT;
} else if (cfg.failmode == DUO_FAIL_SAFE &&
(code == DUO_CONN_ERROR ||
code == DUO_CLIENT_ERROR || code == DUO_SERVER_ERROR)) {
! _log(LOG_WARNING, "Failsafe PAM Duo login",
user, ip, duo_geterr(duo));
pam_err = PAM_SUCCESS;
} else {
! _log(LOG_ERR, "Error in PAM Duo login",
user, ip, duo_geterr(duo));
pam_err = PAM_SERVICE_ERR;
}

All I did was add "PAM" before "Duo login" in the syslog messages. This tells me that pam_duo was used as the authentication method instead of login_duo. I am testing both and I don't want to guess as to which got used.

The change above also impacts the tests/pam_duo-[1-4].t files, which have to be changed like so:

i: diff -c pam_duo-1.t.orig pam_duo-1.t
*** pam_duo-1.t.orig Mon Jun 25 11:11:50 2012
--- pam_duo-1.t Mon Jun 25 11:11:59 2012

*** 1,7 ****
mockduo down

$ ${TESTDIR}/testpam.py -d -c ${TESTDIR}/confs/duo.conf -f whatever true

! [4] Failsafe Duo login for 'whatever': Couldn't connect to localhost:4443: Connection refused

down and fail secure
$ ${TESTDIR}/testpam.py -d -c ${TESTDIR}/confs/mockduo_failsecure.conf -f whatever true
--- 1,7 ----
mockduo down

$ ${TESTDIR}/testpam.py -d -c ${TESTDIR}/confs/duo.conf -f whatever true

! [4] Failsafe PAM Duo login for 'whatever': Couldn't connect to localhost:4443: Connection refused

down and fail secure
$ ${TESTDIR}/testpam.py -d -c ${TESTDIR}/confs/mockduo_failsecure.conf -f whatever true

I did the mods about against files from duosecurity-duo_unix-4c396e7, aka "pre-release 1.9". Thanks.

On an Ubuntu 8.04 system, libduo.so.1 cannot be found until ldconfig is run:

$ /usr/local/sbin/login_duo 
/usr/local/sbin/login_duo: error while loading shared libraries: libduo.so.1: cannot open shared object file: No such file or directory
$ sudo ldconfig -v
$ /usr/local/sbin/login_duo 
Duo login for ...

This is with duo_unix-1.6 tarball edition. -rt

If ikey/skey are missing, login_duo will force a lockout situation rather than gracefully failing the multi-factor authentication.

kryptobsd:~ mstanislav$ ssh manage Missing ikey or skey in /etc/duo/login_duo.conf Connection to manage.xyz.com closed.

This situations exists even when failmode is set to safe (implicitly or explicitly).

Hi guys,

Every since enabling 2FA with pam_duo, xrdp has troubling logging into a session. I tried to edit the /etc/pam.d/sesman file from:

@include common-auth
@include common-account
@include common-session
@include common-password

to:

@includecommon-auth

@include common-account

@include common-session

@include common-password

auth [success=1 default=ignore] pam_duo.so

But it still fails login and nothing is pushed to my phone for authentication. Any idea how to get it working? @akgood @kra @dugsong

Thanks

Hi again,

I'm trying to add the duo_unix package source to my source list, I know it doesn't say it's specifically tested against ARM devices but works just fine (on my Rpi). Only problem is doesn't want to play nice with apt-get update, it throws error:

Unable to find expected entry 'main/binary-armhf/Packages'

I got around the error message by adding "deb [arch=amd64]" to the source list as such:

deb [arch=amd64] http://pkg.duosecurity.com/Debian jessie main

but it still can't find the duo_unix package when issuing "apt-get install duo-unix" it returns:

Unable to locate package duo-unix

Any idea for a workaround till ARM is officially supported?

@kra @akgood @dugsong

Thanks

Working on a FreeBSD 10.3-RELEASE, I am unable to authenticate using pam_duo when the duo package is built against LibreSSL using OPENSSL_PORT=security/libressl and WITH_OPENSSL_PORT=yes in make.conf. Switching to a version with openssl and making no other system configuration changes results in a successful authentication. This is, /etc/pam.d/sshd is correct, and have set AuthenticationMethods publickey,keyboard-interactive for the given group. If I can provide more information than what is below, I'd be happy to help. The debug is enabled on pam_duo for both sessions below.

With LibreSSL

[root@sh2 ~]$ ldd /usr/local/lib/libduo.so
/usr/local/lib/libduo.so:
        libssl.so.38 => /usr/local/lib/libssl.so.38 (0x801611000)
        libcrypto.so.37 => /usr/local/lib/libcrypto.so.37 (0x801870000)
        libc.so.7 => /lib/libc.so.7 (0x800821000)

[root@sh2 ~]$ ldd /usr/local/lib/security/pam_duo.so
/usr/local/lib/security/pam_duo.so:
        libduo.so.3 => /usr/local/lib/libduo.so.3 (0x801603000)
        libssl.so.38 => /usr/local/lib/libssl.so.38 (0x801814000)
        libcrypto.so.37 => /usr/local/lib/libcrypto.so.37 (0x801a73000)
        libpam.so.5 => /usr/lib/libpam.so.5 (0x801e6f000)
        libc.so.7 => /lib/libc.so.7 (0x800821000)

Jun  2 05:21:37 sh2 sshd[51525]: in openpam_dispatch(): calling pam_sm_authenticate() in /usr/local/lib/security/pam_duo.so
Jun  2 05:21:37 sh2 sshd[51525]: in pam_get_user(): entering
Jun  2 05:21:37 sh2 sshd[51525]: in pam_get_item(): entering: PAM_USER
Jun  2 05:21:37 sh2 sshd[51525]: in pam_get_item(): returning PAM_SUCCESS
Jun  2 05:21:37 sh2 sshd[51525]: in pam_get_user(): returning PAM_SUCCESS
Jun  2 05:21:37 sh2 sshd[51525]: in pam_get_item(): entering: PAM_SERVICE
Jun  2 05:21:37 sh2 sshd[51525]: in pam_get_item(): returning PAM_SUCCESS
Jun  2 05:21:37 sh2 sshd[51525]: in pam_get_item(): entering: PAM_RHOST
Jun  2 05:21:37 sh2 sshd[51525]: in pam_get_item(): returning PAM_SUCCESS
Jun  2 05:21:37 sh2 kernel: pid 51525 (sshd), uid 0: exited on signal 11
Jun  2 05:21:37 sh2 sshd[51523]: Connection closed by 2001:470:f:f:f:f:f:f port 49378 [preauth]

With OpenSSL

[root@sh2 ~]$ ldd /usr/local/lib/libduo.so
/usr/local/lib/libduo.so:
        libssl.so.8 => /usr/local/lib/libssl.so.8 (0x801611000)
        libcrypto.so.8 => /usr/local/lib/libcrypto.so.8 (0x801884000)
        libc.so.7 => /lib/libc.so.7 (0x800821000)
        libthr.so.3 => /lib/libthr.so.3 (0x801c91000)

[root@sh2 ~]$ ldd /usr/local/lib/security/pam_duo.so
/usr/local/lib/security/pam_duo.so:
        libduo.so.3 => /usr/local/lib/libduo.so.3 (0x801603000)
        libssl.so.8 => /usr/local/lib/libssl.so.8 (0x801814000)
        libcrypto.so.8 => /usr/local/lib/libcrypto.so.8 (0x801a87000)
        libpam.so.5 => /usr/lib/libpam.so.5 (0x801e94000)
        libc.so.7 => /lib/libc.so.7 (0x800821000)
        libthr.so.3 => /lib/libthr.so.3 (0x8020a0000)

Jun  2 05:19:06 sh2 sshd[51286]: in openpam_dispatch(): calling pam_sm_authenticate() in /usr/local/lib/security/pam_duo.so
Jun  2 05:19:06 sh2 sshd[51286]: in pam_get_user(): entering
Jun  2 05:19:06 sh2 sshd[51286]: in pam_get_item(): entering: PAM_USER
Jun  2 05:19:06 sh2 sshd[51286]: in pam_get_item(): returning PAM_SUCCESS
Jun  2 05:19:06 sh2 sshd[51286]: in pam_get_user(): returning PAM_SUCCESS
Jun  2 05:19:06 sh2 sshd[51286]: in pam_get_item(): entering: PAM_SERVICE
Jun  2 05:19:06 sh2 sshd[51286]: in pam_get_item(): returning PAM_SUCCESS
Jun  2 05:19:06 sh2 sshd[51286]: in pam_get_item(): entering: PAM_RHOST
Jun  2 05:19:06 sh2 sshd[51286]: in pam_get_item(): returning PAM_SUCCESS
Jun  2 05:19:06 sh2 sshd[51286]: in pam_vprompt(): entering
Jun  2 05:19:06 sh2 sshd[51286]: in pam_get_item(): entering: PAM_CONV
Jun  2 05:19:06 sh2 sshd[51286]: in pam_get_item(): returning PAM_SUCCESS
Jun  2 05:19:11 sh2 sshd[51286]: in pam_vprompt(): returning PAM_SUCCESS
Jun  2 05:19:11 sh2 sshd[51286]: in pam_vprompt(): entering
Jun  2 05:19:11 sh2 sshd[51286]: in pam_get_item(): entering: PAM_CONV
Jun  2 05:19:11 sh2 sshd[51286]: in pam_get_item(): returning PAM_SUCCESS
Jun  2 05:19:11 sh2 sshd[51286]: in pam_vprompt(): returning PAM_SUCCESS
Jun  2 05:19:11 sh2 sshd[51286]: in openpam_dispatch(): /usr/local/lib/security/pam_duo.so: pam_sm_authenticate(): success
Jun  2 05:19:11 sh2 sshd[51284]: Accepted keyboard-interactive/pam for xaque208 from 2001:470:f:f:f:f:f:f port 49372 ssh2

This is more of a ticket that is informational here but if anyone has any input to the security implications let me know.

I have a VPS that I manage remote. My host gives me console access which appears as a local connection when I use it. I also have SSH. When I implemented Duo Unix 2 things kinda got to me.

1. I had to go through two factor every time I ran sudo
2. I had to do the same regardless if I authenticated locally or remote. Even as root.

I know the first is being addressed via another ticket but the second I wanted to take care of.

I did some digging and kinda figured out how pam_access works and after managing to lock myself out twice (thank goodness for host rescue mode) I got it figured out.

This is for Ubuntu 12.04.3 but you can probably apply it elsewhere. It is very important that you already have a root session active and do not close it until you test your changes otherwise you might lock yourself out. It is also recommended to temporarily secure another way of getting to the server configuration files (editing them) in case you do manage to lock yourself out like I did.

Pam common-auth as per the documentation

# here are the per-package modules (the "Primary" block)
auth    requisite                       pam_unix.so nullok_secure
# Duo Security
auth    [success=1 default=ignore]      pam_duo.so
# here's the fallback if no module succeeds
auth    requisite                       pam_deny.so

Now I add "auth [success=2 default=ignore] pam_access.so accessfile=/etc/security/access-local.conf" right before the pam_duo line.

# here are the per-package modules (the "Primary" block)
auth    requisite                       pam_unix.so nullok_secure
# Duo Security -- set to skip if auth is local
auth    [success=2 default=ignore]      pam_access.so accessfile=/etc/security/access-local.conf
auth    [success=1 default=ignore]      pam_duo.so
# here's the fallback if no module succeeds
auth    requisite                       pam_deny.so

success=2 means to skip the next 2 lines if succeed.

Contents of access-local.conf

+ : ALL : LOCAL
- : ALL : ALL

Note: This bypasses it on sudo as well as local console. This is because sudo appears to be a local connection just like console.

Without this, "dash" (as /bin/sh) will totally lose its mind.

--- duo-unix-1.7.orig/tests/groups_preload.c
+++ duo-unix-1.7/tests/groups_preload.c
@@ -12,11 +12,11 @@
#include <unistd.h>

static struct passwd _passwd[5] = {

•    { "user1", NULL, 1000, 1000, .pw_shell = "/bin/sh" },
  

•    { "user2", NULL, 1001, 100, .pw_shell = "/bin/sh" },
  

•    { "admin1", NULL, 1002, 10, .pw_shell = "/bin/sh" },
  

•    { "admin2", NULL, 1003, 1003, .pw_shell = "/bin/sh" },
  

•    { "weirdo", NULL, 1004, 1004, .pw_shell = "/bin/sh" },
  

•    { "user1", "*", 1000, 1000, .pw_gecos = "gecos", .pw_dir = "/", .pw_shell = "/bin/sh" },
  

•    { "user2", "*", 1001, 100, .pw_gecos = "gecos", .pw_dir = "/", .pw_shell = "/bin/sh" },
  

•    { "admin1", "*", 1002, 10, .pw_gecos = "gecos", .pw_dir = "/", .pw_shell = "/bin/sh" },
  

•    { "admin2", "*", 1003, 1003, .pw_gecos = "gecos", .pw_dir = "/", .pw_shell = "/bin/sh" },
  

•    { "weirdo", "*", 1004, 1004, .pw_gecos = "gecos", .pw_dir = "/", .pw_shell = "/bin/sh" },
  

  };

  /* Supplemental groups */

Using Duo with a system like Ansible that makes many SSH connections is currently really painful. You can use the ControlMaster ssh config to avoid having to reopen lots of SSH connections, but because of ForceCommand, you have to authorize each one separately.

The SSH_CLIENT environment variable should uniquely identify a single SSH control connection, which would make it possible to only authenticate once. If the control connection gets dropped, then the user would need to reauthenticate.

I'm building duo_unix for openSUSE/SLES via the OpenSUSE Build Service and the rpmlint checks which evaluate the packages is throwing the following warning for /usr/sbin/login_duo. See the link to the build log for the complete build output.

https://build.opensuse.org/package/live_build_log/home:deadpoint/duo_unix/openSUSE_13.1/x86_64

[ 14s] duo_unix.x86_64: W: missing-call-to-setgroups-before-setuid /usr/sbin/login_duo
[ 14s] This executable is calling setuid and setgid without setgroups or initgroups.
[ 14s] There is a high probability this mean it didn't relinquish all groups, and
[ 14s] this would be a potential security issue to be fixed. Seek POS36-C on the web
[ 14s] for details about the problem.

The README file should give a few words of warning and explanation as to why /usr/sbin/login_duo is setuid. I am always suspicious of setuid programs.

Because of System Integrity Protection in OS X 10.11, login_duo needs to be installed in /usr/local instead of /usr. Changing the prefix flag on configure seems to work: the binary is installed in /usr/local/bin, and libduo is installed in /usr/local/lib.

But when when you try to run it, it says

dyld: Library not loaded: /usr/lib/libduo.3.dylib
  Referenced from: /usr/local/sbin/./login_duo
  Reason: image not found
Trace/BPT trap: 5

It looks to me like either:

(a) the path to libduo is hardcoded somewhere, or
(b) the dynamic linker isn't getting the memo

Relatedly, once this is fixed, the Duo Unix docs should be updated to reflect needing to install in /usr/local on OS X.

Thanks!

Even with the policy installed the duo_pam will fail to connect to Duo. In the audit log I see:

type=AVC msg=audit(1467902419.111:92031): avc: denied { name_connect } for pid=21571 comm="login" dest=443 scontext=system_u:system_r:local_login_t:s0-s0:c0.c1023 tcontext=system_u:object_r:http_port_t:s0 tclass=tcp_socket

Fix:
setsebool -P authlogin_yubikey=1

Index: duo-unix-1.7/login_duo/login_duo.8

--- duo-unix-1.7.orig/login_duo/login_duo.8 2011-07-14 18:26:47.000000000 -0700
+++ duo-unix-1.7/login_duo/login_duo.8 2011-09-02 13:27:48.936872449 -0700
@@ -43,7 +43,7 @@
or
.Ev SSH_ORIGINAL_COMMAND
environment variable is specified, it will be executed via the user's
-shell with a -c option.
+shell with a -c option.
.Sh CONFIGURATION
The INI-format configuration file must have a
.Dq Li duo
@@ -128,9 +128,9 @@
.Pa ~root/.ssh/authorized_keys :
.Pp
.Bd -literal -offset 8n
-command="/usr/local/sbin/login_duo -f alice"
+command="/usr/local/sbin/login_duo -f alice"
ssh-rsa AAAAB2...19Q== [email protected]
-command="/usr/local/sbin/login_duo -f bob"
+command="/usr/local/sbin/login_duo -f bob"
ssh-dss AAAAC3...51R== [email protected]
.Ed
.Pp

it's possible that the "sshd" user will not exist in the build environment, so do not require it be present.

configure.ac:

-if id "$DUO_PRIVSEP_USER" >/dev/null 2>&1; then

• AC_MSG_NOTICE([Found privilege separation user "$DUO_PRIVSEP_USER"])
  -else
• DUO_PRIVSEP_USER="nobody"
• AC_MSG_NOTICE([Using privilege separation user "nobody"])
  -fi
  +AC_MSG_NOTICE([Using privilege separation user "$DUO_PRIVSEP_USER"])

When autopush is set if the push fails it doesn't fallback to using a phone method. Instead it just times out and denies the connection. Am I doing something wrong or missing something?

auth    requisite                       pam_unix.so nullok_secure
# Duo Security
auth    [success=1 default=ignore]      pam_duo.so
# here's the fallback if no module succeeds
auth    requisite                       pam_deny.so

This is on ubuntu 12.04.3.

[duo]
; Duo integration key
ikey = removed
; Duo secret key
skey = removed
; Duo API host
host = removed
; Send command for Duo Push authentication
pushinfo = yes
; AutoPush Enabled :p
autopush = yes
; Let's be more verbose now...
pushinfo = yes
; Limit prompts to 1 (otherwise I need to deny 2 more times...)
prompts = 2
; Allow overriding via DUO_PASSCODE env var...
;need to figure out how to make this work over ssh
;accept_env_factor = yes

EDIT: Oops... forgot to remove sensitive parts of the config...

When compiling duo_unix under Solaris 10 with the Solaris Studio compiler on amd64, a line needs to be changed. Samba had the same issue as reported at https://bugzilla.samba.org/show_bug.cgi?id=3159

ifndef VA_COPY

if defined HAVE_VA_COPY || defined va_copy

define VA_COPY(dest, src) va_copy(dest, src)

This is for version 1.9.13, compat/asprintf.c