Вопрос безопасности SSH — тема, на которой не утихают дискуссии уже много лет. В свежей заметке «Thoughtson having SSH allow password authentication from the Internet» системный администратор Крис Зибенманн (Chris Siebenmann) делится мыслями о том, стоит ли оставлять парольную аутентификацию включённой для SSH, даже если сервер доступен из внешней сети. На первый взгляд может показаться, что «ключи и только ключи» — единственно верный путь, однако автор приводит несколько нюансов, из-за которых это решение не всегда идеально. Ниже — мой взгляд на ситуацию с небольшими техническими подробностями.
Почему общественное мнение склоняется к использованию «только ключи»
В интернете давно бытует мнение, что если ваш SSH «торчит» в публичную сеть, то парольная аутентификация должна быть категорически отключена. Аргументы очевидны:
- 🔒 Атакующие перебирают пароли
Каждый, кто администрировал сервер в публичной сети, видел постоянный поток неудачных попыток логина с типичными именами пользователей: root, admin, user и т. п. Брутфорс скриптов всегда активен. - 🛡️ Потенциально слабые пароли
Если пароль оказался коротким или легко подбираемым, велик риск взлома. Да, регулярные «scanners» не дают слишком много попыток в секунду, однако со временем могут найти что-то угрожающее. - 🌍 Опасные «дефолтные» учётные записи
Некоторые ПО или образы ОС создают стандартные логины с известными паролями (admin:admin, user:user и т. д.), что даёт хакерам лёгкий путь внутрь, если парольная аутентификация включена.
Контраргументы: когда пароль может быть не так уж плох
Однако, как отмечает Крис, реальный прирост безопасности от полного запрета паролей может быть не столь велик, если учитывать нюансы:
- ⚙️ Темп перебора по SSH
Атака «брутфорсом» по SSH обычно сильно лимитирована — демон SSH сам по себе не позволяет делать сотни попыток в секунду (добавьте ещё и fail2ban, iptables, SSH RateLimit и т. п.). При достаточно надёжном пароле вероятность «угадать» его за разумное время очень мала. - 🔗 Необходимость резервного доступа
Представьте, что вы системный администратор, и вам срочно нужно подключиться к серверу из «чужого» места, где у вас нет приватного ключа. Если ключи — единственный метод входа, это становилось бы непреодолимым барьером. Да, многие скажут: «Админ всегда носит ключи на USB», «использует SSH-agent forwarding» и т. д., но жизнь бывает непредсказуемой. - 🖥️ Возможность локальной аутентификации
Некоторые админы или разработчики хотят иметь возможность залогиниться по паролю хотя бы из локальной сети, не переживая за расшаривание ключей между машинами. Тут можно настроить SSH-доступ только для нескольких определённых аккаунтов и только по паролю.
Какие риски действительно устраняет отказ от паролей
- 🤫 Утечка и расшифровка
Если кто-то украдёт хеши паролей с сервера (или из резервных копий), то при достаточно сложном пароле шансы взлома минимальны. Однако полностью убрать риск можно, убрав вообще поддержку «password auth» извне. - 🔧 Уязвимости в PAM / механизме аутентификации
Вдруг в паролях всплывёт критическая ошибка — например, уязвимость в PAM-модулях, позволяющая удалённый эксплойт без ввода настоящих учётных данных. С чисто ключевой аутентификацией этот класс проблем уже не страшен (или риск будет меньше). - 🚫 Защита от «левых» служебных учёток
Некоторые недобросовестные приложения могут создавать учётные записи с предсказуемыми логинами и дефолтными паролями. Если разрешена аутентификация по паролю — это становится «чёрным ходом». И наоборот, отключив пароли, мы гарантируем, что такие «фантомные» учётные записи не пропустят злоумышленника.
Советы по настройке
- 🔑 Используйте ключи там, где это возможно
Для обычного рабочего сценария (подключение с личного ноутбука или другого заранее настроенного устройства) связка публичный/приватный ключ действительно удобна и безопасна. - 🪙 Ограничьте пароль для конкретных случаев
Можно настроить SSH так, чтобы пароли принимались только для выбранных учётных записей (например, своего личного пользователя) и ни для каких других. Это снимает риск с дефолтных «admin/admin». - 🎛️ Защитные механизмы
Активируйте fail2ban, настройте RateLimit, используйте нестандартный порт (не панацея, но снижает шум), а также следите за логами. Эти меры здорово сокращают вероятность успешного брутфорса. - 💻 Подумайте о сценариях «что, если?»
Как будете входить, если ключ потерян? Или вы на другом конце мира без флешки с ключом? Иногда парольная «запаска» — лучше, чем вообще ничего.
Личное мнение
Для большинства приватных пользователей и многих серверов в продакшене я сам предпочитаю разрешать только вход по ключу, а пароль либо вообще отключать, либо разрешать лишь внутри VPN/локалки. Но в жизни бывают исключения, особенно если вам нужно входить на рабочую машину из непредвиденных мест. Крис Зибенманн подчёркивает, что лишаться возможности срочного входа паролем может быть критично для админа, пытающегося починить что-то в 3 часа ночи, сидя за чужим компьютером.
В конце концов, всё упирается в баланс безопасности и удобства. Точно так же, как мы не даём пользователю вбивать 100-значный пароль на каждом входе, хотя формально это повысило бы защиту, мы не обязаны «жертвовать» всеми видами аутентификации для малейшего прироста безопасности, если у нас для этого нет реальных предпосылок.
Ссылки и источники
- Оригинальный пост Криса Зибенманна (Chris Siebenmann):
Thoughts on having SSH allow password authentication from the Internet
Вывод: запрет паролей в SSH и переход только на ключи — разумная практика для многих случаев, но не универсальное «лекарство». Администраторам стоит понимать плюсы и минусы, а не слепо следовать мантре «включил — молодец, выключил — некомпетентен». Главное — держать пароли сложными, логи под присмотром, а ключи в безопасном месте.