SSH на VPS для техподдержки: ключи, запрет паролей и защита

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

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

Разделение пользователей и учетных записей поддержки

Практика, которая экономит время при инцидентах: не логиниться в систему как root. Создайте отдельного пользователя (например, support) или несколько (например, support-prod, support-dev), а права выдавайте через sudo по необходимости.

Если у вас несколько команд или контуров, лучше разделить учетные записи по средам. Тогда запрет паролей SSH и другие настройки не становятся “общим зонтиком” для всего сразу.

Минимальный смысл такой схемы:

• отдельные логины для разных сред (prod/stage/dev);
• один логин на роль или на человека, если команда небольшая;
• root доступ отключен, а sudo выдается точечно.

Схема доступа: ключи, ограничения, логирование

Планируем доступ заранее, а не “как получилось”. В нем обычно есть:

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

Дальше в статье будет пошагово: сначала ключи, потом конфигурация sshd_config, затем ограничения и контроль.

Генерация и хранение ключей SSH: практика для команды поддержки

Ключи SSH — это не только “без паролей”. Это еще и управляемый актив: его можно отозвать, заменить, ограничить и проверить по журналам.

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

Какие ключи выбирать: ed25519 и отдельные пары на человека

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

• одна пара ключей на одного сотрудника;
• приватный ключ не отправляется в чатах и не хранится на общем диске;
• ключи меняются при увольнении или смене роли.

Если вы выдаете доступ подрядчику, не давайте ему общий ключ. Даже если это “проще администрировать”, инциденты потом дороже.

Перенос открытого ключа на сервер без лишних рисков

Есть два распространенных способа добавить открытый ключ в /home/<user>/.ssh/authorized_keys: через ssh-copy-id или вручную.

Вариант через ssh-copy-id обычно удобен, если у вас уже есть доступ с паролем на время настройки: «`bash ssh-copy-id -i ~/.ssh/id_ed25519.pub support@your-vps-ip «`

Ручной вариант полезен, когда ssh-copy-id недоступен или вы хотите точно контролировать содержимое:

1. на локальной машине открываете публичный ключ:

«`bash cat ~/.ssh/id_ed25519.pub «`

1. подключаетесь на сервер (временно по паролю или через консоль провайдера);
2. добавляете ключ в authorized_keys.

Содержимое authorized_keys должно быть одной строкой на ключ. Не добавляйте переносы “для красоты”.

Права на .ssh и authorized_keys: частая причина проблем

После добавления ключа проверьте права. SSH-сервер часто игнорирует authorized_keys, если права некорректны. Для типичного Linux-сервера логика такая:

• /home/<user>/.ssh должно быть с правами 700;
• файл /home/<user>/.ssh/authorized_keys — с правами 600;
• владелец — тот пользователь, под кем вы входите.

Пример команд: «`bash sudo mkdir -p /home/support/.ssh sudo nano /home/support/.ssh/authorized_keys # вставляете public key одной строкой sudo chown -R support:support /home/support/.ssh sudo chmod 700 /home/support/.ssh sudo chmod 600 /home/support/.ssh/authorized_keys «`

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

Запрет паролей SSH: настройка sshd_config без потери доступа

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

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

Минимальный безопасный набор директив

Конкретные параметры могут отличаться в зависимости от дистрибутива и версии OpenSSH, но базовый набор для SSH на VPS для техподдержки выглядит так:

• PasswordAuthentication no — запрет паролей
• PubkeyAuthentication yes — разрешить вход по ключам
• PermitRootLogin no — запрет входа root
• ChallengeResponseAuthentication no — отключение старых схем “челлендж-ответ”
• UsePAM yes — обычно оставляют, если вы используете PAM для sudo/учетных политик
• X11Forwarding no — если GUI-форвардинг не нужен
• AllowAgentForwarding no — снижает риск кражи через агент-форвардинг
• AllowTcpForwarding no — если туннели не требуются

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

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

«`conf PasswordAuthentication no KbdInteractiveAuthentication no ChallengeResponseAuthentication no

PubkeyAuthentication yes PermitRootLogin no

X11Forwarding no AllowAgentForwarding no AllowTcpForwarding no «`

Пошаговая смена настроек: сначала проверка, потом запрет

Порядок такой:

1. Создайте пользователя поддержки и добавьте ему ключ.
2. Откройте отдельную сессию к VPS по SSH с этим ключом.
3. Убедитесь, что вход работает и команды выполняются как ожидается.
4. Только после этого меняйте sshd_config и перезапускайте sshd.
5. Проверяйте, что с новой сессией все нормально, а вход по паролю больше не происходит.

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

PermitRootLogin, PasswordAuthentication и проверка через тестовую сессию

Обычно меняют именно PasswordAuthentication и PermitRootLogin, потому что это основные пути для получения доступа.

Проверка делается просто:

• попробуйте подключиться с отключенным ключом и убедитесь, что пароль не принимается;
• подключитесь заново уже с ключом и убедитесь, что это по-прежнему работает;
• проверьте, не осталось ли у root возможности логина.

Для перезапуска sshd на большинстве систем подходит: «`bash sudo systemctl reload sshd «` Если reload не применим, используйте restart. Но reload обычно безопаснее в плане минимальных прерываний.

Ограничения для поддержки: кто что может по SSH

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

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

Разрешить вход только нужным пользователям и по группам

Если у вас на сервере не все пользователи должны логиниться по SSH, ограничьте это на уровне sshd_config директивами.

Примеры, которые часто используют:

• AllowUsers support support-ops
• AllowGroups ssh-support

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

Если вы хотите гибкость, используйте блоки Match. Например, задавать разные политики для разных пользователей.

Ограничение переадресаций и форвардинга

По умолчанию SSH может поддерживать:

• агент-форвардинг (по сути, передача доступа к ssh-agent);
• TCP-туннели (локальная/удаленная переадресация портов);
• X11-форвардинг.

Для техподдержки это не всегда нужно. Поэтому безопасная стратегия:

• отключить то, что не используете;
• включать только для тех, кому реально требуется.

Типичный набор для защиты SSH на VPS:

• AllowAgentForwarding no
• AllowTcpForwarding no
• X11Forwarding no

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

Принудительная команда в authorized_keys для безопасных действий

Иногда поддержке нужен доступ “в коробке”: не произвольный шелл, а выполнение ограниченного набора команд. Для этого в authorized_keys можно использовать forced command.

Пример идеи (адаптируйте путь к скрипту под вашу систему): «`text command=»/usr/local/bin/support-shell»,no-port-forwarding,no-agent-forwarding,no-pty ssh-ed25519 AAAA… yourkey… «`

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

Важно: forced command требует аккуратной реализации скрипта. Он должен корректно передавать параметры, ограничивать команды и вести журнал действий.

Защита SSH на VPS на уровне сети и системы

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

Фаервол: доступ к порту 22 только с IP техподдержки

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

Подход:

• разрешить вход на порт 22 только с офисных IP, VPN-диапазонов или конкретных адресов инженеров;
• запретить остальным внешний доступ к порту.

Примерно это выглядит так (команды зависят от firewalld/ufw/iptables):

• allow tcp/22 from <вашиподсетитехподдержки>;
• deny tcp/22 from any.

Для команд, которые работают через VPN, это особенно эффективно: “внешний интернет” не видит SSH.

fail2ban и защита от перебора по паролям

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

Если у вас PasswordAuthentication no, брутфорс паролей потеряет смысл. Но fail2ban все равно полезен для:

• контроля массовых попыток;
• снижения шума в логах;
• блокировок IP, которые сканируют сервис.

Не стоит воспринимать fail2ban как “единственную защиту”. Это вспомогательный слой, который дополняет ключи и сетевую политику.

Обновления OpenSSH и контроль конфигурации

OpenSSH регулярно получает исправления. Поэтому базовая дисциплина для SSH на VPS:

• обновлять пакет openssh-server по стандартному процессу в вашей инфраструктуре;
• после обновлений делать короткую проверку: вход по ключу работает, запрет паролей не сломался, форвардинг соответствует ожиданиям.

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

Управление ключами: ротация, отзыв и аудит действий

Ключи не “настроили один раз”. Их нужно обслуживать как часть безопасности. Для техподдержки это особенно заметно: смена состава команды, удаленная работа, подрядчики, различная длительность доступа.

Как отзывать доступ быстро и без пауз

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

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

При увольнении или завершении проекта вы отзываетесь так:

1. находите строку конкретного public key в authorized_keys;
2. удаляете ее;
3. перезагружаете или reload sshd (обычно достаточно reload, но зависит от настроек);
4. при необходимости проверяете, что вход с соответствующего ключа больше невозможен.

Если на сервере тысячи ключей, заведите хотя бы внутреннюю “карту соответствий” (человек → fingerprint ключа). Вручную по одному это делать неудобно.

Ротация ключей и регламент для новых сотрудников

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

• новые сотрудники: создают ключи сами на своей машине, вы отправляете только public key;
• ключи хранятся в локальном хранилище, защищены passphrase (если вы используете её и настройки поддерживают);
• по расписанию или после событий (подозрение инцидента) ключи заменяются.

Не обязательно делать ротацию “каждый месяц”. Но иметь понятное правило полезно, чтобы команда не жила в режиме “когда-нибудь заменим”.

Где смотреть логи и какие события важнее всего

Логи SSH показывают не только попытки входа, но и детали по ошибкам. Для диагностики и аудита важны:

• успешные входы по ключам;
• неуспешные попытки (если где-то еще остался парольный вход);
• ошибки конфигурации (например, неверные права в .ssh);
• события, связанные с sudo (если вы используете sudo и ведете лог).

На Debian/Ubuntu обычно смотрят /var/log/auth.log, на других дистрибутивах — /var/log/secure. Ваша задача — убедиться, что вы точно знаете, где ваши логи и как их читать.

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

Типичные ошибки при настройке SSH на VPS для техподдержки

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

• Отключили PasswordAuthentication, но не проверили вход по ключу заранее

Решение: откройте вторую сессию по ключу и только потом меняйте конфигурацию.

• Добавили ключ не тому пользователю

Решение: убедиться, что ключ добавлен в authorized_keys конкретного логина, под которым вы входите.

• Неправильные права на .ssh и authorized_keys

Решение: .ssh 700, authorized_keys 600, владелец верный. Проверьте chown.

• Забыли про PermitRootLogin и попытались логиниться root

Решение: логиниться под support-пользователем, а root не включать.

• Включили запреты на форвардинг, но команда нуждается в туннелях

Решение: включайте AllowTcpForwarding и AllowAgentForwarding только для тех, кому это нужно, через Match.

• Подключались в тестовом режиме и “по привычке” пытались использовать пароль

Решение: тренировка команды: заранее объяснить правила входа и что пароль на SSH больше не работает.

• Нет фаервола, SSH открыт всем на порт 22

Решение: хотя бы ограничить доступ по IP/подсетям техподдержки.

• Нет дисциплины по ключам (общий ключ на всех)

Решение: отдельные ключи на человека или роль, чтобы отзыв и аудит не превращались в ручную боль.

Чек-лист внедрения: SSH с ключами и запретом паролей

Можно идти по этому списку в том же порядке, чтобы снизить риск потерять доступ.

• Создать пользователей техподдержки на VPS и отдельные учетные записи под средами (если нужно).
• Добавить каждому пользователю его ключ SSH в /home/<user>/.ssh/authorized_keys.
• Проверить права на .ssh и authorized_keys (700 и 600, правильный владелец).
• Открыть сессию по ключу и подтвердить, что вход и выполнение команд работают.
• В sshd_config отключить PasswordAuthentication и включить PubkeyAuthentication.
• Отключить PermitRootLogin, если у вас нет осознанного сценария для root.
• Отключить форвардинг и X11, если команда не использует эти функции.
• Настроить фаервол: разрешить доступ к порту 22 только с IP техподдержки/VPN.
• Добавить fail2ban (как вспомогательный слой) и проверить логи.
• После изменений сделать reload sshd и повторно проверить вход по ключу.
• Включить мониторинг логов и определить, кто отвечает за аудит событий.
• Ввести регламент по добавлению, ротации и отзыву ключей.

Итог: практичная защита SSH на VPS для техподдержки

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

Сделайте первый шаг уже сейчас: подготовьте вход по ключу для одного пользователя техподдержки, проверьте его в отдельной сессии, затем отключите PasswordAuthentication и только после этого применяйте остальные ограничения. Так вы улучшите защиту SSH на VPS без риска “отрезать” себя от сервера.