Как правильно общаться с удаленным сервером через SSH

SSH
далек от совершенства, но он был разработан с учетом безопасности, и на
протяжении многих лет было написано огромное количество инструментов для
облегчения его использования. Кроме того, большинство популярного софта
комплектуются SSH.
Он поддерживается практически во всех архитектурах и дистрибутивах, начиная от Raspberry Pi и заканчивая массивными суперкомпьютерными
кластерами.

Сертификаты


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

Следующий
уровень секьюрности после ключей – SSH-сертификаты, которые поддерживаются с OpenSSH
5.4, выпущенного ещё в 2010 году.

С помощью
SSH-сертификатов вы создаете центр сертификации (CA), а затем используете его
для выдачи и криптографической подписи, которая аутентифицирует пользователей.
Вы можете создать пару ключей, например, с помощью команды ssh-keygen:

            $ ssh-keygen -t rsa -b 4096 -f host_ca -C host_ca
Generating public/private rsa key pair.
Enter passphrase (empty for no passphrase): 
Enter same passphrase again: 
Your identification has been saved in host_ca.
Your public key has been saved in host_ca.pub.
The key fingerprint is:
SHA256:tltbnMalWg+skhm+VlGLd2xHiVPozyuOPl34WypdEO0 host_ca
The key's randomart image is:
+---[RSA 4096]----+
|              +o.|
|            .+..o|
|           o.o.+ |
|          o o.= E|
|        S  o o=o |
|       ....+ = +.|
|       ..=. %.o.o|
|        *o Oo=.+.|
|       .oo=ooo+..|
+----[SHA256]-----+

$ ls -l
total 8
-rw-------. 1 gus gus 3381 Mar 19 14:30 host_ca
-rw-r--r--. 1 gus gus  737 Mar 19 14:30 host_ca.pub

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

Рекомендуется использовать два отдельных CA – один для
подписания сертификатов хостов, другой для пользователей. Одни и те же процессы не будут добавлять и хосты, и юзеров. А если закрытый
ключ скомпрометируют, нужно будет лишь пересоздать сертификаты для хостов
или пользователей, а не оба сразу.

Вот так создается
user_ca:

            $ ssh-keygen -t rsa -b 4096 -f user_ca -C user_ca

Файл
user_ca – закрытый ключ пользователя, который должен быть защищен, как и закрытый
ключ хоста.

Выдача
сертификатов хостам


Создадим новый ключ и подпишем с помощью центра сертификации.

ssh_host_rsa_key-cert.pub содержит подписанный сертификат хоста.

            $ ssh-keygen -f ssh_host_rsa_key -N '' -b 4096 -t rsa

$ ls -l
-rw------- 1 palpatine palpatine 3247 Mar 17 14:49 ssh_host_rsa_key
-rw-r--r-- 1 palpatine palpatine  764 Mar 17 14:49 ssh_host_rsa_key.pub

$ ssh-keygen -s host_ca -I host.example.com -h -n host.example.com -V +52w ssh_host_rsa_key.pub
Enter passphrase: # the passphrase used for the host CA
Signed host key ssh_host_rsa_key-cert.pub: id "host.example.com" serial 0 for host.example.com valid from 2020-03-16T15:00:00 to 2021-03-15T15:01:37

$ ls -l
-rw------- 1 palpatine palpatine 3247 Mar 17 14:49 ssh_host_rsa_key
-rw-r--r-- 1 palpatine palpatine 2369 Mar 17 14:50 ssh_host_rsa_key-cert.pub
-rw-r--r-- 1 palpatine palpatine  764 Mar 17 14:49 ssh_host_rsa_key.pub

Вот описание
используемых флагов:

  • -s host_ca: указывает имя файла закрытого CA-ключа, используемого для подписи.
  • -I host.example.com: буквенно-цифровая строка, идентифицирующая сервер. При необходимости значение можно использовать для отзыва сертификата.
  • -h: указывает, что сертификат выдается хосту, а не юзеру.
  • -n host.example.com: указывает разделенный запятыми список участников, для проверки подлинности которых будет действителен сертификат.
  • -V +52w: срок действия сертификата. В данном случае 52 недели (один год). По умолчанию сертификаты действительны вечно. Указание периода истечения срока действия сертификатов хоста настоятельно рекомендуется для ротации и замены сертификатов.

Настройка
SSH для использования сертификатов

Нужно указать серверу, чтобы он использовал новый сертификат. Скопируйте три сгенерированных файла на сервер в каталог /etc/ssh,
установите разрешения и добавьте в файл /etc/ssh/sshd_config следующую строку:

            HostCertificate /etc/ssh/ssh_host_rsa_key-cert.pub

Перезагрузите sshd с помощью systemctl restart sshd. Теперь сервер
настроен на выдачу сертификата. Чтобы локальный ssh-клиент мог автоматически
доверять хосту на основе удостоверения сертификата, нужно добавить открытый ключ
CA в known_hosts. Вы можете
сделать это, добавив в начало файла host_ca.pub следующее: @cert-authority
*.example.com, а затем и в ~/.ssh/known_hosts:

            @cert-authority *.example.com ssh-rsa AAAAB3NzaC1yc2EAAAADAQABAAACAQDwiOso0Q4W+KKQ4OrZZ1o1X7g3yWcmAJtySILZSwo1GXBKgurV4jmmBN5RsHetl98QiJq64e8oKX1vGR251afalWu0w/iW9jL0isZrPrmDg/p6Cb6yKnreFEaDFocDhoiIcbUiImIWcp9PJXFOK1Lu8afdeKWJA2f6cC4lnAEq4sA/Phg4xfKMQZUFG5sQ/Gj1StjIXi2RYCQBHFDzzNm0Q5uB4hUsAYNqbnaiTI/pRtuknsgl97xK9P+rQiNfBfPQhsGeyJzT6Tup/KKlxarjkMOlFX2MUMaAj/cDrBSzvSrfOwzkqyzYGHzQhST/lWQZr4OddRszGPO4W5bRQzddUG8iC7M6U4llUxrb/H5QOkVyvnx4Dw76MA97tiZItSGzRPblU4S6HMmCVpZTwva4LLmMEEIk1lW5HcbB6AWAc0dFE0KBuusgJp9MlFkt7mZkSqnim8wdQApal+E3p13d0QZSH3b6eB3cbBcbpNmYqnmBFrNSKkEpQ8OwBnFvjjdYB7AXqQqrcqHUqfwkX8B27chDn2dwyWb3AdPMg1+j3wtVrwVqO9caeeQ1310CNHIFhIRTqnp2ECFGCCy+EDSFNZM+JStQoNO5rMOvZmecbp35XH/UJ5IHOkh9wE5TBYIeFRUYoc2jHNAuP2FM4LbEagGtP8L5gSCTXNRM1EX2gQ== host_ca

Значение
*.example.com указывает на то, что этому сертификату следует доверять для
идентификации любого хоста, к которому вы подключаетесь и который имеет домен
*.example.com. Это разделенный запятыми список имен хостов для сертификата: host1,
host2, host3 или 1.2.3.4, 1.2.3.5 в зависимости от обстоятельств.

Как
только закончите настройку, удалите все старые записи для host.example.com в ~/.ssh/known_hosts
и запустите подключение. Правильность создания сертификата проверяется так:

            $ ssh -vv host.example.com 2>&1 | grep "Server host certificate"
debug1: Server host certificate: ssh-rsa-cert-v01@openssh.com SHA256:dWi6L8k3Jvf7NAtyzd9LmFuEkygWR69tZC1NaZJ3iF4, serial 0 ID "host.example.com" CA ssh-rsa SHA256:8gVhYAAW9r2BWBwh7uXsx2yHSCjY5OPo/X3erqQi6jg valid from 2020-03-17T11:49:00 to 2021-03-16T11:50:21
debug2: Server host certificate hostname: host.example.com

На этом
этапе вы можете продолжить выдачу сертификатов всех хостов, используя центр сертификации. Польза от этого следующая: вам больше не нужно полагаться
на небезопасную модель Trust On First Use (TOFU) для новых хостов, и если вы
когда-нибудь повторно развернете сервер и, следовательно, измените ключ хоста, новый хост автоматически представит подписанный сертификат без ужасного предупреждения: WARNING: REMOTE HOST IDENTIFICATION HAS CHANGED!

Выдача
сертификатов пользователям (для аутентификации пользователей на хостах)

В этом
примере мы создадим новый ключ пользователя и подпишем с помощью центра сертификации. 

            $ ssh-keygen -f user-key -b 4096 -t rsa

$ ls -l
-rw-r--r--. 1 tatooine tatooine 737 Mar 19 16:33 user-key.pub
-rw-------. 1 tatooine tatooine 3369 Mar 19 16:33 user-key

$ ssh-keygen -s user_ca -I gus@gravitational.com -n ec2-user,gus -V +1d user-key.pub
Enter passphrase: # the passphrase used for the user CA
Signed user key user-key-cert.pub: id "gus@gravitational.com" serial 0 for ec2-user,gus valid from 2020-03-19T16:33:00 to 2020-03-20T16:34:54

$ ls -l
-rw-------. 1 tatooine tatooine 3369 Mar 19 16:33 user-key
-rw-r--r--. 1 tatooine tatooine 2534 Mar 19 16:34 user-key-cert.pub
-rw-r--r--. 1 tatooine tatooine 737 Mar 19 16:33 user-key.pub

user-key-cert.pub
содержит подписанный сертификат пользователя. Для входа в систему понадобится как этот, так и приватный ключ. Вот описание
используемых флагов:

  • -s user_ca: указывает приватный ключ CA, используемый для подписи.
  • -I tatooine@proglib.io: буквенно-цифровая строка, которая будет видна в логе SSH. Для точной идентификации пользователя рекомендуем использовать адрес электронной почты или логин.
  • -n palpatine, tatooine: указывает разделенный запятыми список участников, для проверки подлинности которых будет действителен сертификат. В примере мы предоставляем сертификат доступа как для palpatine, так и для tatooine.
  • -V +1d: указывает срок действия сертификата, в данном случае +1d означает 1 день.

Если нужно увидеть параметры подписи сертификата,
используйте ssh-keygen -L:

            $ ssh-keygen -L -f user-key-cert.pub
user-key-cert.pub:
        Type: ssh-rsa-cert-v01@openssh.com user certificate
        Public key: RSA-CERT SHA256:egWNu5cUZaqwm76zoyTtktac2jxKktj30Oi/ydrOqZ8
        Signing CA: RSA SHA256:tltbnMalWg+skhm+VlGLd2xHiVPozyuOPl34WypdEO0 (using ssh-rsa)
        Key ID: "palpatine@proglib.io"
        Serial: 0
        Valid: from 2020-03-19T16:33:00 to 2020-03-20T16:34:54
        Principals: 
                tatooine
                palpatine
        Critical Options: (none)
        Extensions: 
                permit-X11-forwarding
                permit-agent-forwarding
                permit-port-forwarding
                permit-pty
                permit-user-rc

Настройка
SSH для проверки подлинности

После
того как сертификат подписан, нужно сообщить серверу, что можно доверять пользователским сертификатам. Копируем user_ca.pub
в директорию /etc/ssh, поправляем права и добавляем в конфиг /etc/ssh/sshd_config строку:

            TrustedUserCAKeys /etc/ssh/user_ca.pub

Как раньше, перезагружаем sshd с помощью systemctl restart sshd. Теперь
сервер настроен на пропуск всех, кто представляет сертификат, выданный центром сертификации при подключении. Если сертификат хранится в том же
каталоге, что и ваш приватый ключ (указанный с флагом -i, например ssh -i
/home/tatooine/user-key palpatine @proglib.io),
он будет автоматически использоваться при подключении к серверам.

Проcмотр логов

Если вы
посмотрите в журнал sshd сервера, запустив journalctl -u sshd, то увидите имя используемого для аутентификации сертификата, а также данные центра сертификации:

            sshd[14543]: Accepted publickey for tatooine from 1.2.3.4 port 53734 ssh2: RSA-CERT ID palpatine@proglib.io (serial 0) CA RSA SHA256:tltbnMalWg+skhm+VlGLd2xHiVPozyuOPl34WypdEO0

Если
пользователь попытается войти в систему под логином, у которого нет доступа, в логе вы увидите такую ошибку:

            sshd[14612]: error: key_cert_check_authority: invalid certificate
sshd[14612]: error: Certificate invalid: name is not a listed principal

Если срок
действия сертификата истек, вы увидите следующую ошибку:

            sshd[14240]: error: key_cert_check_authority: invalid certificate
sshd[14240]: error: Certificate invalid: expired

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

Взгляните
на man ssh-keygen для новых идей.

Использование
SSH
Bastion Host

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

Переход к
использованию такого метода не должен быть трудной задачей, особенно если вы уже
применяете сертификаты. Все настройки совершаются через локальный конфиг:
~/.ssh/config.

Вот
пример принудительного использования SSH-доступа к любому хосту в домене
example.com, который будет перенаправлен через bastion-хост, в bastion.example.com:

            Host *.example.com
    ProxyJump bastion.example.com
    IdentityFile ~/user-key

Host bastion.example.com
    ProxyJump none
    IdentityFile ~/user-key

Вместе с bastion для своих подключений вы можете использовать
iptables (или другой *nix-вый файервол на ваш выбор) на серверах за bastion-ом,
для блокировки входящих SSH-соединений. Например, вот так:

            $ iptables -A INPUT -m state --state RELATED,ESTABLISHED -j ACCEPT
$ iptables -A INPUT -p tcp --dport 22 -s <public IP of the bastion> -j ACCEPT
$ iptables -A INPUT -p tcp --dport 22 -j DROP

Хорошая идея оставить второй SSH-сеанс активным – если что-то пойдет не так,
вы должны иметь возможность исправить ситуацию через установленное соединение.

Двухфакторная
аутентификация


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

Давайте установим подключаемый модуль аутентификации google-authenticator, который потребует
от пользователей на своем телефоне ввести код из приложения Google Authenticator. Вы можете скачать приложение для iOS и Android.

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

Установка
google-authenticator

В
системах на базе RHEL/CentOS можно установить модуль google-authenticator из
репозитория EPEL:

            $ sudo yum install https://dl.fedoraproject.org/pub/epel/epel-release-latest-7.noarch.rpm # for RHEL/CentOS 7, change for other versions
$ sudo yum install google-authenticator

Для
систем на базе Debian / Ubuntu решение доступно в виде пакета
libpam-google-authenticator:

            $ sudo apt-get install libpam-google-authenticator

Модуль
имеет множество опций. В интересах экономии
времени мы используем некоторые значения по умолчанию: запретить использование
одного и того же токена дважды, выдавать временные коды и ограничивать
пользователя максимум тремя входами в систему каждые 30 секунд. Настроим это
все одной командой:

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

Вы также
можете запустить google-authenticator без флагов и настроить его в интерактивном
режиме.

Выполнение
предоставит QR-код, который пользователь может сканировать с помощью приложения.

Если вам
потребуется изменить какие-либо настройки в будущем, или полностью удалить
функциональность, конфигурация будет сохранена в разделе
~/.google_authenticator.

Настройка
PAM для двухфакторной аутентификации

Чтобы
заставить систему использовать коды OTP (one-time password), нужно
отредактировать конфиг PAM sshd. Добавьте следующую строку в конец файла /etc/pam.d/sshd:

            auth required pam_google_authenticator.so nullok

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

В
завершение, измените методы аутентификации по умолчанию, чтобы SSH не
запрашивал у пользователей пароль, если они не представляют двухфакторный
токен. Эти изменения также вносятся в файл /etc/pam.d/sshd:

  • В RHEL/CentOS закомментируйте auth substack password-auth, добавив # в начало строки: #auth substack password-auth.
  • В Debian/Ubuntu, закомментируйте @include common-auth: #@include common-auth.
  • Сохранитесь.

Настройка
SSH для двухфакторной аутентификации

Для того
чтобы сервер требовал использования такой аутентификации, внесем несколько
изменений в /etc/ssh/sshd_config:

  • изменим ChallengeResponseAuthentication no на ChallengeResponseAuthentication yes, чтобы разрешить использование pam.
  • установим список допустимых методов аутентификации, добавив следующую строку в конец файла (или отредактировав строку, если она уже существует): AuthenticationMethods publickey,keyboard-interactive

На этом
этапе вы должны перезапустить sshd с помощью systemctl restart sshd. Убедитесь,
что вы оставили SSH-соединение открытым, чтобы при необходимости исправить ошибки. Перезапуск SSH оставит существующие соединения активными, но если есть проблема с конфигурацией, новые соединения могут быть запрещены.

Тестируем

Подключаемся
к bastion-у и видим приглашение:

            $ ssh bastion.example.com
Verification code:

Вводим код, представленный приложением Google Authenticator. Если вы проверите журнал
sshd и если все настроено верно, перед вами будет следующее:

            Mar 23 16:51:13 ip-172-31-33-142.ec2.internal sshd[29340]: Accepted keyboard-interactive/pam for gus from 1.2.3.4 port 42622 ssh2

Заключение

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

Источники

Специально для сайта ITWORLD.UZ. Новость взята с сайта Библиотека программиста