Смена порта SSH без потери доступа: sshd, активация через сокет и SELinux

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

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

Все сведения относятся к Debian 13 (trixie), Debian 12 (bookworm), Ubuntu 24.04 LTS и Ubuntu 22.04 LTS. Отдельный раздел посвящён SELinux на системах RHEL, таких как AlmaLinux и Rocky Linux. Команды рассчитаны на работу от root. Если вы работаете под обычным пользователем, ставьте перед каждой командой sudo. В качестве примера порта служит 2222, в качестве примера адреса 203.0.113.10.

Что другой порт даёт, а что нет

Прироста безопасности нет. Полное сканирование всех 65 535 портов всё равно найдёт службу, а идентификатор версии, который OpenSSH отправляет при подключении, и на порту 51022 сразу выдаёт, что это за служба. Смена порта не заменяет ни одной из мер, которые действительно работают: вход по ключу вместо пароля, отключённая парольная аутентификация, узко настроенный пакетный фильтр.

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

Издержки, которые надо заложить заранее. Каждому инструменту теперь нужно указание порта: скриптам резервного копирования, процедурам развёртывания, мониторингу. И момент, о котором умалчивает почти каждое руководство: корпоративные сети, гостиничный Wi-Fi и некоторые мобильные тарифы выпускают наружу лишь несколько портов, чаще всего 22, 80 и 443. Из таких сетей вы после смены порта можете вообще не попасть на свой сервер.

Коротко: делайте это, если хотите тихие журналы. Не делайте в расчёте на то, что так решается проблема безопасности.

Путь назад, ещё до того как вы что-то измените

1. Один раз откройте консоль в личном кабинете

У каждого KVM root-сервера и каждого выделенного сервера в KernelHost есть VNC-консоль в личном кабинете. Она подключена к экранному выводу системы и не зависит от сетевого стека сервера, поэтому неправильное правило файрвола её не заблокирует. Войдите туда один раз заранее и убедитесь, что знаете пароль root. Аварийный путь, который впервые пробуют уже в аварийной ситуации, никаким аварийным путём не является.

2. Два сеанса, и первый остаётся открытым

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

3. Таймер, который сам откатит изменение

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

systemd-run --on-active=15min --unit=ssh-portrollback /bin/sh -c 'rm -f /etc/ssh/sshd_config.d/20-port.conf /etc/systemd/system/ssh.socket.d/override.conf; systemctl daemon-reload; systemctl try-restart ssh.socket ssh.service'

Проверка: systemctl list-timers ssh-portrollback.timer покажет время срабатывания. Если всё получилось, отмените задание, иначе ваше изменение позже откатится прямо посреди работы:

systemctl stop ssh-portrollback.timer

Порядок, который не запирает снаружи

Эта последовательность построена так, что ни в один момент старый путь уже не закрыт, а новый ещё не открыт.

1. Выбрать порт и убедиться, что он свободен.
2. Сначала файрвол: открыть новый порт, старый оставить открытым.
3. Заставить sshd слушать оба порта.
4. При активации через сокет дополнительно поправить socket-юнит.
5. Перезапустить и проверить по открытому сокету.
6. Войти третьим, свежим сеансом через новый порт.
7. И только теперь убрать порт 22 и подтянуть инструменты.

Шаг 1: выбор порта

Только не 2222. Это самый частый запасной вариант, и массовые сканеры давно проверяют его заодно. Здесь мы берём его лишь как хорошо читаемый пример.

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

cat /proc/sys/net/ipv4/ip_local_port_range

Обычно вывод такой: 32768 60999. Порт из этого диапазона может быть временно занят исходящим соединением. Чаще всего обходится, но после перезагрузки, когда другие службы стартуют раньше sshd, попытка привязки завершается сообщением Address already in use, и сервер поднимается без SSH. Проявляется это нерегулярно, и причину искать неприятно.

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

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

ss -tlnp | grep -E ':2222 '
grep -w 2222 /etc/services

Шаг 2: сначала файрвол

Этот шаг идёт до настройки sshd, а не после. Открытый порт без службы за ним безобиден, а служба без открытого порта запрёт вас снаружи.

ufw allow 2222/tcp comment 'SSH новый'
ufw status verbose

Проверка: в выводе теперь должны стоять оба порта, причём каждый дважды: один раз для IPv4 и один раз с пометкой (v6). Если строки IPv6 нет, новый порт по IPv6 недоступен, а современные клиенты пробуют IPv6 первым. Подробности в нашем руководстве по файрволу UFW.

Кто ведёт nftables вручную, дописывает порт в свой файл правил, перезагружает его и проверяет по загруженному набору правил командой nft list ruleset | grep 2222. На системах RHEL с firewalld:

firewall-cmd --permanent --add-port=2222/tcp
firewall-cmd --reload
firewall-cmd --list-ports

Два места обычно упускают из виду. Первое, fail2ban: если там сработает блокировка, после смены порта она по-прежнему закроет только порт 22, а попытки на новом порту пройдут беспрепятственно. Допишите порт в /etc/fail2ban/jail.local:

[sshd]
enabled = true
port    = 2222

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

Шаг 3: sshd_config и ловушка sshd_config.d

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

ls -l /etc/ssh/sshd_config.d/
grep -n '^Include' /etc/ssh/sshd_config

Строка Include в Debian и Ubuntu с завода стоит в самом начале, обычно в строке 12. Это важнее, чем кажется: у большинства директив побеждает первое найденное значение, а не последнее. Поскольку Include стоит вверху, файлы из каталога перебивают всё, что идёт ниже в sshd_config. Если строку перенесли в конец файла, порядок переворачивается и ваш файл уже не подействует.

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

tee /etc/ssh/sshd_config.d/20-port.conf >/dev/null <<'EOF'
Port 22
Port 2222
EOF
chmod 644 /etc/ssh/sshd_config.d/20-port.conf

Проверка: сначала синтаксис, потом действующая итоговая конфигурация с раскрытыми файлами Include:

sshd -t
sshd -T | grep -E '^(port|listenaddress) '

Ожидаются две строки, port 22 и port 2222. Если дополнительно появится строка listenaddress, это второе место, где могут стоять порты: ListenAddress может задавать адрес вместе с портом и тем самым ограничивает, что именно прослушивается. Незамеченная строка вроде ListenAddress 127.0.0.1 объясняет большинство случаев, когда порт настроен чисто, а снаружи никто не доходит.

Если sshd -t вместо этого сообщает Missing privilege separation directory: /run/sshd, значит, служба ни разу не запускалась с момента загрузки системы, и mkdir -p /run/sshd снимает вопрос.

Шаг 4: активация через сокет, когда порт лежит не в sshd_config

Здесь дистрибутивы расходятся, и здесь же случается большинство аварий. Ubuntu начиная с 22.10 делает ставку на активацию через сокет: порт держит не sshd, а systemd. Он слушает вместо службы и запускает процесс sshd только при входящем соединении. Порт тогда стоит в юните ssh.socket в параметре ListenStream, а строка Port в конфигурации sshd может вообще не подействовать.

Не гадайте, а спросите систему:

systemctl is-enabled ssh.socket ssh.service

Таблица описывает состояние при поставке, а не обязательно ваш сервер: образы разного происхождения отличаются, а обновлённая система сохраняет прежнюю настройку. Если ssh.socket активен, systemctl cat покажет юнит вместе со всеми дополняющими файлами и их путями, в том числе созданными автоматически:

systemctl cat ssh.socket

Новый порт вы прописываете отдельным дополняющим файлом. Первая, пустая строка ListenStream= сбрасывает уже имеющиеся значения, после неё считаются исключительно ваши. Без этой сбрасывающей строки заводские значения добавились бы к вашим:

mkdir -p /etc/systemd/system/ssh.socket.d
tee /etc/systemd/system/ssh.socket.d/override.conf >/dev/null <<'EOF'
[Socket]
ListenStream=
ListenStream=0.0.0.0:22
ListenStream=[::]:22
ListenStream=0.0.0.0:2222
ListenStream=[::]:2222
EOF
systemctl daemon-reload

И здесь оба порта стоят рядом, по той же причине, что и в шаге 3. Файл в /etc/systemd/system/ имеет приоритет над всем, что система создаёт сама.

Проверка: systemctl cat ssh.socket теперь выводит ваш файл отдельным блоком.

Если ssh.service и ssh.socket активны одновременно, они спорят за один и тот же порт. Проявляется это как fatal: Cannot bind any address. или ssh.socket: Socket service ssh.service already active, refusing. Тогда выберите один из двух режимов работы, подробности разбирает наше руководство по защите SSH.

Шаг 5: перезапуск и проверка по сокету

Одна команда, которая верна на всех четырёх системах, потому что try-restart перезапускает только то, что действительно работает, и не трогает второй юнит:

sshd -t && systemctl try-restart ssh.socket ssh.service

Не используйте reload: на системах с активацией через сокет он отвечает fatal: Cannot bind any address., и служба после этого отпускает свой порт. И не выполняйте отдельно systemctl restart ssh.socket: в Debian команда не проходит, а в Ubuntu 22.04 незаметно переводит хост на работу через сокет. Уже открытые сеансы переживают перезапуск в любом случае.

Проверка, причём единственная, которая действительно имеет значение:

ss -tlnp | grep -E ':(22|2222) '

Ожидаются четыре строки: 0.0.0.0:22, [::]:22, 0.0.0.0:2222 и [::]:2222. Если строк IPv6 нет, по IPv6 сервер для вас недоступен.

Особенность, которая приводит к лишней панике: при активации через сокет в последнем столбце может стоять systemd вместо sshd, потому что слушающий сокет держит systemd, пока не запущен ни один процесс sshd. Поэтому фильтруйте по номеру порта, а не по имени процесса, иначе примете работающую службу за мёртвую.

Шаг 6: третий сеанс, собственно проверка

Теперь, и ни шагом раньше, откройте новый терминал. Оба прежних сеанса остаются открытыми.

ssh -p 2222 root@203.0.113.10

Если не получилось, ssh -vv -p 2222 root@203.0.113.10 покажет, на каком этапе всё срывается.

Один уточняющий вопрос при этом нормален: SSH снова спрашивает о подлинности ключа хоста, хотя на сервере ничего не менялось. Дело в том, что записи в known_hosts привязаны к порту и для нестандартных портов сохраняются в виде [203.0.113.10]:2222. Посмотреть и при сомнениях удалить:

ssh-keygen -F '[203.0.113.10]:2222'
ssh-keygen -R '[203.0.113.10]:2222'

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

Шаг 7: закрыть порт 22 и подтянуть инструменты

Только после того как шаг 6 сработал, убирайте старый порт. В 20-port.conf остаётся одна-единственная строка:

tee /etc/ssh/sshd_config.d/20-port.conf >/dev/null <<'EOF'
Port 2222
EOF
sshd -t && systemctl try-restart ssh.socket ssh.service

При активации через сокет дополнительно вычеркните обе строки с портом 22 из /etc/systemd/system/ssh.socket.d/override.conf и следом выполните systemctl daemon-reload. После этого файрвол:

ufw delete allow 22/tcp
ufw status verbose

Проверка: ss -tlnp | grep -E ':(22|2222) ' теперь показывает только новый порт, снова в обоих семействах адресов.

Остаётся часть, которая аукается дольше всего: все инструменты, которые обращаются к серверу. Удобнее всего решить это раз и навсегда в ~/.ssh/config:

Host my-server
    HostName 203.0.113.10
    Port 2222
    User kernel

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

rsync --port, кстати, относится к демону rsync, а не к SSH, и здесь никакого действия не оказывает. В Ansible порт записывается в инвентаре как ansible_port.

SELinux на системах RHEL

В AlmaLinux, Rocky Linux и RHEL SELinux с завода работает в режиме enforcing, и правила разрешают sshd исключительно те порты, которые помечены как ssh_port_t. С завода это только порт 22. Без этого дополнительного шага служба не запустится, а сообщение обманчиво выглядит как проблема с правами:

error: Bind to port 2222 on 0.0.0.0 failed: Permission denied.

Сначала взгляд на состояние и на уже имеющуюся пометку:

getenforce
semanage port -l | grep ssh_port_t

Если semanage нет, он лежит в пакете policycoreutils-python-utils:

dnf install -y policycoreutils-python-utils

Добавьте новый порт, причём до перезапуска sshd:

semanage port -a -t ssh_port_t -p tcp 2222

Если порт уже отнесён к другому типу, -a завершится с указанием на то, что он уже определён. Тогда меняйте привязку через -m, а не добавляйте новую.

Проверка: semanage port -l | grep ssh_port_t теперь перечисляет оба порта. Если после этого всё равно что-то не идёт, отклонённые обращения покажет:

ausearch -m avc -ts recent

В Debian и Ubuntu при стандартной установке сравнимого ограничения нет, там этот раздел не нужен.

Частые ошибки и решения

ssh: connect to host 203.0.113.10 port 2222: Connection refused: пакеты доходят, но никто не слушает. Служба не была перезапущена, конфигурация не подействовала, либо строка ListenAddress привязывает её к другому адресу.

ssh: connect to host 203.0.113.10 port 2222: Connection timed out: пакеты вообще не доходят, и это почти всегда пакетный фильтр на сервере или в вашей собственной сети. Отличие от предыдущего сообщения — самая важная диагностическая информация вообще: отказ означает, что нет службы, а тайм-аут означает фильтр.

error: Bind to port 2222 on 0.0.0.0 failed: Permission denied.: на системах RHEL это SELinux, смотрите выше. В Debian и Ubuntu сообщение появляется практически только тогда, когда sshd работает не от root и должен занять порт ниже 1024.

error: Bind to port 2222 on 0.0.0.0 failed: Address already in use.: порт занял другой процесс, ss -tlnp | grep ':2222 ' его назовёт. Если ошибка появляется лишь изредка после перезагрузки, значит, порт попал в диапазон динамических портов источника, смотрите шаг 1.

fatal: Cannot bind any address.: ни один из запрошенных адресов занять не удалось. В Debian и Ubuntu это, как правило, значит, что порт уже держит ssh.socket, а вы дополнительно пытаетесь запустить на нём ssh.service.

Job for ssh.service failed because the control process exited with error code.: причина стоит в журнале, а не в этой строке. journalctl -u ssh -n 50 --no-pager её покажет, независимо от версии OpenSSH.

/etc/ssh/sshd_config.d/20-port.conf line 1: Bad configuration option: prot: опечатка. sshd -t назовёт файл и номер строки, именно ради этого команда и стоит перед каждым перезапуском.

sshd: no hostkeys available -- exiting.: ключей хоста нет или они недоступны для чтения, ssh-keygen -A создаст недостающие. sshd -t и sshd -T требуют прав на чтение и поэтому должны запускаться от root.

ssh: connect to host 203.0.113.10 port 22: Connection refused после успешной смены: ваш клиент по-прежнему пробует стандартный порт. Дополните ~/.ssh/config или передавайте -p.

Если вы всё-таки заперты снаружи

1. Не перезагружайте. Перезагрузка восстановит правила файрвола и конфигурацию службы, и сервер вернётся ровно таким же закрытым.
2. Откройте VNC-консоль в личном кабинете и войдите как root. Вход через консоль идёт не по SSH и вашего изменения не касается.
3. Определите класс ошибки. ss -tlnp отвечает на это сразу: если порт там есть, это проблема с фильтром. Если его нет, это проблема со службой, и journalctl -u ssh -n 50 --no-pager скажет почему.
4. Откатывайте, а не чините. rm -f /etc/ssh/sshd_config.d/20-port.conf и, если создавали, rm -f /etc/systemd/system/ssh.socket.d/override.conf, затем systemctl daemon-reload и systemctl try-restart ssh.socket ssh.service.
5. Если причиной был файрвол, поможет ufw disable, а следом чистая пересборка правил с правильным разрешением порта.

Коротко о главном

• Сначала файрвол, sshd потом. Старый порт остаётся открытым, пока новый не докажет свою работоспособность.
• Несколько строк Port складываются, и это делает переход безопасным. Значение по умолчанию 22 отпадает, как только появляется хоть одна строка Port.
• При активации через сокет, включённой с завода в Ubuntu 24.04, порт стоит в ListenStream.
• Решает всегда не конфигурационный файл, а ss -tlnp с фильтром по номеру порта.
• Аварийный путь — это VNC-консоль в личном кабинете, для неё держите наготове пароль root.

Если вы только вводите сервер в эксплуатацию, наш чек-лист для новых root-серверов встраивает этот шаг в остальную базовую настройку. И ещё раз для порядка: другой порт делает ваши журналы читаемыми. Безопасным доступ становится за счёт входа по ключу и отключённой парольной аутентификации. Если вы сделаете только одно из двух, возьмите второе.