TOC

Как настроить многофакторную аутентификацию для SSH на CentOS 7

Вступление

Authentication factor - это единичная часть информации, используемая для подтверждения того, что у вас есть права на выполнение действия, например, входа в систему. Authentication channel - это способ, которым система аутентификации доставляет фактор пользователю или требует от пользователя ответа. Пароли и токены безопасности являются примерами факторов аутентификации; компьютеры и телефоны являются примерами каналов.

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

В этом уроке мы настроим многофакторную аутентификацию для борьбы с этим. Многофакторная аутентификация (MFA) требует более одного фактора для аутентификации или входа в систему. Это означает, что плохой актер должен был бы скомпрометировать несколько вещей, как ваш компьютер и телефон, чтобы войти. Различные типы факторов часто суммируются как:

  1. Что-то, что вы * знаете *, например пароль или секретный вопрос

  2. Что-то, что у вас есть, например, приложение для аутентификации или токен безопасности

  3. Что-то, что вы * есть *, как ваш отпечаток или голос

Одним из распространенных факторов является приложение OATH-TOTP, такое как Google Authenticator. OATH-TOTP (Одноразовый пароль на основе времени открытой аутентификации) - это открытый протокол, который генерирует одноразовый пароль, обычно это 6-значное число, которое перерабатывается каждые 30 секунд.

В этой статье будет рассказано, как включить аутентификацию SSH с помощью приложения OATH-TOTP в дополнение к ключу SSH. Для входа на сервер через SSH потребуется два фактора по двум каналам, что делает его более безопасным, чем пароль или только ключ SSH. Кроме того, мы рассмотрим некоторые дополнительные варианты использования MFA и некоторые полезные советы и рекомендации.

Предпосылки

Чтобы следовать этому уроку, вам понадобится:

  • Один сервер CentOS 7 с некорневым пользователем sudo и ключом SSH, который вы можете настроить, следуя https://www.digitalocean.com/community/tutorials/initial-server-setup-with-centos-7[this Initial. Руководство по настройке сервера.

  • Смартфон или планшет с установленным приложением OATH-TOTP, например, Google Authenticator (iOS, https://play.google. .com / магазин / приложений / подробности? ID = com.google.android.apps.authenticator2 & гл = еп [Android]).

Шаг 1 - Установка Google PAM

На этом этапе мы установим и настроим PAM Google.

PAM, что означает Pluggable Authentication Module, является инфраструктурой аутентификации, используемой в системах Linux для аутентификации пользователя. Поскольку Google создал приложение OATH-TOTP, они также создали PAM, который генерирует TOTP и полностью совместим с любым приложением OATH-TOTP, например, Google Authenticator или Authy.

Во-первых, нам нужно добавить репозиторий EPEL (Extra Packages for Enterprise Linux).

sudo yum install https://dl.fedoraproject.org/pub/epel/epel-release-latest-7.noarch.rpm

Далее установите PAM. Вам может быть предложено принять ключ EPEL, если вы используете репо впервые. После принятия вам больше не будет предложено принять ключ.

sudo yum install google-authenticator

С установленным PAM мы будем использовать вспомогательное приложение, которое поставляется с PAM, чтобы сгенерировать ключ TOTP для пользователя, к которому вы хотите добавить второй фактор. Этот ключ генерируется для каждого пользователя, а не для всей системы. Это означает, что каждый пользователь, который хочет использовать приложение аутентификации TOTP, должен войти в систему и запустить вспомогательное приложение, чтобы получить свой собственный ключ; Вы не можете просто запустить его один раз, чтобы включить его для всех (но в конце этого руководства есть несколько советов по настройке или требованию MFA для многих пользователей).

Запустите приложение инициализации.

google-authenticator

После запуска команды вам будет задано несколько вопросов. Первый спрашивает, должны ли токены аутентификации основываться на времени.

OutputDo you want authentication tokens to be time-based (y/n)

Этот PAM позволяет использовать токены на основе времени или на основе последовательности. Использование маркеров sequential-based означает, что код начинается в определенной точке, а затем увеличивает код после каждого использования. Использование маркеров _time-based означает, что код изменяется случайным образом по истечении определенного времени. Мы будем придерживаться времени, потому что именно этого ожидают такие приложения, как Google Authenticator, поэтому ответьте «+ y +» «да».

После ответа на этот вопрос будет пролистано много выходных, включая большой QR-код. На этом этапе используйте приложение для проверки подлинности на своем телефоне, чтобы отсканировать QR-код, или введите секретный ключ вручную. Если QR-код слишком велик для сканирования, вы можете использовать URL-адрес над QR-кодом, чтобы получить уменьшенную версию. После добавления вы увидите шестизначный код, который меняется каждые 30 секунд в вашем приложении.

Оставшиеся вопросы сообщают PAM, как функционировать. Мы пройдем их один за другим.

OutputDo you want me to update your "/home/sammy/.google_authenticator" file (y/n)

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

OutputDo you want to disallow multiple uses of the same authentication
token? This restricts you to one login about every 30s, but it increases
your chances to notice or even prevent man-in-the-middle attacks (y/n)

Ответив «да» здесь, вы предотвращаете атаку воспроизведения, заставляя каждый код истечь сразу после использования. Это предотвращает захват злоумышленником кода, который вы только что использовали, и вход в систему с ним.

OutputBy default, tokens are good for 30 seconds. In order to compensate for
possible time-skew between the client and the server, we allow an extra
token before and after the current time. If you experience problems with
poor time synchronization, you can increase the window from its default
size of +-1min (window size of 3) to about +-4min (window size of 17 acceptable tokens).
Do you want to do so? (y/n)

Ответ «да» позволяет вводить до 8 действительных кодов в четырехминутном окне. Отвечая «нет», вы ограничиваете его 3 действительными кодами в течение 1:30 минутного окна. Если вы не обнаружите проблем с окном 1:30, ответ «нет» - более безопасный выбор.

OutputIf the computer that you are logging into isn't hardened against brute-force
login attempts, you can enable rate-limiting for the authentication module.
By default, this limits attackers to no more than 3 login attempts every 30s.
Do you want to enable rate-limiting (y/n)

Ограничение скорости означает, что удаленный злоумышленник может выполнить только определенное количество предположений, прежде чем его заблокируют. Если вы ранее не настраивали ограничение скорости непосредственно в SSH, то теперь это отличная техника защиты.

Теперь, когда PAM Google установлен и настроен, следующий шаг - настроить SSH для использования вашего ключа TOTP. Нам нужно сообщить SSH о PAM, а затем настроить SSH для его использования.

Шаг 2 - Настройка OpenSSH

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

Для начала мы отредактируем файл конфигурации + sshd +. Здесь мы используем + nano +, который по умолчанию не установлен в CentOS. Вы можете установить его с помощью + sudo yum install nano + или использовать свой любимый альтернативный текстовый редактор.

sudo nano /etc/pam.d/sshd

Добавьте следующую строку в конец файла.

/etc/pam.d/sshd

. . .
# Used with polkit to reauthorize users in remote sessions
-session   optional     pam_reauthorize.so prepare

Слово + nullok + в конце последней строки говорит PAM, что этот метод аутентификации является необязательным. Это позволяет пользователям без токена OATH-TOTP по-прежнему входить в систему с использованием своего ключа SSH. Когда у всех пользователей есть токен OATH-TOTP, вы можете удалить + nullok + из этой строки, чтобы сделать MFA обязательным.

Сохраните и закройте файл.

Далее мы настроим SSH для поддержки этого типа аутентификации. Откройте файл конфигурации SSH для редактирования.

sudo nano /etc/ssh/sshd_config

Найдите строки + ChallengeResponseAuthentication no. Закомментируйте строку + no + и раскомментируйте строку + no +.

/ И т.д. / SSH / sshd_config

. . .
# Change to no to disable s/key passwords

ChallengeResponseAuthentication no
. . .

Сохраните и закройте файл, затем перезапустите SSH, чтобы перезагрузить файлы конфигурации. Перезапуск службы + sshd + не приведет к закрытию открытых соединений, поэтому вы не рискуете заблокировать себя этой командой.

sudo systemctl restart sshd.service

Чтобы проверить, что все работает, откройте другой терминал и попробуйте войти через SSH. Если вы ранее создали ключ SSH и используете его, вы заметите, что вам не нужно было вводить пароль пользователя или код подтверждения MFA. Это потому, что ключ SSH переопределяет все остальные параметры аутентификации по умолчанию. В противном случае вы должны были получить пароль и код подтверждения.

Если вы хотите убедиться, что то, что вы сделали до сих пор, работает, в вашем открытом SSH-сеансе перейдите к + ~ / .ssh / + и временно переименуйте файл авторизованные_ключи, откройте новый сеанс и войдите в систему с помощью нашего пароль и проверочный код.

cd ~/.ssh
mv authorized_keys authorized_keys.bak

После того, как вы убедились, что ваш токен TOTP работает, переименуйте файл «author_keys.bak» обратно в прежнее состояние.

mv authorized_keys.bak authorized_keys

Затем нам нужно включить ключ SSH в качестве одного фактора и код проверки в качестве второго и сообщить SSH, какие факторы использовать, и не дать ключу SSH переопределить все другие типы.

Шаг 3 - информирование SSH о MFA

Снова откройте файл конфигурации + sshd +.

sudo nano /etc/ssh/sshd_config

Добавьте следующую строку внизу файла. Это сообщает SSH, какие методы аутентификации требуются. Эта строка сообщает SSH, что нам нужен ключ SSH и либо пароль, либо код подтверждения (или все три).

/ И т.д. / SSH / sshd_config

. . .
# Added by DigitalOcean build process
ClientAliveInterval 120
ClientAliveCountMax 2

Сохраните и закройте файл.

Затем снова откройте файл конфигурации PAM + sshd +.

sudo nano /etc/pam.d/sshd

Найдите строку + auth substack password-auth + в верхней части файла. Прокомментируйте это, добавив символ + # + в качестве первого символа в строке. Это говорит PAM не запрашивать пароль.

/etc/pam.d/sshd

. . .
auth       substack     password-auth
. . .

Сохраните и закройте файл, затем перезапустите SSH.

sudo systemctl restart sshd.service

Теперь попробуйте снова войти на сервер с другим сеансом. В отличие от прошлого раза, SSH должен запросить ваш код подтверждения. После входа вы будете авторизованы. Даже если вы не видите никаких признаков того, что ваш SSH-ключ был использован, ваша попытка входа в систему использовала два фактора. Если вы хотите проверить, вы можете добавить + -v + (для подробного описания) после команды SSH:

Example SSH output\. . .
debug1: Authentications that can continue: publickey
debug1: Next authentication method: publickey
debug1: Offering RSA public key: /Users/sammy/.ssh/id_rsa
debug1: Server accepts key: pkalg ssh-rsa blen 279
Authenticated with partial success.
debug1: Authentications that can continue: keyboard-interactive
debug1: Next authentication method: keyboard-interactive
Verification code:

В конце вывода вы увидите, где SSH использует ваш SSH-ключ, а затем запросит код подтверждения. Теперь вы можете войти через SSH с ключом SSH и одноразовым паролем. Если вы хотите применить все три типа аутентификации, вы можете выполнить следующий шаг.

Шаг 4 - Добавление третьего фактора (необязательно)

На шаге 3 мы перечислили утвержденные типы аутентификации в файле + sshd_config +:

  1. + publickey + (ключ SSH)

  2. + пароль publickey + (пароль)

  3. + клавиатура-интерактив + (проверочный код)

Несмотря на то, что мы перечислили три различных фактора, с выбранными нами вариантами, они допускают только ключ SSH и код подтверждения. Если вы хотите иметь все три фактора (ключ SSH, пароль и проверочный код), одно быстрое изменение активирует все три.

Откройте файл конфигурации PAM + sshd +.

sudo nano /etc/pam.d/sshd

Найдите строку, которую вы закомментировали ранее, + # auth substack password-auth +, и раскомментируйте строку, удалив символ + # +. Сохраните и закройте файл. Теперь еще раз, перезапустите SSH.

sudo systemctl restart sshd.service

Включив опцию + auth substack password-auth +, PAM теперь будет запрашивать пароль в дополнение к проверке ключа SSH и запрашиванию кода проверки, который у нас был ранее. Теперь мы можем использовать что-то, что мы знаем (пароль), и два разных типа вещей (ключ SSH и код подтверждения) по двум разным каналам.

До сих пор в этой статье рассказывалось, как включить MFA с ключом SSH и одноразовым паролем на основе времени. Если это все, что вам нужно, вы можете закончить здесь. Однако это не единственный способ многофакторной аутентификации. Ниже приведены несколько дополнительных способов использования этого модуля PAM для многофакторной аутентификации, а также некоторые советы и рекомендации по восстановлению, автоматическому использованию и многим другим.

Совет 1 - Восстановление доступа

Как и в случае любой системы, которую вы укрепляете и защищаете, вы отвечаете за управление этой безопасностью. В этом случае это означает, что вы не потеряете свой SSH-ключ или ваш секретный ключ TOTP и убедитесь, что у вас есть доступ к вашему приложению TOTP. Однако иногда что-то случается, и вы можете потерять контроль над клавишами или приложениями, в которые вы должны войти.

Потеря ключа SSH или секретного ключа TOTP

Если вы потеряете свой SSH-ключ или секретный ключ TOTP, восстановление можно разбить на пару шагов. Первый - это возврат в систему без знания кода проверки, а второй - поиск секретного ключа или его восстановление для обычного входа в систему MFA.

Чтобы войти после потери секретного ключа, который генерирует проверочный код на дроплете DigitalOcean, вы можете просто https://www.digitalocean.com/community/tutorials/how-to-use-the-digitalocean-console-to-access -your-droplet [используйте виртуальную консоль] на панели инструментов, чтобы войти в систему с использованием вашего имени пользователя и пароля.

В противном случае вам понадобится административный пользователь с доступом к sudo; не включайте MFA для этого пользователя, а используйте только ключ SSH. Если вы или другой пользователь теряете свой секретный ключ и не можете войти в систему, тогда пользователь с правами администратора может войти в систему и помочь восстановить или восстановить ключ для любого пользователя, используя + sudo +.

После того, как вы вошли в систему, есть два способа помочь получить секрет TOTP:

  1. Восстановить существующий ключ

  2. Создать новый ключ

В домашнем каталоге каждого пользователя секретный ключ и настройки Google Authenticator сохраняются в + ~ / .google-authenticator +. Самая первая строка этого файла - секретный ключ. Быстрый способ получить ключ - выполнить следующую команду, которая отображает первую строку файла + google-authenticator + (т.е. секретный ключ). Затем возьмите этот секретный ключ и введите его вручную в приложение TOTP.

head -n 1 /home//.google_authenticator

Если есть причина не использовать существующий ключ (например, из-за невозможности легко поделиться секретным ключом с защищенным пользователем или существующий ключ был взломан), вы можете удалить файл + ~ / .google-authenticator + вчистую. Это позволит пользователю снова войти в систему, используя только один фактор, при условии, что вы не применили MFA, удалив «nullok» в файле «/etc/pam.d/sshd». Затем они могут запустить + google-authenticator, чтобы сгенерировать новый ключ.

Потеря доступа к приложению TOTP

Если вам необходимо войти на сервер, но у вас нет доступа к приложению TOTP для получения кода подтверждения, вы все равно можете войти в систему, используя коды восстановления, которые отображались при первом создании секретного ключа. Обратите внимание, что эти коды восстановления используются только один раз. Как только кто-то используется для входа в систему, он не может быть снова использован в качестве кода подтверждения.

Совет 2 - Изменение настроек аутентификации

Если вы хотите изменить настройки MFA после начальной конфигурации, вместо создания новой конфигурации с обновленными настройками, вы можете просто отредактировать файл + ~ / .google-authenticator +. Этот файл выложен следующим образом:

google-authenticator layout
<secret key>
<options>
<recovery codes>

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

Вот изменения, которые вы можете внести в этот файл:

  • Чтобы включить последовательные коды вместо кодов, основанных на времени, измените строку +" TOTP_AUTH + `на + "HOTP_COUNTER 1 +`.

  • Чтобы разрешить многократное использование одного кода, удалите строку `+" DISALLOW_REUSE + `.

  • Чтобы продлить срок действия кода до 4 минут, добавьте строку `+" WINDOW_SIZE 17 + `.

  • Чтобы отключить несколько неудачных входов в систему (ограничение скорости), удалите строку `+" RATE_LIMIT 3 30 + `.

  • Чтобы изменить порог ограничения скорости, найдите строку +" RATE_LIMIT 3 30 + `и настройте числа. `+ 3 + в оригинале указывает количество попыток за период времени, а + 30 + указывает период времени в секундах.

  • Чтобы отключить использование кодов восстановления, удалите пять 8-значных кодов внизу файла.

Совет 3 - Как избежать MFA для некоторых учетных записей

Может возникнуть ситуация, когда один пользователь или несколько учетных записей служб (т.е. учетные записи, используемые приложениями, а не людьми), нуждаются в SSH-доступе без включенного MFA. Например, некоторые приложения, использующие SSH, например некоторые клиенты FTP, могут не поддерживать MFA. Если в приложении нет способа запросить код подтверждения, запрос может зависнуть до истечения времени ожидания соединения SSH.

Пока пара опций в + / etc / pam.d / sshd + установлена ​​правильно, вы можете контролировать, какие факторы используются для каждого пользователя.

Чтобы разрешить MFA для некоторых учетных записей и SSH-ключ только для других, убедитесь, что следующие параметры в + / etc / pam.d / sshd + активны.

/etc/pam.d/sshd

#%PAM-1.0
auth       required     pam_sepermit.so
#auth       substack     password-auth

. . .

# Used with polkit to reauthorize users in remote sessions
-session   optional     pam_reauthorize.so prepare
auth       required      pam_google_authenticator.so nullok

Здесь + auth substack password-auth + закомментирован, потому что пароли необходимо отключить. Невозможно принудительное использование MFA, если в некоторых учетных записях отключено MFA, поэтому оставьте опцию + nullok + в последней строке.

После настройки этой конфигурации просто запустите + google-authenticator + от имени всех пользователей, которым требуется MFA, и не запускайте его для пользователей, для которых будут использоваться только ключи SSH.

Совет 4 - Автоматизация установки с помощью управления конфигурацией

Многие системные администраторы используют configuration tools, например Puppet, Chef или Ansible, для управления своими системами. Если вы хотите использовать систему, подобную этой, для установки, настройки секретного ключа при создании учетной записи нового пользователя, есть способ сделать это.

+ google-authenticator поддерживает переключатели командной строки для установки всех параметров в одной неинтерактивной команде. Чтобы увидеть все параметры, вы можете набрать + google-authenticator --help. Ниже приведена команда, которая настроит все, как описано в шаге 1:

google-authenticator -t -d -f -r 3 -R 30 -W

Это отвечает на все вопросы, на которые мы ответили вручную, сохраняет их в файл, а затем выводит секретный ключ, QR-код и коды восстановления. (Если вы добавите флаг + -q +, то никаких выходных данных не будет.) Если вы используете эту команду в автоматическом режиме, убедитесь, что вы захватили секретный ключ и / или коды восстановления и сделали их доступными для Пользователь.

Совет 5 - Принудительное MFA для всех пользователей

Если вы хотите принудительно использовать MFA для всех пользователей даже при первом входе в систему или предпочитаете не полагаться на то, что ваши пользователи будут создавать свои собственные ключи, есть простой способ справиться с этим. Вы можете просто использовать один и тот же файл + .google-authenticator + для каждого пользователя, так как в этом файле нет пользовательских данных.

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

Другой способ принудительного создания секретного ключа пользователя - использовать скрипт bash, который:

  1. Создает токен TOTP,

  2. Предлагает им загрузить приложение Google Authenticator и отсканировать отображаемый QR-код, и

  3. Запускает для них приложение + google-authenticator + после проверки, существует ли уже файл + .google-authenticator +.

Чтобы убедиться, что скрипт запускается, когда пользователь входит в систему, вы можете назвать его + .bash_login + и поместить его в корень своего домашнего каталога.

Заключение

Тем не менее, имея два фактора (ключ SSH + токен MFA) по двум каналам (ваш компьютер + ваш телефон), вы очень сильно затруднили внешний агент грубому проникновению в вашу машину через SSH и значительно увеличили безопасность вашей машины.

Related