You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
What happened:
Attempting to configure pam_yubico integration with teleport leads to all auth attempts failing when attempted through Teleport. Integration works fine, however, through standard OpenSSH. It appears that Teleport is injecting an extra byte or character which leads to pam_yubico module to swallow the first byte in order to fit the 12/32 token_id/otp expected response.
What you expected to happen:
pam_yubico integration should work with teleport PAM auth.
Reproduction Steps
As minimally and precisely as possible, describe step-by-step how to reproduce the problem.
1.
2.
3.
Server Details
Teleport version (run teleport version): 9.0.4
Server OS (e.g. from /etc/os-release): Ubuntu 20.04
Where are you running Teleport? (e.g. AWS, GCP, Dedicated Hardware): EC2/VM
Additional details:
PAM Auth File:
#configuration for the Secure Shell service
# Standard Un*x authentication.
# @include common-auth
#auth [success=1 default=ignore] /lib64/security/pam_duo.so
#auth requisite pam_deny.so
#auth required pam_permit.so
auth required pam_yubico.so id=my_id key=my_key debug debug_file=/var/run/pam-debug.log authfile=/etc/pam.d/authorized_yubikeys
auth [success=1 default=ignore] pam_unix.so nullok_secure try_first_pass
auth requisite 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.
@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
# 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.
@include common-password
PAM Auth File:
user:abcd
Client Details
Tsh version (tsh version): 9.0.4
Computer OS (e.g. Linux, macOS, Windows): macOS
Browser version (for UI-related issues): Brave/Chrome/Safari/Firefox
Circled back w/ end-user re: requirement for external MFA outside of Teleport-provided MFA. Response received is copied below:
With Teleport MFA we are trusting Teleport with MFA since a coding/config issue can disable/void the trigger (since it's all managed by teleport)
With OS/PAM MFA when if Teleport is compromised, OS will still block and unauthorized access. That's the difference to us.
Description
What happened:
Attempting to configure pam_yubico integration with teleport leads to all auth attempts failing when attempted through Teleport. Integration works fine, however, through standard OpenSSH. It appears that Teleport is injecting an extra byte or character which leads to pam_yubico module to swallow the first byte in order to fit the 12/32 token_id/otp expected response.
What you expected to happen:
pam_yubico integration should work with teleport PAM auth.
Reproduction Steps
As minimally and precisely as possible, describe step-by-step how to reproduce the problem.
1.
2.
3.
Server Details
teleport version
): 9.0.4/etc/os-release
): Ubuntu 20.04PAM Auth File:
PAM Auth File:
Client Details
tsh version
): 9.0.4Debug Logs
PAM Logs:
Teleport node logs:
gz#4642
The text was updated successfully, but these errors were encountered: