cancel
Showing results for 
Search instead for 
Did you mean: 
cancel
416
Views
0
Helpful
1
Replies

Duo authentication failing on Debian 11

chown
Level 1
Level 1

I've ran into this a few times now and have followed the installation instructions, but it still happens:

 

root@gateway:/var/log# cat /etc/ssh/sshd_config

# $OpenBSD: sshd_config,v 1.103 2018/04/09 20:41:22 tj Exp $

# This is the sshd server system-wide configuration file. See

# sshd_config(5) for more information.

# This sshd was compiled with PATH=/usr/bin:/bin:/usr/sbin:/sbin

# The strategy used for options in the default sshd_config shipped with

# OpenSSH is to specify options with their default value where

# possible, but leave them commented. Uncommented options override the

# default value.

Include /etc/ssh/sshd_config.d/*.conf

Port 22

#AddressFamily any

#ListenAddress 0.0.0.0

#ListenAddress ::

#HostKey /etc/ssh/ssh_host_rsa_key

#HostKey /etc/ssh/ssh_host_ecdsa_key

#HostKey /etc/ssh/ssh_host_ed25519_key

# Ciphers and keying

#RekeyLimit default none

# Logging

#SyslogFacility AUTH

#LogLevel INFO

# Authentication:

LoginGraceTime 30s

PermitRootLogin no

#StrictModes yes

MaxAuthTries 5

#MaxSessions 10

PubkeyAuthentication yes

PasswordAuthentication no

AuthenticationMethods publickey,keyboard-interactive

# Expect .ssh/authorized_keys2 to be disregarded by default in future.

AuthorizedKeysFile .ssh/authorized_keys .ssh/authorized_keys2

#AuthorizedPrincipalsFile none

#AuthorizedKeysCommand none

#AuthorizedKeysCommandUser nobody

# For this to work you will also need host keys in /etc/ssh/ssh_known_hosts

#HostbasedAuthentication no

# Change to yes if you don't trust ~/.ssh/known_hosts for

# HostbasedAuthentication

#IgnoreUserKnownHosts no

# Don't read the user's ~/.rhosts and ~/.shosts files

#IgnoreRhosts yes

# To disable tunneled clear text passwords, change to no here!

#PasswordAuthentication yes

#PermitEmptyPasswords no

# Change to yes to enable challenge-response passwords (beware issues with

# some PAM modules and threads)

ChallengeResponseAuthentication yes

# Kerberos options

#KerberosAuthentication no

#KerberosOrLocalPasswd yes

#KerberosTicketCleanup yes

#KerberosGetAFSToken no

# GSSAPI options

GSSAPIAuthentication yes

GSSAPICleanupCredentials no

#GSSAPIStrictAcceptorCheck yes

#GSSAPIKeyExchange no

# Set this to 'yes' to enable PAM authentication, account processing,

# and session processing. If this is enabled, PAM authentication will

# be allowed through the ChallengeResponseAuthentication and

# PasswordAuthentication. Depending on your PAM configuration,

# PAM authentication via ChallengeResponseAuthentication may bypass

# the setting of "PermitRootLogin without-password".

# If you just want the PAM account and session checks to run without

# PAM authentication, then enable this but set PasswordAuthentication

# and ChallengeResponseAuthentication to 'no'.

UsePAM yes

#AllowAgentForwarding yes

#AllowTcpForwarding yes

#GatewayPorts no

X11Forwarding yes

#X11DisplayOffset 10

#X11UseLocalhost yes

#PermitTTY yes

PrintMotd no

#PrintLastLog yes

#TCPKeepAlive yes

#PermitUserEnvironment no

#Compression delayed

#ClientAliveInterval 0

#ClientAliveCountMax 3

UseDNS no

#PidFile /var/run/sshd.pid

#MaxStartups 10:30:100

#PermitTunnel no

#ChrootDirectory none

#VersionAddendum none

# no default banner path

#Banner none

# Allow client to pass locale environment variables

AcceptEnv LANG LC_*

# override default of no subsystems

Subsystem sftp /usr/lib/openssh/sftp-server

# Example of overriding settings on a per-user basis

#Match User anoncvs

# X11Forwarding no

# AllowTcpForwarding no

# PermitTTY no

# ForceCommand cvs server

Match User guacamole

AuthenticationMethods publickey

root@gateway:/var/log# cat /etc/pam.d/common-auth

#

# /etc/pam.d/common-auth - authentication settings common to all services

#

# This file is included from other service-specific PAM config files,

# and should contain a list of the authentication modules that define

# the central authentication scheme for use on the system

# (e.g., /etc/shadow, LDAP, Kerberos, etc.). The default is to use the

# traditional Unix authentication mechanisms.

#

# As of pam 1.0.1-6, this file is managed by pam-auth-update by default.

# To take advantage of this, it is recommended that you configure any

# local modules either before or after the default block, and use

# pam-auth-update to manage selection of other modules. See

# pam-auth-update(8) for details.

# here are the per-package modules (the "Primary" block)

auth [success=1 default=ignore] pam_unix.so nullok

#auth [success=2 default=ignore] pam_unix.so nullok

auth [success=2 default=ignore] pam_unix.so nullok

auth sufficient /lib64/security/pam_duo.so

# here's the fallback if no module succeeds

auth requisite pam_deny.so

# 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)

# end of pam-auth-update config

root@gateway:/var/log# cat /etc/pam.d/sshd

# PAM configuration for the Secure Shell service

# Standard Un*x authentication.

#@include common-auth

auth required pam_unix.so

auth sufficient /lib64/security/pam_duo.so

auth required pam_deny.so

# 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.

u/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.

u/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

session optional pam_motd.so noupdate

# 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 # [1]

# 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.

u/include common-password

 

If I try and connect using an SSH key it prompts me for keyboard input and there is no password set for the user. If I enter anything it prompts for Duo, but doesn't let me login. Any idea what is happening? I tried to e-mail Duo support and they weren't helpful.

 

Using username "chown".

Authenticating with public key "chown"

Further authentication required

Keyboard-interactive authentication prompts from server:

| Password: blah

| Duo two-factor login for chown|| Enter a passcode or select one of the following options:|| 1. Duo Push to XXX-XXX-0878| 2. Phone call to XXX-XXX-0878| 3. SMS passcodes to XXX-XXX-0878|| Passcode or option (1-3):

This is on Debian 11 btw.

The only way I can get access again without Duo and using SSH keys is by commenting out:

#AuthenticationMethods publickey,keyboard-interactive

1 Accepted Solution

Accepted Solutions

chown
Level 1
Level 1

I figured out the problem. I needed to modify /etc/pam.d/sshd:

# PAM configuration for the Secure Shell service

# Standard Un*x authentication.
#@include common-auth
auth  [success=1 default=ignore] /lib64/security/pam_duo.so
#auth  sufficient /lib64/security/pam_duo.so
auth  requisite  pam_deny.so
auth  required pam_permit.so
# Disallow non-root logins when /etc/nologin exists.
account    required     pam_nologin.so

 

View solution in original post

1 Reply 1

chown
Level 1
Level 1

I figured out the problem. I needed to modify /etc/pam.d/sshd:

# PAM configuration for the Secure Shell service

# Standard Un*x authentication.
#@include common-auth
auth  [success=1 default=ignore] /lib64/security/pam_duo.so
#auth  sufficient /lib64/security/pam_duo.so
auth  requisite  pam_deny.so
auth  required pam_permit.so
# Disallow non-root logins when /etc/nologin exists.
account    required     pam_nologin.so

 

Quick Links