На какой порт переносить SSH?

На любой свободный выше 1024 — 52200, 47820, что угодно. Порты ниже 1024 требуют root для привязки, что для sshd не проблема, но сужает выбор. Избегайте 2222 — это первое, что пробуют после 22, — и перед сменой проверьте через ss -tlnp, что порт никем не слушается.

Почему SSH всё ещё слушает 22 после правки sshd_config?

В Ubuntu 22.10 и новее и в Debian 12 и новее может быть включён ssh.socket, и тогда слушающим сокетом владеет systemd, а директива Port игнорируется. Проверьте через systemctl is-enabled ssh.socket; если включён — переопределяйте ListenStream в юните сокета, сначала пустой строкой ListenStream=, чтобы очистить унаследованное значение.

Нужно ли настраивать SELinux при смене порта SSH?

В RHEL, CentOS, AlmaLinux, Rocky и Fedora с SELinux в enforcing — да: sshd откажется вставать на неразмеченный порт. Выполните semanage port -a -t ssh_port_t -p tcp до перезагрузки конфига. Пропуск этого шага — самая частая причина неудачной смены порта в семействе RHEL, и проявляется она уже после того, как вы сделали reload.

Нестандартный порт SSH действительно безопаснее?

Ровно настолько же безопасен, как 22, но с гораздо меньшим фоновым шумом. Порт не является средством контроля доступа: SSH отправляет баннер версии открытым текстом, поэтому любой сканер полного диапазона опознаёт службу с первого раза, а Shodan непрерывно индексирует SSH на нестандартных портах. Безопасность определяется тем, что обрабатывает попытки, а не тем, куда они приходят.

Смена порта SSH с 22: что это чинит, а что нет

Перенос SSH с порта 22 радикально снижает объём атак и почти ни от чего не защищает. Как сделать это, не заперев себя снаружи, включая два шага, которые пропускает большинство инструкций.

7 мин чтенияОбновлено 2026-08-26

Честное резюме

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

Оба утверждения верны, потому что отвечают на разные вопросы. Падение объёма реально, измеримо и полезно. Защита близка к нулю против любого, кто потратит тридцать секунд на то, чтобы посмотреть.

Стоит ли делать? Обычно да — как снижение шума, рядом с настоящей защитой и никогда вместо неё.

Что это действительно останавливает

Подавляющая часть атакующего трафика по SSH идёт от нецелевых сканеров, делающих одно: подключение к порту 22 по крупным диапазонам IP и перебор учётных данных на всём, что ответило. Порты они не сканируют: проверить один порт по всему интернету на порядки дешевле, чем 65 535, а машин на 22 более чем достаточно, чтобы их занять.

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

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

Что это не останавливает

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

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

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

Есть и активный минус: нестандартные порты ломают вещи. Корпоративные фаерволы, разрешающие исходящий 22, заблокируют исходящий 52200, и вы узнаете об этом от коллеги, который не может выкатить релиз.

Как сменить порт и не запереть себя снаружи

Два шага пропускает большинство инструкций, и оба запрут вас на современном дистрибутиве: разметка порта в SELinux в семействе RHEL и активация через сокет systemd в свежих Debian и Ubuntu, где sshd больше не слушает сам.

Держите текущую сессию открытой всё время и идите по порядку:

bash

NEWPORT=52200

# 1. СНАЧАЛА фаервол — до того как sshd куда-то переедет
sudo ufw allow ${NEWPORT}/tcp                                          # Debian/Ubuntu с ufw
sudo firewall-cmd --permanent --add-port=${NEWPORT}/tcp && sudo firewall-cmd --reload   # семейство RHEL

# 2. SELinux: разметить порт, иначе sshd откажется на него встать (RHEL)
sudo semanage port -a -t ssh_port_t -p tcp ${NEWPORT} || \
  sudo semanage port -m -t ssh_port_t -p tcp ${NEWPORT}

# 3. Сказать sshd. Пока оставляем и 22 — два порта, чтобы вас не отрезало
printf 'Port 22\nPort %s\n' "$NEWPORT" | sudo tee /etc/ssh/sshd_config.d/20-port.conf
sudo sshd -t                            # проверка синтаксиса до любой перезагрузки

# 4. Активация через сокет: в свежих Debian/Ubuntu sshd не слушает сам
systemctl is-enabled ssh.socket 2>/dev/null && \
  echo 'ssh.socket включён — ListenStream надо переопределять там, см. заметку ниже'

sudo systemctl reload ssh               # 'sshd' в семействе RHEL

Довести переезд до конца

Теперь проверьте из второго терминала на новом порту — ssh -p 52200 user@server — прежде чем трогать что-либо ещё. Только когда это заработает, убирайте Port 22 из конфигурации, делайте reload ещё раз и закрывайте старое правило фаервола.

Затем обновите всё, где хранился старый порт: записи в ~/.ssh/config, скрипты деплоя, CI-раннеры, инвентари Ansible, проверки мониторинга, задания бэкапа и документацию команды. Смена порта, сломавшая ночной бэкап, хуже, чем несменённый порт.

Не убирайте порт 22 до того, как убедитесь, что новый работает снаружи вашей сети. Внутри LAN работает и так, и так — именно этим люди себя и убеждают, что всё в порядке.

Чем это дополнять

Смена порта снижает шум. Кто-то всё равно должен обрабатывать долетающие попытки — а после смены порта долетают те, кто искал конкретно вас, то есть ровно те, что вас действительно волнуют.

SSH Protector определяет реальный порт SSH по эффективной конфигурации sshd, а не считает, что это 22, — поэтому уже перенесённый сервер защищён без единой настройки, и правила перестраиваются, если порт сменится снова.

Меняйте порт ради читаемого лога. Держите защиту ради трафика, который найдёт вас всё равно.

FAQ

На какой порт переносить SSH?: На любой свободный выше 1024 — 52200, 47820, что угодно. Порты ниже 1024 требуют root для привязки, что для sshd не проблема, но сужает выбор. Избегайте 2222 — это первое, что пробуют после 22, — и перед сменой проверьте через ss -tlnp, что порт никем не слушается.
Почему SSH всё ещё слушает 22 после правки sshd_config?: В Ubuntu 22.10 и новее и в Debian 12 и новее может быть включён ssh.socket, и тогда слушающим сокетом владеет systemd, а директива Port игнорируется. Проверьте через systemctl is-enabled ssh.socket; если включён — переопределяйте ListenStream в юните сокета, сначала пустой строкой ListenStream=, чтобы очистить унаследованное значение.
Нужно ли настраивать SELinux при смене порта SSH?: В RHEL, CentOS, AlmaLinux, Rocky и Fedora с SELinux в enforcing — да: sshd откажется вставать на неразмеченный порт. Выполните semanage port -a -t ssh_port_t -p tcp <порт> до перезагрузки конфига. Пропуск этого шага — самая частая причина неудачной смены порта в семействе RHEL, и проявляется она уже после того, как вы сделали reload.
Нестандартный порт SSH действительно безопаснее?: Ровно настолько же безопасен, как 22, но с гораздо меньшим фоновым шумом. Порт не является средством контроля доступа: SSH отправляет баннер версии открытым текстом, поэтому любой сканер полного диапазона опознаёт службу с первого раза, а Shodan непрерывно индексирует SSH на нестандартных портах. Безопасность определяется тем, что обрабатывает попытки, а не тем, куда они приходят.