company_banner

Добавляем двухфакторную OTP аутентификацию в SSH за 10 минут

  • Tutorial
Ситуация: у вас парк Linux-серверов, куда вы регулярно заходите по SSH. Двухфакторная аутентификация для SSH по какому-либо железному ключу или Google Authenticator настраивается, может быть, и просто, но далеко не всегда удобно эту настройку производить на каждом сервере, их может быть слишком много, или просто страшно перезапускать sshd :)

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

image

Начнем с разворачивания Isolate, для этого понадобится CentOS 7, Ubuntu 16.04 или же Debian 8 машина:

1. Подготавливаем систему к установке Isolate:

Centos:
yum install ansible git

Ubuntu:
apt update; apt install git python-pip
pip install ansible


2. Скачиваем сам Isolate:

git clone https://github.com/itsumma/isolate.git

3. Для запуска ansible на той же машине, приводим к виду (можно запускать либо с удаленной машины, сервера или десктопного Linux/MacOS, либо же прямо на той машине, на которой разворачиваем Isolate):

[main]
localhost ansible_connection=local

4.

ansible-playbook -i isolate/ansible/hosts.ini isolate/ansible/main.yml

Ждем выполнения. В случае, если Ubuntu ругается на шаг Upgrading installed packages (APT), делаем:

apt dist-upgrade

5. Добавляем в конец /etc/bashrc (Centos) либо /etc/bash.bashrc (Ubuntu)

if [ -f /opt/auth/shared/bash.sh ]; then
    source /opt/auth/shared/bash.sh;
fi

6. Перезагружаем машину. Готово!

Приступаем к включению oauth


1. Добавляем в конец /etc/pam.d/sshd (Centos) строку, либо в /etc/pam.d/common-auth (Ubuntu)

auth required pam_oath.so usersfile=/etc/oath/users.oath window=20 digits=6

2.

sed -i -e 's/ChallengeResponseAuthentication no/ChallengeResponseAuthentication yes/g' /etc/ssh/sshd_config

3. В конец /etc/ssh/sshd_config

Match Group auth
    AuthenticationMethods keyboard-interactive

4.

systemctl restart sshd

5. Добавляем пользователя, которому включим oauth

auth-add-user  имя_юзера

6. Генерируем TOTP или HOTP токены:

gen-oath-safe имя_юзера totp
gen-oath-safe имя_юзера hotp

image

Добавляем токен через QR-код в Google Authenticator:

image

7.

touch /etc/oath/users.oath
chmod 0600 /etc/oath/users.oath

8. Полученную в пункте 6 строку добавляем в /etc/oath/users.oath

9. Смотрим пароль от redis

grep requirepass /etc/redis.conf

Добавляем запись в /etc/bashrc (Centos) либо /etc/bash.bashrc (Ubuntu)

ISOLATE_BACKEND=redis
ISOLATE_REDIS_HOST="127.0.0.1";
ISOLATE_REDIS_PORT="6379";
ISOLATE_REDIS_DB=0;
ISOLATE_REDIS_PASS=redis_pass; 
export ISOLATE_REDIS_HOST;
export ISOLATE_REDIS_PORT;
export ISOLATE_REDIS_PASS;
export ISOLATE_REDIS_DB;

Добавление серверов


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

Добавляем сервер, на который будем ходить:

auth-add-host --project server-admin --server-name ubuntu --ip 10.0.0.1

Посмотреть список серверов можно с помощью команды s:

image

Добавление пользователя на сервер


На сервере 10.0.0.1 создаем юзера support и прописываем ему ключ из /home/auth/.ssh/id_rsa.pub с Isolate сервера:

SUPPORT_USER="support"
KEY="<YOU KEY HERE>"
useradd -m ${SUPPORT_USER}
mkdir /home/${SUPPORT_USER}/.ssh
echo ${KEY} >> /home/${SUPPORT_USER}/.ssh/authorized_keys
chmod 600 /home/${SUPPORT_USER}/.ssh/authorized_keys
chmod 700 /home/${SUPPORT_USER}/.ssh/
chown -R ${SUPPORT_USER}:${SUPPORT_USER} /home/${SUPPORT_USER}/.ssh/
echo "${SUPPORT_USER} ALL=(ALL) NOPASSWD: ALL" >> /etc/sudoers

Теперь на Isolate сервере мы можем использовать команды s для поиска нужного сервера и g для перехода на конкретный сервер:

g ip_сервера - g 10.0.0.1
g проект имя_сервера - g server-admin ubuntu

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

Как обычно, комментарии, дополнения и, конечно, пул реквесты приветствуются! Github проекта.
ITSumma
235,00
Собираем безумных людей и вместе спасаем интернет
Поделиться публикацией

Похожие публикации

Комментарии 15

    0
    The idea behind Isolate is that we should somehow manage how do people get access to our servers. How can we make this process more secure? How could we prevent a system from being compromised when someone lost the laptop with ssh key. What would we do in case someone quits the company — is there an alternative to just changing all passwords, keys, etc?

    А ssh certificates не решают эту же проблему?

      0
      А вообще для всех тех кто только научился заходить на сервер по ssh после прочтения двух трех мануалов и сразу решил что «надо эту проблему решить», все уже давным давно решено за них: OpenLDAP, FreeIPA, SSSD и прочее. Целый зоопарк решений для управления авторизацией на больших группах серверов.
        0
        конечно :)
        мы не претендуем на глобальное решение которое заменит все, но если есть телефон, есть желание защититься лучше, и при этом не постоянным паролем а дополнительно OTP кодами, можно просто склонить репозиторий и через пять минут получить решение, то есть да, другие решения конечно есть, но мы поделились простым, которое может быть кому то пригодиться (и люди вместо сложного внедрения будут использовать наше) :)
          0
          How could we prevent a system from being compromised when someone lost the laptop with ssh key. What would we do in case someone quits the company — is there an alternative to just changing all passwords, keys, etc?


          Судя по вот этому ваше решение это велосипед который игнорирует уже существующие системы (которые к слову развивались не один год). Простейший OpenLDAP+SSSD позволит в одну минуту заблокировать пользователя на всех серверах + отозвать sudo привилегии + отозвать доступ к сервисам которые работают через PAM или напрямую через LDAP и т.д. и т.п. И все это сделано централизованно без необходимости использовать несуразный Ansible (его сейчас вообще очень модно использовать где попало). Опять же с банальным OpenLDAP и SSSD можно включить MFA на всех устройствах. А если идти более сложным путем (FreeIPA) то открывается еще больше возможностей.

          Дисклеймер: Я не против Ansible, и сам его использую чтобы поддерживать примерно 1.5к серверов. Но я точно не хочу использовать его для вот таких вещей.
            0
            у нас немного другая задача: сервера не наши, а клиентские. Сейчас мы даем клиентам публичный ключ, что бы они его себе добавили. Осталось только придумать, как своим сотрудникам не давать приватный, а разрешать им пользоваться.
              0
              Ну у нас как бы тоже самое. Сервера не свои, а клиентские. Своих и клиентских пользователей мы добавляем в LDAP. Наши пользователи имеют доступ ко всем серверам, но только по определенному тикету, если нет тикета, нет и доступа. Клиентские пользователи имеют доступ только к своим серверам, но у них доступ не ограничен тикетом (может быть ограниченный sudo, например разработчики могут переключится на пользователя под которым работает приложение, или только могут управлять определенными процессами).

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

              Как я сказал выше этот продукт не добавляет ничего нового, а только является очень очень странным велосипедом в области где все уже вполне себе хорошо не первый год.
                0
                Если нет проблем с англ. очень советую прочитать вот эту статью про достоинства и недостатки FreeIPA+SSSD+MFA, но эта статья достаточно старая и многие указанные там недостатки уже были исправлены (в статье есть ссылки на соответствующие дискусси разработчиков)
                  0
                  Кажется вам подойдет смарт-карта. Ключ физически у пользователя, но он не может его получить в открытом виде, а может только использовать.

                  Другой вариант, вероятно более подходящий под ваше описание: облачный сервер подписи. Ключи пользователей могут храниться на нем + HSM. При прохождении строгой аутентификации(можно даже по OTP-паролям) на этом сервере, он позволит подписать аутентификационный запрос. Правда, насколько мне известно, пока облачные сервера подписи используются только для подписи. Но аутентификация по ключам подразумевает как раз подпись нонса, так что это тоже должно быть возможно.
          +1
          очень интересно, попробуем разобраться.
            0
            мы всегда на связи ;)
            0
            А в чем преимущество по сравнению с аутентификацией по сертификату, который зашифрован паролем?
              0
              чуть ниже уже ответил
              главный мой страх по сути: любой кейлоггер позволит утащив сертификат ввести пароль и работать с сервером, допускать такого не хочется ни по какой причине (поэтому и на почту делают не второй пароль а именно одноразовые коды — даже свиснутый код не сработает)
              0
              Немного не понимаю зачем нужна двухфакторная аутентификация для ssh если использовать вход по ключу и ключ можно зашифровать паролем, ну если только вы боитесь что кто-то ваш приватный ключ украдет + пароль он него, но если кто-то украл ваш приватный ключ то мне кажется стоит задуматься о том, а не делаете вы что-то неправильно и на сколько хорошо ваш спасет двух фактурная амортизация (если кто-то получил доступ к вашей машине)?

              По мне так если париться, так сделать уведомления об подключения к серверу с нового ip или добавления нового публичного ключа на авторизацию.
                +1
                о, здесь очень просто
                даже лично я, оставаясь параноиком боюсь компрометации лэптопа/компьютера где лежит ключ
                как говорят — по настоящему система защищена тогда, когда ты понимаешь что даже в случае компрометации, важные данные не будут потеряны
                условно говоря если хоть каким то образом мой компьютер будет скомпрометирован (кейлоггер, что угодно), зайти на серверы будет нельзя, так как 2FA не даст повторить попытку
                  0
                  Да, вы правы, это вполне себе неплохая дверь которую плохие программы скорее всего не рассчитаны открывать, но думаю преимущество это зашита от кейлогеров перед это как раз участие 2 устройств для авторизации.

                  Хотя, у меня есть вариант взлома (говорю уже с моменте когда злая программа силой магии попала на ваш компьютер):
                  Мы просто эмулируем подключения к вашему серверу для вас (такой странны консольный малварь).

                  И мне кажется повысить зашиты можно немного по другому. Это использовать 2 фактурную авторизацию при выполнении команд от root, и возможно даже написать отдельный протокол подтверждения команды с телефона.

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

              Только полноправные пользователи могут оставлять комментарии. Войдите, пожалуйста.

              Самое читаемое