Настройка, конфигурирование и защита SSH в Debian 13 Linux за 30 минут

Краткое описание

Чтобы настроить SSH в Debian 13, выполните следующие команды в sudo:

sudo apt update и sudo apt install openssh-server -y

Включите службу ssh при загрузке системы с помощью команды:

sudo systemctl enable ssh && sudo systemctl start ssh

Наконец, подключитесь к Debian 13 по SSH с помощью:

ssh имя_пользователя@ip_сервера

Для рабочих серверов необходимо также отключить вход в систему с правами root, настроить SSH-ключи и брандмауэр.

Введение

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

В этой подробной статье по настройке SSH мы расскажем всё, что вам нужно знать, чтобы настроить, сконфигурировать и защитить SSH в Debian 13 «Trixie» — от базовой установки до расширенной защиты, которая предотвращает 99 % атак.

Мы разделили эту статью на две части: Часть 1. Настройка SSH позволяет подключиться и проверить, всё ли работает. Часть 2. Усиление защиты SSH с помощью основных настроек безопасности, которые предотвращают 99 % атак.

Чему вы научитесь

Часть 1. Базовая настройка SSH (как заставить его работать)

• Как установить и включить сервер OpenSSH в Debian 13
• Как узнать IP-адрес вашего сервера
• Проверка SSH-соединения
• Базовая настройка брандмауэра

Часть 2. Усиление защиты SSH (сделайте его безопасным)

• Настройка аутентификации по SSH-ключу
• Основные настройки безопасности
• Дополнительные параметры защиты
• Мониторинг и предотвращение атак с помощью fail2ban

Часть 1. Базовая настройка SSH

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

Что такое SSH и почему это важно

SSH (Secure Shell) создаёт зашифрованное соединение между вашим компьютером и удалённым сервером. Каждая команда, пароль и передача файлов проходят через этот зашифрованный туннель.

Почему SSH заменил старые протоколы:

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

SSH по умолчанию работает на порте 22 и поддерживает два метода аутентификации: пароли (удобные, но менее безопасные) и криптографические ключи (более безопасные, соответствуют отраслевым стандартам).

Что делает SSH:

• Безопасный удалённый доступ через командную строку
• Зашифрованная передача файлов (SCP, SFTP)
• Безопасное туннелирование для других протоколов
• Переадресация портов для доступа к внутренним службам

Чего не делает SSH:

• SSH — это не VPN (он не шифрует весь сетевой трафик)
• Он не защищает от вредоносного ПО на самом сервере
• Он не может обеспечить безопасность других служб, работающих на вашем сервере

Предварительные условия и системные требования

Перед началом работы убедитесь, что у вас есть:

Системные требования:

• Debian 13 «Трикси»
• Активное подключение к Интернету

Требования к доступу:

• Root-доступ или привилегии sudo
• Физический или консольный доступ к серверу (важно для первоначальной настройки)
• Базовые знания командной строки Linux

Необязательно, но рекомендуется:

• Второе окно терминала для безопасного тестирования подключений
• Статический IP-адрес или имя хоста вашего сервера
• Клиентский компьютер для подключения (Linux, Mac или Windows)

Это руководство работает над:

• Физические серверы Debian
• Виртуальные машины (VirtualBox, VMware, KVM)
• Облачные инстансы (AWS, DigitalOcean, Linode и т. д.)
• Raspberry Pi под управлением Debian
• WSL2 с Debian

О Debian 13 «Trixie»: Debian 13, выпущенный 9 августа 2025 года, включает OpenSSH 10.0p1 или более позднюю версию с современными настройками безопасности по умолчанию. Он будет полностью поддерживаться до августа 2028 года, а долгосрочная поддержка (LTS) продлится до июня 2030 года.

Шаг 1. Проверьте, установлен ли SSH

Во многих установках Debian есть клиентские инструменты SSH, но нет сервера SSH. Сначала проверьте, прежде чем устанавливать.

Выполните эту команду, чтобы узнать, установлен ли и работает ли сервер SSH:

sudo systemctl status ssh

Если вы видите надпись «active (running)» зеленым цветом: SSH уже установлен и работает. Перейдите к шагу 3, чтобы проверить подключение.

Если вы видите надпись «Unit ssh.service could not be found»: Сервер SSH не установлен. Перейдите к шагу 2.

Вы также можете проверить, прослушивает ли SSH порт 22:

sudo ss -tlnp | grep :22

Если эта команда ничего не возвращает, значит, SSH-сервер не запущен.

В качестве альтернативы попробуйте подключиться к localhost:

ssh localhost

Если вы получаете сообщение «Отказано в соединении», вам нужно установить SSH-сервер.

Шаг 2. Установка OpenSSH Server

Теперь давайте установим пакет OpenSSH Server.

Сначала обновите список репозиториев пакетов:

sudo apt update

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

Установите сервер OpenSSH:

sudo apt install openssh-server -y

Флаг -y автоматически подтверждает установку. При появлении запроса введите пароль sudo.

Во время установки:

• Пакет openssh-server устанавливает
• необходимые пакеты зависимостей устанавливаются автоматически
• служба SSH запускается немедленно
• SSH настроен на автоматический запуск при загрузке

Вся установка занимает 10–30 секунд в зависимости от скорости вашего подключения.

Убедитесь, что служба SSH успешно запущена:

sudo systemctl status ssh

Вы должны увидеть примерно такой результат:

● ssh.service - OpenBSD Secure Shell server
     Loaded: loaded (/usr/lib/systemd/system/ssh.service; enabled; preset: enabled)
     Active: active (running) since Fri 2026-01-16 14:28:13 IST; 1h 45min ago
 Invocation: 837ace1c8cb5446aa5a67ef0c7181038
       Docs: man:sshd(8)
             man:sshd_config(5)
   Main PID: 640 (sshd)
      Tasks: 1 (limit: 9470)
     Memory: 9M (peak: 27.4M)
        CPU: 123ms
     CGroup: /system.slice/ssh.service
             └─640 "sshd: /usr/sbin/sshd -D [listener] 0 of 10-100 startups"

Jan 16 14:28:13 debian13minimal systemd[1]: Starting ssh.service - OpenBSD Secure Shell server...
Jan 16 14:28:13 debian13minimal sshd[640]: Server listening on 0.0.0.0 port 22.
Jan 16 14:28:13 debian13minimal sshd[640]: Server listening on :: port 22.
Jan 16 14:28:13 debian13minimal systemd[1]: Started ssh.service - OpenBSD Secure Shell server.
Jan 16 16:12:39 debian13minimal sshd-session[1384]: Connection closed by ::1 port 54232 [preauth]
Jan 16 16:13:19 debian13minimal sshd-session[1393]: Accepted password for andreyex from 192.168.1.101 port 49020 ssh2
Jan 16 16:13:19 debian13minimal sshd-session[1393]: pam_unix(sshd:session): session opened for user andreyex(uid=1000) by andreyex(uid=0)

Как видно из приведенного выше вывода, зеленый статус «активно (работает)» подтверждает, что SSH работает.

Если SSH не настроен на запуск при загрузке (по умолчанию он должен быть включен), включите его:

sudo systemctl enable ssh

Шаг 3. Найдите IP-адрес вашего сервера

Для подключения по SSH вам понадобится IP-адрес вашего сервера

Найдите свой IP-адрес с помощью этой команды:

ip addr show

Или используйте сокращённый вариант:

ip a

Как прочитать вывод:

Найдите свой основной сетевой интерфейс (обычно это eth0, enp0s3, или wlan0 для беспроводной сети). Найдите строку, начинающуюся с inet (не inet6), если вам не нужен IPv6.

Пример вывода:

2: ens18: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc fq_codel state UP group default qlen 1000
    link/ether bc:24:11:5f:7f:01 brd ff:ff:ff:ff:ff:ff
    altname enp6s18
    altname enxbc24115f7f01
    inet 192.168.1.13/24 brd 192.168.1.255 scope global ens18
       valid_lft forever preferred_lft forever
    inet6 fe80::be24:11ff:fe5f:7f01/64 scope link proto kernel_ll 
       valid_lft forever preferred_lft forever

В этом примере IP-адрес — 192.168.1.13.

Альтернативный метод с использованием имени хоста:

hostname -I

Здесь отображаются только IP-адреса без дополнительной информации.

Найдите своё имя пользователя:

Если вы не помните своё имя пользователя, выполните команду:

whoami

Здесь отображается ваше текущее имя пользователя.

Запишите свой IP-адрес и имя пользователя — они понадобятся вам для подключения.

Шаг 4. Проверьте подключение по SSH

Прежде чем вносить какие-либо изменения, убедитесь, что SSH работает с настройками по умолчанию.

С того же сервера (тест localhost):

ssh localhost

При запросе отпечатка пальца введите yes, затем введите свой пароль. Если вы можете войти в систему, значит, SSH работает.

Завершите тестовое подключение:

exit

С другого компьютера (удаленное тестирование):

Откройте терминал на клиентском компьютере и подключитесь:

ssh username@server_ip

Замените username на своё настоящее имя пользователя, а server_ip на IP-адрес вашего сервера.

Пример:

ssh andreyex@192.168.1.13

Предупреждение при первом подключении:

При первом подключении к новому серверу вы увидите:

hostkeys_find_by_key_hostfile: hostkeys_foreach failed for /etc/ssh/ssh_known_hosts: Permission denied
The authenticity of host '192.168.1.13 (192.168.1.13)' can't be established.
ED25519 key fingerprint is SHA256:xmmilIRQ0oY3cSBkf746gngxPhzv22Fl/Q5mflJ2kt0.
This key is not known by any other names.
Are you sure you want to continue connecting (yes/no/[fingerprint])? yes

Введите yes и нажмите Enter. Это сохранит отпечаток сервера в вашем файле known_hosts.

При появлении запроса введите свой пароль. Если вы успешно вошли в систему, значит, SSH работает правильно.

Поздравляем! Теперь у вас есть работающий SSH-сервер.

Шаг 5. Базовая настройка брандмауэра (необязательно, но рекомендуется)

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

Установите UFW (Uncomplicated Firewall):

sudo apt install ufw -y

Важно: Разрешите использование SSH ДО включения брандмауэра.

sudo ufw allow 22/tcp

Установка политик по умолчанию:

sudo ufw default deny incoming
sudo ufw default allow outgoing

Включить брандмауэр:

sudo ufw enable

Нажмите y для подтверждения.

Проверка состояния брандмауэра:

sudo ufw status verbose

Вы должны увидеть, что SSH (порт 22) разрешён.

Status: active
Logging: on (low)
Default: deny (incoming), allow (outgoing), disabled (routed)
New profiles: skip

To                         Action      From
--                         ------      ----
22/tcp                     ALLOW IN    Anywhere                  
22/tcp (v6)                ALLOW IN    Anywhere (v6)

Если вы пропустите правило разрешения и включите UFW, вы сами себя заблокируете. Брандмауэр немедленно заблокирует ваше SSH-соединение.

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

Часть 2. Усиление защиты SSH в Debian Linux (сделайте его безопасным)

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

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

Почему важна защита SSH

ВАЖНОЕ ПРЕДУПРЕЖДЕНИЕ О БЕЗОПАСНОСТИ

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

Что происходит без закаливания:

• Боты находят ваш сервер в течение нескольких часов после его подключения к сети
• Автоматические атаки с подбором пароля (метод перебора)
• Учетная запись root является основной целью
• Ваши логи заполняются тысячами неудачных попыток входа в систему
• В конце концов слабые пароли взламываются

Чего позволяет добиться правильная закалка:

• Мгновенно останавливает 90–95 % автоматизированных атак
• Полностью устраняет уязвимости, связанные с паролями
• Значительно сокращает поверхность атаки
• Делает ваш сервер практически невидимым для автоматизированных сканеров

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

Шаг 6. Создайте резервную копию конфигурации SSH

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

sudo cp /etc/ssh/sshd_config /etc/ssh/sshd_config.backup

Если что-то пойдёт не так, вы сможете это восстановить:

sudo cp /etc/ssh/sshd_config.backup /etc/ssh/sshd_config
sudo systemctl restart ssh

Шаг 7. Базовая настройка безопасности SSH

Откройте файл конфигурации SSH в предпочитаемом вами текстовом редакторе:

sudo nano /etc/ssh/sshd_config

Мы внесём несколько важных изменений, чтобы защитить ваш SSH-сервер.

Настройка безопасности 1: отключение входа в систему с правами root (важно)

Найдите эту строку:

#PermitRootLogin prohibit-password

Измените его на:

PermitRootLogin no

Уберите символ # и измените значение на no. Пока не сохраняйте. Нам нужно настроить ещё несколько параметров.

Как сохранить root-доступ: Вместо этого используйте свою обычную учётную запись с sudo. Это обеспечит более качественное ведение журнала и подотчётность.

Настройка безопасности 2: измените порт по умолчанию (настоятельно рекомендуется)

Найдите эту строку:

#Port 22

Измените его на нестандартный порт:

Port 2222

Уберите # и выберите любой порт в диапазоне от 1024 до 65535. Распространённые варианты: 2222, 2200, 2244 или 22222.

Зачем менять порт по умолчанию?

Порт 22 — самый часто сканируемый порт в интернете. Исследования показывают, что смена порта 22 на другой останавливает 90–99 % автоматических атак ботов, поскольку большинство сценариев сканирования проверяют только стандартные порты.

Журналы безопасности на серверах с портом 22 ежедневно фиксируют от сотен до тысяч попыток взлома методом перебора. На серверах с нестандартными портами количество попыток атак значительно меньше.

Важные примечания:

• Запишите новый номер порта, он вам понадобится для подключения
• Обновите правила брандмауэра (см. шаг 11): sudo ufw allow 2222/tcp
• Сообщите пользователям, что они должны указать порт: ssh -p 2222 user@server

Ограничение: смена портов — это «безопасность через неизвестность». Она предотвращает случайные сканирования, но не остановит решительного злоумышленника, который сканирует все порты. Тем не менее это эффективно против 90 % автоматизированных атак.

Настройка безопасности 3: подготовка к аутентификации только по ключу

Найдите эту строку:

#PubkeyAuthentication yes

Измените его на:

PubkeyAuthentication yes

Почему SSH-ключи лучше:

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

Дополнительные настройки безопасности (рекомендуется)

Добавьте или измените эти строки в /etc/ssh/sshd_config:

Ограничение количества попыток аутентификации

MaxAuthTries 3
MaxSessions 2

Это позволяет сделать 3 попытки ввода пароля/ключа и провести 2 одновременных сеанса SSH за одно подключение. Ограничивает количество попыток перебора. Значения по умолчанию — 6 и 10 в конфигурационном файле ssh Debian 13.

Установите время ожидания входа в систему:

LoginGraceTime 60

Отключает неаутентифицированные соединения через 60 секунд. Предотвращает использование ресурсов зависшими соединениями. Значение по умолчанию — 2 минуты.

Установить время ожидания в режиме ожидания:

ClientAliveInterval 300
ClientAliveCountMax 2

Автоматически отключает неактивные сеансы через 10 минут (300 секунд × 2 проверки). Не позволяет оставлять открытыми забытые сеансы. Значения по умолчанию для этих двух параметров — 0 и 3 соответственно.

Принудительно использовать протокол SSH 2 (уже установлен по умолчанию в Debian 13):

Protocol 2

Протокол SSH 1 устарел и не работает. В современных версиях Debian он уже отключен, но явная настройка не повредит.

Сохраните файл: нажмите Ctrl+O, затем Ctrl+X.

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

Шаг 8. Настройка аутентификации с помощью SSH-ключей

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

Как работают SSH-ключи

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

Сгенерируйте пару ключей SSH

На локальном клиентском компьютере (НЕ на сервере), откройте терминал и выполните команду:

ssh-keygen -t ed25519 -C «your_email@example.com»

Замените your_email@example.com на свой реальный адрес электронной почты (используется в качестве метки).

Почему Ed25519?

Это самый современный и безопасный тип ключей. Ed25519 обеспечивает такой же уровень безопасности, как и 4096-битные ключи RSA, но при этом имеет более высокую производительность, более короткие ключи и более надёжные криптографические свойства. Это рекомендуемый стандарт на 2025 год.

Процесс генерации ключа:

1. Сохранить местоположение: Нажмите Enter, чтобы использовать значение по умолчанию (~/.ssh/id_ed25519)
2. Кодовая фраза: При появлении запроса введите надежную кодовую фразу
   • Это защитит ваш закрытый ключ, если кто-то украдёт ваш компьютер
   • При использовании ключа вам будет предложено ввести эту парольную фразу
   • Если оставить поле пустым, это будет менее безопасно, но более удобно
3. Завершение: Вы увидите отпечаток ключа и случайное изображение

Generating public/private ed25519 key pair.
Enter file in which to save the key (/home/andreyex/.ssh/id_ed25519): 
/home/andreyex/.ssh/id_ed25519 already exists.
Overwrite (y/n)? y
Enter passphrase (empty for no passphrase): 
Enter same passphrase again: 
Your identification has been saved in /home/andreyex/.ssh/id_ed25519
Your public key has been saved in /home/andreyex/.ssh/id_ed25519.pub
The key fingerprint is:
SHA256:dKyZ99/7d5o1sXJM3WE9HpBb1jwjxG64zmRBew4LP7w sk@andreyex.lan
The key's randomart image is:
+--[ED25519 256]--+
|            oo...|
|         . . +.=+|
|        . + + ==+|
|       . * = =o *|
|        S = O  +o|
|         . X .o o|
|          = +. =.|
|           E .o++|
|              +oB|
+----[SHA256]-----+

Созданные файлы:

• ~/.ssh/id_ed25519 — Ваш закрытый ключ (НИКОГДА не сообщайте его)
• ~/.ssh/id_ed25519.pub — Ваш открытый ключ (можно сообщить)

Альтернатива: ключи RSA (если Ed25519 не поддерживается):

ssh-keygen -t rsa -b 4096 -C "your_email@example.com"

Используйте RSA только при подключении к очень старым системам, которые не поддерживают Ed25519.

Скопируйте свой открытый ключ на сервер

Теперь перенесите свой открытый ключ в файл authorized_keys на сервере.

Способ 1. Использование ssh-copy-id (самый простой):

ssh-copy-id -p 22 username@server_ip

Заменить:

• 22с указанием вашего SSH-порта (если вы изменили его на шаге 7, используйте этот порт)
• usernameс указанием имени пользователя на вашем сервере
• server_ipс указанием IP-адреса вашего сервера

Пример:

ssh-copy-id -p 22 andreyex@192.168.1.13

Введите пароль ещё раз. Команда автоматически скопирует ваш открытый ключ на сервер.

Способ 2: копирование вручную (если ssh-copy-id недоступен):

Отображение вашего открытого ключа:

cat ~/.ssh/id_ed25519.pub

Скопируйте весь вывод (начинается с ssh-ed25519 и заканчивается вашим адресом электронной почты).

Войдите на свой сервер, затем:

mkdir -p ~/.ssh
chmod 700 ~/.ssh
nano ~/.ssh/authorized_keys

Вставьте свой открытый ключ в новую строку. Сохраните и выйдите (Ctrl+X, Y, Enter).

Установите правильные разрешения:

chmod 600 ~/.ssh/authorized_keys

Почему важны разрешения: SSH отказывается использовать ключи с неправильными разрешениями из соображений безопасности. Требуются именно эти разрешения.

Шаг 9. Проверка аутентификации по SSH-ключу

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

Оставьте существующий сеанс SSH открытым и откройте НОВОЕ окно терминала для проверки.

Попробуйте подключиться с помощью своего ключа:

ssh -p 22 username@server_ip

Используйте новый номер порта, если вы изменили его на шаге 7.

Примечание: Мы изменили номер порта, но ещё не перезапустил службу ssh, поэтому 22 по-прежнему является портом ssh по умолчанию.

Что должно произойти:

• Если вы установили кодовую фразу: вам будет предложено ввести кодовую фразу (НЕ пароль)
• Если кодовая фраза не установлена: вы войдете в систему сразу, без запроса пароля

$ ssh -p 22 andreyex@192.168.1.13
Linux debian13minimal 6.12.63+deb13-amd64 #1 SMP PREEMPT_DYNAMIC Debian 6.12.63-1 (2025-12-30) x86_64

The programs included with the Debian GNU/Linux system are free software;
the exact distribution terms for each program are described in the
individual files in /usr/share/doc/*/copyright.

Debian GNU/Linux comes with ABSOLUTELY NO WARRANTY, to the extent
permitted by applicable law.
Last login: Fri Jan 16 16:52:25 2026 from 192.168.1.101

Если всё работает: Отлично! Аутентификация по ключу настроена. Теперь вы можете отключить аутентификацию по паролю.

Если не работает:

• Проверьте права доступа к файлам на сервере: ls -la ~/.ssh/
• Убедитесь, что ваш открытый ключ находится в ~/.ssh/authorized_keys на сервере
• Проверьте логи SSH-сервера: sudo tail -f /var/log/auth.log
• НЕ отключайте аутентификацию по паролю, пока это не сработает

Шаг 10. Отключите аутентификацию по паролю

Теперь, когда SSH-ключи работают, полностью отключите аутентификацию по паролю.

Вернитесь на свой сервер Debian 13 и снова откройте файл конфигурации SSH в предпочитаемом вами текстовом редакторе:

sudo nano /etc/ssh/sshd_config

Найдите эту строку:

#PasswordAuthentication yes

Измените его на:

PasswordAuthentication no

Удалите # и замените его на no.

Сохраните и выйдите (Ctrl+X, Y, Enter).

Проверьте файл конфигурации на наличие синтаксических ошибок:

sudo sshd -t

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

Перезапустите службу SSH:

sudo systemctl restart ssh

Убедитесь, что SSH работает на новом порту:

sudo ss -tlnp | grep sshd

Вы должны увидеть вывод, показывающий, что SSH прослушивает ваш новый порт (например, :2222).

LISTEN 0      128          0.0.0.0:2222      0.0.0.0:*    users:(("sshd",pid=2149,fd=6))
LISTEN 0      128             [::]:2222         [::]:*    users:(("sshd",pid=2149,fd=7))

Шаг 11. Настройте брандмауэр для нового порта SSH

Если вы изменили порт SSH на шаге 7, обновите правила брандмауэра.

Удалите старое правило для порта 22:

sudo ufw delete allow 22/tcp

Разрешите использование нового SSH-порта:

sudo ufw allow 2222/tcp

Замените 2222 на фактический порт SSH.

Проверьте состояние брандмауэра с помощью команды:

sudo ufw status numbered

Вы должны увидеть, что ваш новый SSH-порт разрешён, а порт 22 должен быть удалён.

Status: active

     To                         Action      From
     --                         ------      ----
[ 1] 2222/tcp                   ALLOW IN    Anywhere                  
[ 2] 2222/tcp (v6)              ALLOW IN    Anywhere (v6)

Дополнительно: ограничение количества SSH-подключений:

sudo ufw limit 2222/tcp

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

Шаг 12. Проверка SSH-подключения с использованием нового порта без пароля

Вернитесь в локальную клиентскую систему и проверьте SSH-подключение в НОВОМ терминале (оставьте старый терминал открытым):

ssh -p 2222 andreyex@192.168.1.13

Замените номер порта, имя пользователя и IP-адрес на свои.

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

Если не работает: Хорошо, что вы не закрыли исходный сеанс. Проверьте файл конфигурации на наличие опечаток, исправьте их и перезапустите SSH.

Шаг 13. Проверьте правильность настройки безопасности SSH

Выполните эти команды для проверки, чтобы убедиться, что всё настроено правильно.

Убедитесь, что SSH прослушивает нужный порт

sudo ss -tlnp | grep sshd

В выводе вы должны увидеть свой SSH-порт (в нашем примере — 2222).

LISTEN 0      128          0.0.0.0:2222      0.0.0.0:*    users:(("sshd",pid=2149,fd=6))
LISTEN 0      128             [::]:2222         [::]:*    users:(("sshd",pid=2149,fd=7))

Проверка подлинности по паролю отключена

sudo sshd -T | grep passwordauthentication

Должен выводить:

passwordauthentication no

Убедитесь, что вход с правами Root отключен

sudo sshd -T | grep permitrootlogin

Должен выводить:

permitrootlogin no

Убедитесь, что аутентификация по SSH-ключу включена

sudo sshd -T | grep pubkeyauthentication

Должен выводить:

pubkeyauthentication yes

Откройте терминал на другом компьютере:

ssh -p 2222 username@server_ip

Ожидаемые результаты:

• Подключение выполнено успешно с использованием вашего SSH-ключа
• Не запрашивается пароль (только кодовая фраза, если она установлена)
• Подключение не выполнено, если вы указали неправильное имя пользователя

Проверьте, что НЕ должно работать:

Попробуйте подключиться с помощью пароля (должно не сработать):

ssh -o PreferredAuthentications=password -p 2222 username@server_ip

Должно завершиться ошибкой «Отказано в доступе».

Попробуйте подключиться как root (должно завершиться ошибкой):

ssh -p 2222 root@server_ip

Должно завершиться ошибкой.

Если все эти тесты пройдены успешно, значит, ваш SSH-сервер надежно защищен.

Шаг 14. Настройка Fail2Ban (автоматическая защита от атак)

Fail2ban автоматически блокирует IP-адреса, с которых совершаются вредоносные действия, например повторяющиеся неудачные попытки входа в систему.

Установите Fail2Ban

sudo apt установить fail2ban — y

Настройка Fail2Ban для SSH

Создайте локальный файл конфигурации (никогда не редактируйте файл по умолчанию jail.conf):

sudo cp /etc/fail2ban/jail.conf /etc/fail2ban/jail.local

Отредактируйте локальную конфигурацию:

sudo nano /etc/fail2ban/jail.local

Найдите раздел [sshd] и измените его:

[sshd]
enabled = true
port = 2222
filter = sshd
logpath = /var/log/auth.log
maxretry = 3
bantime = 3600
findtime = 600

Объясненная конфигурация:

• enabled = true — Активирует защиту SSH
• port = 2222 — Ваш порт SSH (измените на свой )
• maxretry = 3 — Блокировка после 3 неудачных попыток
• bantime = 3600 — Блокировка на 1 час (3600 секунд )
• findtime = 600 — Неудачные попытки засчитываются в течение 10 минут

Сохранить и выйти (Ctrl+X, Y, Enter).

Перезапустить Fail2Ban

sudo systemctl restart fail2ban
sudo systemctl enable fail2ban

Отслеживание активности Fail2Ban

Проверка статуса блокировки:

sudo fail2ban-client статус sshd

Отображает общее количество блокировок и заблокированные в данный момент IP-адреса.

Просмотр заблокированных IP-адресов:

sudo fail2ban-client get sshd banip

Разблокируйте IP-адрес вручную:

sudo fail2ban-client set sshd unbanip IP_ADDRESS

Мониторинг журналов fail2ban:

sudo tail -f /var/log/fail2ban.log

Почему Fail2Ban необходим:

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

На типичном общедоступном сервере fail2ban ежедневно блокирует 10–50 IP-адресов за попытки брутфорса.

Более подробную информацию можно найти в нашем подробном руководстве по Fail2ban по ссылке ниже:

• Защита от атак методом перебора SSH с помощью Fail2ban в Linux

Мониторинг журналов и активности SSH

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

Просмотр последних журналов SSH

sudo journalctl -u ssh --no-pager -n 30

Здесь показаны последние 30 записей в журнале, связанных с SSH.

Просмотр журналов в режиме реального времени

Чтобы следить за журналами SSH в режиме реального времени (например, tail -f), выполните команду:

sudo journalctl -u ssh -f

Нажмите Ctrl+C, чтобы остановить просмотр.

Фильтр по попыткам аутентификации

sudo journalctl -u ssh | grep -i auth

Просмотр журналов с момента последней загрузки

sudo journalctl -u ssh -b

Просмотр неудачных входов в систему по SSH

sudo journalctl -u ssh | grep -i fail

Или более сосредоточенный:

sudo journalctl _COMM=sshd | grep -i fail

Что искать в журналах

Успешные входы в систему

Accepted publickey for username from IP_ADDRESS port XXXXX ssh2

Неудачные попытки входа в систему:

Failed password for invalid user admin from IP_ADDRESS port XXXXX ssh2

Несколько сбоев с одного IP-адреса = атака методом перебора:

Failed password for root from 192.168.1.100
Failed password for admin from 192.168.1.101
Failed password for user from 192.168.1.102

Проверьте, кто сейчас вошёл в систему

who

Или более подробный:

w

Отображает все текущие сеансы SSH с указанием времени подключения и IP-адресов.

Просмотр истории подключений SSH

last -a | grep pts

Отображает все недавние входы в систему по SSH с указанием временных меток и IP-адресов.

Тревожный сигнал: сотни неудачных попыток входа с одного и того же IP-адреса = автоматическая атака.

При установленном fail2ban: эти IP-адреса автоматически блокируются после 3 попыток.

Расширенная настройка SSH (необязательно)

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

Ограничить доступ к SSH для определенных пользователей

Добавьте эту строку, чтобы ограничить доступ к SSH для определенных учетных записей пользователей:

AllowUsers username1 username2

Только указанные пользователи могут войти в систему через SSH. Всем остальным будет отказано во входе, независимо от их учётных данных.

Привязка SSH к определённым IP-адресам

Если у вашего сервера несколько сетевых интерфейсов, ограничьте доступ SSH одним из них:

ListenAddress 192.168.1.13

Это не позволяет SSH прослушивать все интерфейсы, что снижает вероятность атаки.

Установите собственный баннер для входа в систему

Создайте файл с баннером:

sudo nano /etc/ssh/banner.txt

Добавьте свое предупреждающее сообщение:

AUTHORIZED ACCESS ONLY
All activity is monitored and logged.
Unauthorized access is prohibited.

Обратитесь к нему в /etc/ssh/sshd_config:

Banner /etc/ssh/banner.txt

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

Пример вывода:

AUTHORIZED ACCESS ONLY
All activity is monitored and logged.
Unauthorized access is prohibited.
Linux debian13minimal 6.12.63+deb13-amd64 #1 SMP PREEMPT_DYNAMIC Debian 6.12.63-1 (2025-12-30) x86_64

The programs included with the Debian GNU/Linux system are free software;
the exact distribution terms for each program are described in the
individual files in /usr/share/doc/*/copyright.

Debian GNU/Linux comes with ABSOLUTELY NO WARRANTY, to the extent
permitted by applicable law.
Last login: Fri Jan 16 18:16:27 2026 from 192.168.1.101

Отключите переадресацию X11

Если только вам не нужны графические приложения через SSH:

X11Forwarding no

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

Отключить переадресацию TCP (очень ограничительно)

Если вы не используете SSH для туннелирования или переадресации портов, вы можете отключить эти функции:

AllowTcpForwarding no
AllowStreamLocalForwarding no
GatewayPorts no
PermitTunnel no

Это отключает возможности SSH-туннелирования и переадресации, которые не нужны многим серверам.

Пользователи Chroot в своих домашних каталогах

Для пользователей, которым нужна только передача файлов и не требуется доступ к оболочке, можно ограничить доступ к SFTP в изолированной среде Chroot.

Важно: ChrootDirectory должен принадлежать root и не должен быть доступен для записи пользователю. Для этого часто требуется специальная структура каталогов.

Пример конфигурации:

Match User sftpuser  
ChrootDirectory /home/sftpuser  
ForceCommand internal-sftp  
AllowTcpForwarding no  
X11Forwarding no

Прежде чем включить это:

• Убедитесь, что /home/sftpuser принадлежит root:root
• Создайте подкаталог с возможностью записи (например, /home/sftpuser/upload) и сделайте его владельцем пользователя

Эта настройка ограничивает пользователя доступом только по протоколу SFTP в среде chroot.

Используйте SSH-сертификаты (для команд)

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

⚠️ Предупреждение: не копируйте и не вставляйте вслепую фрагменты кода для защиты SSH

Многие руководства по усилению защиты SSH в интернете написаны для более старых версий Linux. Современные системы, такие как Debian 13, уже поставляются с надёжными криптографическими настройками по умолчанию, включая шифрование с аутентификацией и постквантовый обмен ключами.

Слепое копирование списков шифров, MAC-адресов или ключей обмена может:

• отключить более надёжные алгоритмы по умолчанию
• нарушить совместимость с легитимными клиентами
• увеличить трудозатраты на долгосрочное обслуживание
• снизить уровень безопасности вместо того, чтобы повысить его

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

sudo sshd -T | grep -E 'ciphers|macs|kexalgorithms'

 

Изменяйте настройки по умолчанию только в том случае, если у вас есть чёткие требования к совместимости, соответствию или политике.

Понимание ограничений безопасности SSH

При правильной настройке SSH обеспечивает высокий уровень безопасности, но ни одна мера безопасности не является идеальной. Узнайте, от чего защищает SSH и от чего не защищает.

Что на самом деле обеспечивает безопасность SSH

Надежная защита от:

• ✅ Перехват пароля (все зашифровано)
• ✅ Прослушивание сетевого трафика (сквозное шифрование)
• ✅ Атаки типа «человек посередине» (с надлежащей проверкой по отпечатку пальца)
• ✅ Атаки методом перебора (с аутентификацией на основе ключа)
• ✅ Перехват сеанса (криптографические токены сеанса)

От чего не защищает SSH

Нет защиты от:

• ❌ Компрометация закрытых ключей (если кто-то украдёт ваш файл с ключами)
• ❌ Вредоносное ПО на сервере или клиенте
• ❌ Атаки с использованием социальной инженерии
• ❌ Физический доступ к вашему компьютеру с незашифрованными ключами
• ❌ Уязвимости в других службах, работающих на сервере
• ❌ Бэкдоры в самой операционной системе

Устранение распространённых проблем с SSH

1. Отказано в соединении

Ошибка: ssh: connect to host server_ip port 22: Connection refused

Причины и способы устранения:

• Служба SSH не запущена: sudo systemctl start ssh
• Указан неверный порт: используйте флаг -p с правильным портом
• Брандмауэр блокирует соединение: проверьте sudo ufw status

2. Отказано в доступе (publickey)

Ошибка: Permission denied (publickey)

Причины и способы устранения:

• SSH-ключи не настроены: повторите шаг 8
• Неверный файл ключа: укажите ключ с помощью ssh -i ~/.ssh/id_ed25519
• Неверные разрешения: исправьте с помощью chmod 600 ~/.ssh/authorized_keys на сервере
• Аутентификация по паролю отключена без рабочих ключей: отредактируйте /etc/ssh/sshd_config через консоль

3. Тайм-аут подключения

Ошибка: Подключение зависает, в конечном итоге происходит тайм-аут

Причины и способы устранения:

• Неверный IP-адрес: проверьте IP-адрес сервера с помощью ip a
• Сервер не работает: проверьте, запущен ли сервер
• Блокировка брандмауэром: временно отключите для проверки: sudo ufw disable
• Проблемы с сетью: проверьте с помощью ping server_ip

4. Слишком много неудачных попыток аутентификации

Ошибка: Received disconnect from server: Too many authentication failures

Причины и способы устранения:

• Слишком много ключей в ~/.ssh/: SSH автоматически пробует все ключи
• Решение: укажите ключ явно: ssh -i ~/.ssh/id_ed25519 user@server
• Или: увеличьте MaxAuthTries в /etc/ssh/sshd_config

5. Не удалось проверить ключ хоста

Ошибка: Host key verification failed

Причины:

• Сервер переустановлен с использованием новых SSH-ключей
• Атака «человек посередине» (редкая, но возможная)

Исправление (если вы доверяете новому ключу):

ssh-keygen -R server_ip

Это удаляет старый отпечаток. Переподключитесь, чтобы добавить новый.

6. Ошибка неверных разрешений

Ошибка: Bad permissions. Ignore key

Исправление:

chmod 700 ~/.ssh
chmod 600 ~/.ssh/id_ed25519
chmod 644 ~/.ssh/id_ed25519.pub

Для обеспечения безопасности SSH требуются точные разрешения.

7. Проверьте журналы SSH-сервера на наличие подробных ошибок

sudo tail -f /var/log/auth.log

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

Распространённые ошибки, которые приводят к блокировке (и как их избежать)

Это наиболее частые ошибки при настройке SSH. Учитесь на чужих ошибках.

Ошибка 1: отключение аутентификации по паролю перед тестированием SSH-ключей

Ошибка: Изменение PasswordAuthentication no перед проверкой работоспособности SSH-ключей.

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

Как этого избежать: Всегда проверяйте аутентификацию по SSH-ключу в НОВОМ терминале, не закрывая существующий сеанс. Отключайте аутентификацию по паролю только после того, как ключи будут работать без сбоев.

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

Ошибка 2: включение брандмауэра без разрешения для порта SSH

Ошибка: Запуск sudo ufw enable без разрешения для порта SSH.

Что происходит: Брандмауэр мгновенно блокирует все SSH-подключения. Вы заблокированы.

Как избежать: ВСЕГДА настраивайте правила брандмауэра (разрешайте порт SSH) ДО включения брандмауэра. Во время тестирования не закрывайте активный сеанс SSH.

Ошибка 3: не закрывать сеанс при внесении изменений

Ошибка: внесение изменений в конфигурацию SSH и немедленное закрытие сеанса для тестирования.

Что происходит: если что-то пойдёт не так, вы не сможете исправить это удалённо.

Как этого избежать: не закрывайте исходный сеанс SSH. Откройте ВТОРОЙ терминал для проверки новых подключений. Закройте исходный терминал только после того, как убедитесь, что новое подключение работает.

Ошибка 4: опечатки в файле sshd_config

Ошибка: Неправильное написание директив конфигурации, таких как PermitRootLogin или PasswordAuthentification (неправильное написание).

Что происходит: SSH может не запуститься, или директива будет проигнорирована.

Как избежать: Всегда проверяйте синтаксис конфигурации: sudo sshd -t перед перезапуском SSH. Это позволяет выявить синтаксические ошибки до того, как они приведут к сбою службы SSH.

Ошибка 5: неправильные права доступа к файлам SSH-ключей

Ошибка: .ssh каталог доступен для чтения всем пользователям или authorized_keys имеет неправильные права доступа.

Что происходит: SSH отказывается использовать ключи из соображений безопасности.

Как этого избежать: Установите правильные разрешения:

chmod 700 ~/.ssh
chmod 600 ~/.ssh/authorized_keys

Ошибка 6: изменение порта без обновления правил брандмауэра

Ошибка: SSH работает на порту 2222 в sshd_config, но брандмауэр по-прежнему разрешает только порт 22.

Что происходит: SSH работает на новом порту, но брандмауэр блокирует все подключения к нему.

Как избежать: После изменения портов немедленно обновите правила брандмауэра: sudo ufw allow 2222/tcp

Ошибка 7: использование слабых или устаревших типов ключей

Ошибка: Генерация ключей RSA длиной менее 2048 бит или использование ключей DSA.

Что происходит: Слабые ключи могут быть скомпрометированы. OpenSSH 10.0+ в Debian 13 вообще не поддерживает ключи DSA.

Как этого избежать: Всегда используйте ключи Ed25519: ssh-keygen -t ed25519 или RSA с длиной ключа не менее 4096 бит: ssh-keygen -t rsa -b 4096

Ошибка 8: установка порта SSH ниже 1024 для пользователей без прав root

Ошибка: попытка использовать порт 22, 80 или любой другой порт ниже 1024 без прав root.

Что происходит: SSH не может подключиться к порту.

Как этого избежать: Используйте порты выше 1024 (например, 2222) или убедитесь, что SSH работает с соответствующими привилегиями.

Когда использовать эту настройку SSH (а когда нет)

Используйте эту конфигурацию SSH, когда:

• Управление производственными серверами — для серверов, подключенных к интернету, необходима усиленная защита
• Удаленное администрирование серверов — SSH — стандартный инструмент для управления через командную строку
• Автоматизация развертывания — SSH-ключи обеспечивают безопасную автоматизацию без пароля
• Безопасная передача файлов — SCP и SFTP через SSH шифруют передачу файлов
• Доступ к облачным серверам — AWS, DigitalOcean, Linode и т. д. используют SSH
• Управление домашней лабораторией — рекомендуется изучить правильные настройки безопасности
• Управление несколькими серверами — SSH-ключи масштабируются лучше, чем запоминание множества паролей

Не используйте SSH, если:

• Вам нужен графический рабочий стол — используйте VNC или RDP (туннелируйте их через SSH для безопасности)
• Вам нужны полные возможности VPN — туннелирование по SSH имеет ограничения; используйте WireGuard или OpenVPN для подключения от сайта к сайту
• Пользователи — это нетехнические специалисты — SSH-ключи сбивают с толку большинство нетехнических пользователей; рассмотрите веб-панели управления
• Сервер не имеет доступа к сети— только физический доступ, SSH не поможет
• Вам необходимо широко предоставлять общий доступ — SSH-ключи плохо масштабируются для команд из более чем 50 человек; рассмотрите хосты bastion или централизованную аутентификацию

Рассмотрите альтернативные варианты:

• Tailscale SSH: упрощённое управление SSH без переадресации портов или управления ключами
• mosh: мобильная оболочка для нестабильных соединений (роуминг, высокая задержка)
• Веб-терминалы: для пользователей, которым нужен базовый доступ без SSH-клиентов
• Ansible Управление конфигурацией:, Salt, Puppet для управления множеством серверов

Часто задаваемые вопросы (FAQ)

Полный контрольный список мер безопасности SSH

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

Установка и базовая настройка

• ✅ Сервер OpenSSH установлен и работает
• ✅ Служба SSH включена для запуска при загрузке
• ✅ Успешно протестировано подключение по SSH
• ✅ Знайте IP-адрес своего сервера и порт SSH

Важные настройки безопасности

• ✅ Вход в систему с правами root отключен (PermitRootLogin no)
• ✅ Порт SSH изменен с 22 по умолчанию
• ✅ Сгенерированы SSH-ключи (Ed25519 или RSA 4096+)
• ✅ Открытый ключ скопирован на сервер authorized_keys
• ✅ Проверка подлинности по SSH-ключу пройдена
• ✅ Проверка подлинности по паролю отключена (PasswordAuthentication no)

Ужесточение настройки SSH

• ✅ Установлено льготное время для входа в систему (LoginGraceTime 60)
• ✅ Ограничено максимальное количество попыток аутентификации (MaxAuthTries 3)
• ✅ Настроен тайм-аут в режиме ожидания (ClientAliveInterval 300)
• ✅ Только протокол 2 (по умолчанию в Debian 13)
• ✅ Проверено синтаксическое соответствие конфигурации (sudo sshd -t)

Брандмауэр и сетевая безопасность

• ✅ Установлен брандмауэр UFW
• ✅ Порт SSH разрешён в брандмауэре перед включением
• ✅ Брандмауэр включён и активен
• ✅ Для входящих подключений установлена политика запрета по умолчанию
• ✅ Открыты только необходимые порты

Мониторинг и предотвращение атак

• ✅ Инструмент Fail2ban установлен и настроен
• ✅ Fail2ban включен для защиты SSH
• ✅ Служба Fail2ban настроена на запуск при загрузке
• ✅ Знаем, как проверять заблокированные IP-адреса
• ✅ Регулярно проверяем /var/log/auth.log

Управление ключами

• ✅ Закрытые ключи защищены парольными фразами
• ✅ Закрытые ключи имеют правильные разрешения (600)
• ✅ .ssh каталог имеет правильные разрешения (700)
• ✅ Закрытые ключи надёжно защищены
• ✅ Для разных серверов используются разные ключи (рекомендуется)
• ✅ Разработан план ротации ключей

Оперативная безопасность

• ✅ У всех пользователей, которым нужен доступ по SSH, добавлены ключи
• ✅ Старые/неиспользуемые ключи удалены из authorized_keys
• ✅ SSH-соединение работает во всех необходимых местах
• ✅ План восстановления в случае блокировки (доступ к консоли есть)
• ✅ Члены команды проинформированы о новом SSH-порте и требованиях к ключам

Текущее Техническое обслуживание

• ✅ Регулярно устанавливайте обновления безопасности (apt update && apt upgrade)
• ✅ Проверяйте логи SSH на наличие подозрительной активности
• ✅ Периодически проверяйте блокировки fail2ban
• ✅ Проводите аудит authorized_keys раз в квартал
• ✅ Меняйте ключи SSH ежегодно или по мере необходимости

Распечатайте этот контрольный список и отмечайте выполненные пункты. Правильно настроенная система SSH включает в себя ВСЕ эти пункты, а не только некоторые из них.

Заключение

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

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

Сначала настройте SSH. Проверьте подключение. Затем систематически повышайте уровень безопасности.

Затем выполните критически важные действия по обеспечению безопасности, такие как отключение root-доступа, использование SSH-ключей, изменение порта по умолчанию и другие действия, описанные в разделе выше, посвящённом усилению защиты SSH. Это предотвратит 99 % автоматизированных атак. Для правильной реализации может потребоваться 20 минут.

Это не рекомендации. Это требования для любого сервера Linux, подключённого к интернету.

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

Следите за своими логами. Если вы не отслеживаете /var/log/auth.log, то не знаете, подвергаетесь ли вы атаке. По возможности настройте централизованный сервер логирования.

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

Редактор: AndreyEx