Назад | Перейти на главную страницу

Использование OpenSSH (открытый ключ или пароль) + аутентификатор Google

Я хочу разрешить эти два типа аутентификации: открытый ключ + аутентификатор Google ИЛИ пароль + аутентификатор Google.

У меня в моем sshd_config:

AuthenticationMethods publickey,keyboard-interactive:pam password,keyboard-interactive:pam
UsePAM yes
ChallengeResponseAuthentication yes
PubkeyAuthentication yes
PasswordAuthentication yes

И в /etc/pam.d/ssh Я раскомментировал

#@include common-auth and added auth required pam_google_authenticator.so

в конце файла.

Маршрут ключ + токен все еще работает, но по какой-то причине мой пароль всегда отклоняется с сообщением «Доступ запрещен».

Я узнал, что всякий раз, когда я устанавливаю UsePAM на «да», проверка пароля не выполняется. Не уверен, почему?

Содержимое /etc/pam.d/sshd: (этот файл кажется мне очень длинным, но он был просто по умолчанию для ubuntu, может быть, я мог бы сократить его?)

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

auth required pam_google_authenticator.so

Содержимое /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_secure
# 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)
auth    optional            pam_cap.so 
# end of pam-auth-update config

На самом деле мой вопрос сводится к следующему: как использовать «UsePAM yes» вместе с «паролем AuthenticationMethods». Может стоит удалить этот вопрос и открыть новый?

Я узнал, что всякий раз, когда я устанавливаю UsePAM да, аутентификация по паролю не выполняется. Не уверен, почему?

UsePAM опция делает метод аутентификации password используйте тот же модуль PAM, который вы хотите использовать для второго фактора. Вот почему он отклоняет ваш пароль.


Это ответ на ваш вопрос с объяснением «почему», но не полное решение «как сделать это лучше». Настроить эту комбинацию сложно. Я хотел научиться делать это просто и правильно, но пока у меня было время. Но я открыт для ваших идей :)

Я провел все утро, пытаясь заставить этот работать. AFAIK теперь, метод аутентификации с открытым ключом происходит ВНЕ стека PAM.

Из того, что я могу наблюдать, имея ChallengeResponseAuthentication yes и UsePAM yes означает, что значение PasswordAuthentication эффективно игнорируется и может считаться no. Это означает password значение AuthenticationMethods всегда будет терпеть неудачу.

Это не было бы проблемой, если бы мы могли наблюдать успешное или неудачное состояние входа в систему с открытым ключом внутри стека PAM. Но мы не можем - похоже, это полностью обрабатывается внутри SSH.

Это означает, что мы можем AuthenticationMethods наборы):

  • publickey и ничего больше
  • Весь стек PAM
  • publickey и весь стек PAM

Но не так, как мы того хотим, publickey и часть стека PAM в зависимости от того, publickey был успешным.

Хотел бы быть доказанным, что ошибаюсь в этом!

Ответ прост: невозможно запросить два фактора с аутентификацией по паролю, но с объяснением для вас, которое поможет наладить работу. Вы смотрите на аутентификацию по паролю как на способ использования пароля. Это неверно.

«аутентификация по паролю» - это простой запрос одного пароля. Сервер не отправляет клиенту никаких конкретных запросов. Именно клиент выбирает, как пометить приглашение, например, когда он запрашивает «Введите пароль для пользователя @ host:».

«keyboard-interactive» - это более сложный запрос на произвольное количество единиц информации. Для каждой части информации сервер отправляет метку для приглашения. Более того, это позволяет серверу предоставить описание формы ожидаемого ответа. Сервер также может указать, какие входные данные являются секретными (пароли должны быть скрыты на экране), а какие нет (одноразовые пароли).

В большинстве случаев интерактивная аутентификация с клавиатуры используется для запроса единого «секретного» пароля, поэтому для конечного пользователя практически нет никакой разницы по сравнению с аутентификацией по паролю.

Поскольку интерактивная клавиатура - это механизм аутентификации, который позволяет серверу отправлять несколько пар запрос / ответ, подключаемому модулю Google Authenticator PAM требуется, чтобы он отправлял два вопроса - пароль и OTP.

Таким образом, аутентификация по паролю НИКОГДА не будет работать с Google Authenticator, поскольку у него нет возможности запрашивать более одного запроса. Google Authenticator будет работать с закрытыми ключами и OTP в запросе пароля (хотя и не в идеале). Google Authenticator будет работать с интерактивной клавиатурой с паролем и OTP. Google Authenticator НЕ будет работать с запросом пароля, поскольку он не может запрашивать правильную информацию.

В клиентском программном обеспечении установите приоритет интерактивности с клавиатурой над паролем, и вы будете настроены на получение двух приглашений с вашей текущей конфигурацией. Чтобы этого не произошло, мы можем полностью отключить аутентификацию по паролю.

На самом деле мой вопрос сводится к следующему: как использовать «UsePAM yes» вместе с «паролем AuthenticationMethods»

Прямо ответить на это вы не можете. Удалите пароль как поддерживаемый метод аутентификации и полагайтесь на интерактивную клавиатуру для аутентификации пароля. Установите "PasswordAuthentication no" в / etc / ssh / sshd_config

Так: / и т.д. / SSH / sshd_config

UsePAM yes
PasswordAuthentication no
ChallengeResponseAuthentication yes
PubkeyAuthentication yes
# I don't use AuthenticationMethods at all and rely on my yes/no's

/etc/pam.d/sshd (внизу)

auth required pam_google_authenticator.so nullok