Привет, Хабр! На связи Кирилл, сисадмин в Selectel. Если вы только начинаете свой путь в системном администрировании, то наверняка задумывались, что происходит «под капотом» Linux при вводе логина и пароля. Давайте заглянем в потроха системы, чтобы: разобраться, как она удостоверяется в подлинности пользователя; сравнить привычные пароли и SSH-ключи; настроить сервер для безопасной работы. Добро пожаловать под кат.

Используйте навигацию, если не хотите читать текст целиком:
→ Аутентификация и авторизация
→ Типы аутентификации
→ Почему же SSH-ключи лучше паролей
→ Неутешительная статистика
→ Настройка доступа по SSH-ключу
→ Ни на что не намекаю, но…

Аутентификация и авторизация

В современных дистрибутивах Linux за проверку полномочий пользователя отвечает подсистема PAM (Pluggable Authentication Module) — гибкий механизм, который поддерживает разные способы аутентификации. Например, при входе пользователя пароль может проверяться как локально (файлы /etc/passwd и /etc/shadow), так и с привлечением внешних сервисов (LDAP, ключи SSH и других). Выбор зависит от конфигурации PAM и настроек администратора системы. Когда проверка успешно пройдена, для пользователя устанавливается сеанс с соответствующими правами.

Уверен, вы и без меня это знаете, но давайте повторим еще раз.

• Аутентификация — это процесс подтверждения личности пользователя. Система удостоверяется, что он — действительно тот, за кого себя выдает. Для этого нужны учетные данные — например, пара логин‑пароль или криптографический ключ.
• Авторизация — это процесс предоставления прав доступа после успешной аутентификации. Теперь система решает, что именно пользователь может делать: какие файлы читать и команды выполнять, а также устанавливает для него другие подобные разрешения и ограничения.

Типы аутентификации

Linux поддерживает несколько способов аутентификации. Как несложно догадаться даже по заголовку статьи, два наиболее распространенных из них: парольная и по SSH-ключу.

Парольная аутентификация

Это классический способ входа в систему. Указывая свой логин, пользователь как бы говорит ОС: «Привет! Я ». Затем он приводит пруфы, вводя пароль. И при локальной работе, и при удаленном доступе процесс парольной аутентификации практически идентичен. Несущественное отличие — интерфейс для ввода учетных данных: это может быть GUI‑форма или терминал. В любом случае по комбинации логина и пароля система удостоверяется в подлинности пользователя и авторизует его.

В Debian и дистрибутивах‑наследниках, таких как Ubuntu или SelectOS, учетные записи пользователей хранятся в файле /etc/passwd, а хэши паролей — в защищенном /etc/shadow. Прямой доступ к последнему разрешен только привилегированным процессам — запущенным от имени root. Однако даже они не смогут увидеть пароли ни при каких обстоятельствах — хранятся только их хэши.

Специальный модуль PAM необратимо преобразовывает введенный пароль и сравнивает полученный результат с сохраненным в /etc/shadow хэшем. Применяемый алгоритм и «соль» также указываются в строке с хэшем. В современных дистрибутивах Linux обычно используется SHA-512 с «солью» вместо устаревшего DES/MD5. Таким образом, проверка выполняется безопасно — реальные пароли не передаются и не хранятся в открытом виде.

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

Как я сказал выше, парольная аутентификация может быть как локальной, так и удаленной. В последнем случае, как правило, используется протокол SSH (Secure Shell). Конечно, его механизм может использоваться не только для парольной аутентификации — и об этом мы подробно поговорим ниже. Важно знать, что в основанных на Debian-дистрибутивах OpenSSH-сервер по умолчанию разрешает вход по паролю всем, кроме, возможно, пользователя root. Параметр PasswordAuthentication в файле /etc/ssh/sshd_config управляет этой возможностью: значение yes разрешает парольную аутентификацию, no — запрещает.

Протокол SSH шифрует весь трафик, поэтому сам пароль передается на сервер в защищенном виде. Демон sshd на сервере расшифровывает полученный пароль. Далее модуль PAM вычисляет хэш и соотносит его с записью в /etc/shadow.

У паролей есть несколько существенных недостатков

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

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

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

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

Управление паролями на множестве серверов становится нетривиальной задачей. Для десятков машин администратору пришлось бы хранить где-то список разных сложных паролей, регулярно их менять, следить за сроком действия и тому подобным. Такая сложность вызывает неудобство и чревата ошибками. Один скомпрометированный пароль — и под угрозой вся система, если не включена двухфакторная защита.

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

SSH-авторизация: что это такое и как работают SSH-ключи

SSH (Secure Shell) — сетевой протокол для защищенного удаленного доступа к системе. Его название переводится как «безопасная оболочка». Протокол обеспечивает шифрование соединения и проверку подлинности обеих сторон. SSH дает возможность подключиться к удаленному серверу и выполнять команды в терминале так же, как если бы использовалось локальное подключение на той же машине.

Работа строится по модели клиент-сервер: на удаленном узле должен быть запущен SSH-демон (служба sshd), который «слушает» сетевой порт (стандартно 22) и ожидает входящих подключений. На стороне пользователя используется SSH-клиент — программа, которая инициирует соединение, проходит аутентификацию, а также шифрует и дешифрует данные.

OpenSSH — наиболее популярная реализация SSH в Linux. В дистрибутивах, унаследованных от Debian, клиентская часть OpenSSH уже присутствует в системе. Для развертывания серверной части достаточно установить пакет openssh-server — служба запустится автоматически и сможет принимать входящие SSH-подключения. Конфигурация сервера хранится в файле /etc/ssh/sshd_config, где задаются параметры аутентификации, используемые протоколы шифрования и прочие настройки.

Для подключения по SSH пользователь вводит команду вида:

ssh <user>@<host>

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

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

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

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

Во время подключения по SSH сервер отправляет клиенту случайную строку (челлендж), которую клиент подписывает своим приватным ключом и отправляет обратно. Сервер, используя публичный ключ, проверяет подпись. Если она корректна, доступ предоставляется, в противном случае — отклоняется. Таким образом, подтверждается владение приватным ключом без передачи каких-либо секретных данных по сети. Пароль при этом не нужен вовсе.


Рекомендуется, чтобы каждый администратор или процесс заводил свою пару ключей. В файле authorized_keys на сервере можно записать несколько публичных ключей, по одному на каждого пользователя, которому разрешен доступ. Тогда в случае компрометации какого‑либо ключа отозвать придется только его — доступ остальных никак не будет затронут.

При необходимости, SSH-ключи можно дополнить вспомогательной защитой. Один из примеров — ограничение возможности входа только с определенных IP-адресов. Другой вариант — добавление двухфакторной авторизации, ведь протокол SSH позволяет требовать одновременно и ключ, и одноразовый код, получаемый, например, через PAM-модуль Google Authenticator.

Почему же SSH-ключи лучше паролей

Вот основные аргументы в пользу ключей.

Стойкость к взлому

Пароль длиной 8-10 символов можно относительно быстро подобрать. Это делается или перебором, или с помощью словаря, особенно если пароль распространенный. SSH-ключ же — это последовательность из сотен случайных символов, чаще всего длиной 2 048 или 4 096 бит. Длина и энтропия таких ключей на порядки превышают даже самые сложные пароли.

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

Конфиденциальность приватного ключа

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

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

Устойчивость к компрометации сервера и утечкам данных

Злоумышленник может скомпрометировать сервер, где хранятся хэши паролей — например, получит права root и скопирует файл /etc/shadow. Тогда он может попытаться взломать пароли офлайн, перебирая комбинации и сравнивая получающийся хэш. При использовании ключей такая атака бессмысленна: на сервере нет секретов, пригодных для подбора, как нет и приватного ключа.

Компрометация одного сервера не дает злоумышленнику инструментов для прямого доступа к другим узлам пользователя. Приватный ключ нигде централизованно не хранится и не может утечь вместе с чужими данными. Таким образом, утечка баз паролей или повторное использование пароля (reuse-атака) не угрожают системе, где вход осуществляется по ключам.

Исключение человеческого фактора

Ключ не нужно помнить, его нельзя выбрать «слишком простым» случайно. Пользователь не сможет установить тривиальный SSH-ключ подобно тому, как может придумать слабый пароль вроде «12345». Уходит риск использования легко угадываемых или слабых комбинаций.

Удобство, гибкость и автоматизация

С SSH-ключами можно использовать одну пару ключей для доступа к разным своим серверам (либо сгенерировать отдельную пару для разных групп машин). Это гораздо удобнее управления множеством уникальных паролей для каждого ресурса. Не нужно каждый раз вводить пароль при подключении: аутентификация происходит автоматически.

Удобство особенно ощутимо при частых подключениях или использовании автоматизированных скриптов и систем оркестрации. К примеру, Ansible и Terraform используют ключи для доступа к серверам без участия человека. Такой подход безопаснее, чем хранение паролей в скриптах в открытом виде.

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

Концептуальное преимущество: владение против знания

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

Конечно, идеальный вариант — это комбинация методов. Например, можно использовать закрытый ключ на аппаратном токене вместе с PIN-кодом или в связке с одноразовым кодом. Однако в контексте выбора «пароль или ключ» последний выигрывает по всем параметрам.

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

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

Неутешительная статистика

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

Первая атака подбором пароля наблюдается уже через 10-15 минут после подключения свежеразвернутого сервера к сети. Об этом говорят данные наших ИБ‑специалистов в Selectel. Далее атаки продолжаются постоянно, сканируя машину в поисках открытых SSH-портов.

В год фиксируются десятки миллионов попыток входа. Компания Rapid7 провела исследование на ловушках (honeypot) SSH и RDP и предоставила данные за 2021-2022 годы. Было выявлено свыше 216 000 уникальных IP-адресов атакующих и более 512 000 паролей, использованных в этих атаках. Подавляющее большинство паролей — распространенные, которые даже собраны в специальные словари. В первую пятерку вошли: 123456, nproc, test, qwerty и password — то есть откровенно слабые значения.

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

81% взломов аккаунтов в 2022 году были вызваны слабыми, повторно используемыми или украденными паролями. Об этом рассказывает отчет LastPass. Иными словами, восемь из десяти успешных атак на информационные системы, так или иначе, эксплуатировали уязвимости, связанные с паролями. Это могут быть фишинговые кражи, утечки баз данных паролей, перебор простых комбинаций или использование паролей, украденных с других сервисов.

2/3 атак на облачные сервисы связаны с уязвимыми учетными данными — еще один тревожный сигнал. Причина та же — отсутствие или слабый пароль, о чем говорят данные Google Cloud за вторую половину 2023 года. Пароли остаются «слабым звеном», через которое злоумышленники получают первоначальный доступ перед развитием атаки.

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

• сложный ключ и современный алгоритм,
• защита приватного ключа,
• отключение входа по паролю.

Статистика атак подтверждает: переход на аутентификацию по криптографическим ключам кардинально снижает вероятность взлома.

Настройка доступа по SSH-ключу

В дистрибутивах на основе Debian OpenSSH-сервер поддерживает авторизацию по ключам по умолчанию (директива PubkeyAuthentication yes включена). Чтобы настроить вход по SSH-ключу, требуется сгенерировать ключ и установить публичный ключ на сервер. Ниже приведен общий порядок.

1. Генерация ключевой пары на клиенте. В терминале пользователя на локальной машине, с которой будет осуществляться доступ, выполните команду генерации ключа. Например, для RSA 3 072 бит (значение по умолчанию для OpenSSH), команда будет следующая:

ssh-keygen -t ed25519 -C

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

Enter file in which to save the key (/home/alex/.ssh/id_ed25519): .ssh/my_key

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

2. Установка публичного ключа на сервере. Проще всего сделать это утилитой ssh-copy-id, если пока еще доступен вход по паролю. По умолчанию утилита пытается скопировать первый найденный ключ — обычно это ~/.ssh/id_rsa.pub или ~/.ssh/id_ed25519.pub. Если ключей несколько, нужно указать, какой из них использовать. Скопируем ключ из нашего примера — my_key.pub.

ssh-copy-id i ~/.ssh/my_key.pub <имя_пользователя>@<адрес_сервера>

Утилита попросит текущий пароль пользователя на сервере, а затем автоматически скопирует содержимое my_key.pub в файл ~/<имя_пользователя>/.ssh/authorized_keys на сервере. Если директория .ssh или файл authorized_keys не существуют, они будут созданы.

Можно также скопировать публичный ключ вручную. Для этого сохраняем его в подходящее место на сервере, а затем добавляем к содержимому ~/.ssh/authorized_keys. Например, можно воспользоваться утилитой scp (Secure Copy):

scp ~/.ssh/my_key.pub <имя_пользователя>@<адрес_сервера>:~/
cat ~/my_key.pub >> ~/.ssh/authorized_keys

Разумеется, чтобы выполнить подобную операцию, у пользователя должен быть и доступ на сервер, и соответствующие права.

3. Проверка входа по ключу. Проверим работоспособность SSH — попробуем подключиться к серверу, указав ключ:

ssh -i ~/.ssh/my_key.pub <имя_пользователя>@<адрес_сервера>

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

4. Отключение парольной авторизации (рекомендуется). Добившись работающего входа по ключу, запретим вход по паролю — так мы избавимся от недостатков парольной аутентификации и получим все преимущества аутентификации по ключу. Отредактируем на сервере конфигурационный файл SSH /etc/ssh/sshd_config.

Убедитесь, что вход по ключам действительно работает, прежде чем отключать пароль. Иначе доступ к серверу получится восстановить только через KVM-консоль или в Rescue Mode.

Изменим параметр PasswordAuthentication — его значение должно стать no. Убедимся, что также отключена опция ChallengeResponseAuthentication, которая отвечает за устаревшую аутентификацию keyboard-interactive. Чтобы изменения вступили в силу, перезапустим службу SSH:

sudo systemctl restart ssh

Сервер перестанет принимать пароль после перезагрузки. Теперь вход — только по ключам.

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

• id_rsa или id_ed25519 — приватный ключ (название по умолчанию зависит от применявшегося алгоритма);
• id_rsa.pub или id_ed25519.pub — публичный ключ.

Эти файлы рекомендуется защищать от несанкционированного доступа. Каталог ~/.ssh должен иметь права 700, а приватный ключ — 600 (только владелец может читать и записывать). Если права доступа настроены неверно, сервер SSH может отказать во входе по ключу из соображений безопасности.

Также частая практика — установка парольной фразы (passphrase) на приватный ключ при его создании. Тогда он будет храниться в зашифрованном виде. Чтобы воспользоваться ключом, необходимо будет ввести парольную фразу. Такая мера защищает приватный ключ даже при краже файла или всего устройства.

Чтобы не вводить парольную фразу каждый раз, можно воспользоваться утилитой ssh-agent — ввод passphrase потребуется только одноразово за сессию:

ssh-add ~/.ssh/my_key

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

Ни на что не намекаю, но…

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

Все добавленные секреты хранятся в зашифрованном виде с использованием стойких алгоритмов, таких как AES-256-GCM. Доступ к хранилищу имеет только авторизованный пользователь — владелец аккаунта. Обмен данных с хранилищем шифруется по протоколу TLS, что предотвращает их перехват при использовании API или веб-интерфейса. Таким образом, приватный SSH-ключ, помещенный в менеджер, лежит в зашифрованном виде и защищен на уровне инфраструктуры.

Менеджер секретов интегрируется с системой проектов Selectel. Можно создавать несколько пользователей, проектов, задавать роли и права доступа к определенным проектам. Таким образом, есть возможность разрешить конкретным пользователям доступ только к нужным проектам, исключив избыточные привилегии.

Все операции с секретами логируются — для аудита доступна вся история действий, что повышает контроль и отслеживаемость. Можно увидеть, кто и когда извлекал или изменял ключ. Доступ к самой панели Selectel защищен как минимум паролем, а при включении 2FA — еще и одноразовыми кодами, что также рекомендуется.

Работа с хранилищем возможна через веб-интерфейс панели, через API или с помощью Terraform-провайдера. Это означает, что есть способ автоматически подключать секреты в пользовательские приложения и инфраструктурные сценарии. Например, вместо хранения SSH-ключа в скриптах CI/CD, его лучше запросить из менеджера секретов через API во время развертывания — ключ передается в зашифрованном виде и сразу доступен для подключения. При этом ключ не хранится на диске разработчика или в репозитории — он всегда находится только в защищенном хранилище и в памяти приложений на момент использования.

Менеджер секретов может безопасно защищать самые разные данные: пароли, учетные данные СУБД, TLS-сертификаты, приватные ключи к ним и многое другое. Такая централизация управления всеми секретами проекта решает множество задач. Например, для подключения к серверу используется SSH-ключ, а к базе данных — пароль. И ключ, и пароль находятся в менеджере секретов. В результате администратор не держит критичные секреты на своем компьютере или в блокноте — они все в надежном хранилище.

Сервис менеджер секретов предоставляется бесплатно для клиентов Selectel. Это современный подход к управлению чувствительными данными, соответствующий рекомендациям безопасности:

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

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