Управление доступом к серверу через SSH

Управление доступом к серверу через SSH

Управление доступом к серверу через SSH (Secure Shell) — это краеугольный камень безопасности любой удаленной инфраструктуры. Оно осуществляется путем тщательной настройки аутентификационных механизмов и конфигурационных параметров самого демона SSH (sshd) на сервере, а также правильного использования клиентских утилит. Наша главная задача — обеспечить надежную, криптографически защищенную связь и строгий контроль над тем, кто может получить командную строку на удаленной машине. Это достигается преимущественно за счет использования SSH-ключей вместо паролей, а также путем ужесточения настроек SSH-сервера, таких как отключение входа для root-пользователя, изменение стандартного порта и применение дополнительных средств мониторинга и защиты. В этой статье мы, команда Valebyte, поделимся проверенными практиками, которые помогут вам построить крепкую линию обороны для ваших серверов.

Почему SSH — наш главный инструмент?


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

        Конфиденциальность: Весь трафик между клиентом и сервером шифруется, защищая данные от перехвата.
        Целостность: SSH гарантирует, что передаваемые данные не были изменены в пути.
        Аутентификация: Сервер проверяет подлинность клиента, а клиент может проверить подлинность сервера, предотвращая атаки типа "человек посередине".
    
    Однако, как и любой мощный инструмент, SSH требует грамотной настройки. Без должного внимания к деталям, даже самые надежные механизмы могут стать уязвимыми.


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

        Приватный ключ (Private Key): Хранится строго на вашем локальном компьютере и НИКОГДА не покидает его. Он должен быть защищен парольной фразой (passphrase).
        Публичный ключ (Public Key): Размещается на сервере, к которому вы хотите получить доступ. Его можно свободно распространять.
    
    При подключении клиент использует приватный ключ для создания криптографической подписи, которую сервер проверяет с помощью соответствующего публичного ключа. Это намного надежнее, чем передача пароля по сети.


Генерация SSH-ключей
Для создания пары ключей используйте команду ssh-keygen. Мы рекомендуем использовать алгоритм Ed25519 как более современный и эффективный, но RSA с длиной ключа 4096 бит также является хорошим выбором.

ssh-keygen -t ed25519 -C "ваша_почта@example.com"

В процессе генерации вам будет предложено сохранить ключ в определенном файле (по умолчанию ~/.ssh/id_ed25519) и ввести парольную фразу. Обязательно используйте надежную парольную фразу! Это дополнительный уровень защиты вашего приватного ключа на случай, если кто-то получит к нему доступ.
После генерации у вас появится два файла в директории ~/.ssh/:
    

        id_ed25519 (ваш приватный ключ)
        id_ed25519.pub (ваш публичный ключ)
    


Размещение публичного ключа на сервере
Самый простой и безопасный способ добавить ваш публичный ключ на сервер — это использовать утилиту ssh-copy-id:

ssh-copy-id -i ~/.ssh/id_ed25519.pub user@your_server_ip

Эта команда скопирует ваш публичный ключ на удаленный сервер в файл ~/.ssh/authorized_keys пользователя user и автоматически установит правильные права доступа. Если ssh-copy-id недоступна или вы предпочитаете ручной метод, вот как это сделать:

    Скопируйте содержимое вашего публичного ключа:
        
cat ~/.ssh/id_ed25519.pub
        
    
    Подключитесь к серверу по SSH (если это первое подключение, возможно, придется использовать пароль).
    Создайте директорию .ssh, если ее нет, и установите правильные права:
        
mkdir -p ~/.ssh
chmod 700 ~/.ssh
        
    
    Добавьте ваш публичный ключ в файл authorized_keys:
        
echo "СОДЕРЖИМОЕ_ВАШЕГО_ПУБЛИЧНОГО_КЛЮЧА" >> ~/.ssh/authorized_keys
chmod 600 ~/.ssh/authorized_keys
        
        Важно: Замените "СОДЕРЖИМОЕ_ВАШЕГО_ПУБЛИЧНОГО_КЛЮЧА" на вывод команды cat ~/.ssh/id_ed25519.pub. Убедитесь, что права доступа для ~/.ssh установлены в 700, а для ~/.ssh/authorized_keys — в 600. Неправильные права доступа могут помешать аутентификации.
    


Управление несколькими SSH-ключами и хостами через ~/.ssh/config
Для системных администраторов, работающих с десятками, а то и сотнями серверов, ручное указание ключей и пользователей для каждого подключения быстро становится утомительным. Здесь на помощь приходит файл конфигурации SSH-клиента ~/.ssh/config.
Пример файла ~/.ssh/config:

Host valeserver-dev
    HostName 192.168.1.100
    User devuser
    IdentityFile ~/.ssh/id_ed25519_dev
    Port 2222
    # StrictHostKeyChecking no # Не рекомендуется для продакшена!

Host valeserver-prod
    HostName prod.valebyte.com
    User admin
    IdentityFile ~/.ssh/id_rsa_prod
    ForwardAgent yes # Подробнее об этом ниже

Host *
    User defaultuser
    Port 22
    ServerAliveInterval 60
    AddKeysToAgent yes
    IdentitiesOnly yes

Теперь вы можете просто набрать ssh valeserver-dev или ssh valeserver-prod, и SSH-клиент автоматически подставит все необходимые параметры. Директива Host * применяет настройки по умолчанию для всех хостов, если они не переопределены более специфичными правилами.

  
    Нужен надежный сервер для безопасного SSH?
  
  
    Защитите свой SSH-доступ с помощью наших надежных VPS. Получите полный контроль над разрешениями пользователей. — from €4.49/mo.
  
  
    Выбрать VPS-план →
  

Ужесточаем настройки SSH-сервера (sshd_config)
После того, как вы успешно настроили доступ по ключам, пришло время затянуть гайки на стороне сервера. Основной конфигурационный файл SSH-демона — это /etc/ssh/sshd_config. Всегда делайте резервную копию этого файла перед внесением изменений!

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

# /etc/ssh/sshd_config
PasswordAuthentication no
ChallengeResponseAuthentication no
UsePAM no # Отключите, если не используете PAM для аутентификации

После этого сервер будет принимать только подключения по ключам. Любые попытки аутентификации по паролю будут отклонены.

Запрещаем вход для root-пользователя
Прямой вход под root — это огромная дыра в безопасности. Если злоумышленник подберет пароль или ключ для root, он получит полный контроль над сервером. Всегда входите под обычным пользователем, а затем используйте sudo для выполнения административных задач.

# /etc/ssh/sshd_config
PermitRootLogin no

Если вам действительно нужно разрешить root-доступ по ключам, можно использовать PermitRootLogin prohibit-password. Но мы настоятельно рекомендуем PermitRootLogin no.

Изменяем стандартный порт SSH
Стандартный порт SSH (22) является целью постоянных сканирований и атак. Изменение его на нестандартный порт (например, 2222, 22222 или любой другой свободный порт >1024) — это не панацея, но значительно снижает объем "шума" в логах и отсекает автоматизированные боты, которые сканируют только стандартные порты.

# /etc/ssh/sshd_config
Port 2222

Не забудьте обновить правила файрвола (ufw, firewalld, iptables), чтобы разрешить входящие соединения на новом порту, и перезапустить sshd. И, конечно, обновите ваш ~/.ssh/config!

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

# /etc/ssh/sshd_config
AllowUsers user1 user2
AllowGroups sysadmins

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

Перезапуск службы SSH
После любых изменений в /etc/ssh/sshd_config всегда необходимо перезапустить службу SSH, чтобы новые настройки вступили в силу:

sudo systemctl reload sshd # Или restart

Важный совет: Прежде чем закрыть текущую SSH-сессию после изменения sshd_config, откройте новую сессию в другом терминале и убедитесь, что вы можете подключиться с новыми настройками. Если что-то пойдет не так, у вас останется активная сессия для отката изменений. Это спасет вас от блокировки доступа к собственному серверу!

Удобство и безопасность: SSH-агент
Ввод парольной фразы для каждого ключа при каждом подключении может быть утомительным. SSH-агент (ssh-agent) решает эту проблему. Он запускается как фоновый процесс, хранит расшифрованные приватные ключи в памяти и предоставляет их SSH-клиенту по запросу, избавляя вас от многократного ввода парольной фразы.
Как это работает:

    Запустите ssh-agent (обычно он запускается автоматически при старте графической среды или через команды вроде eval "$(ssh-agent -s)").
    Добавьте ваши приватные ключи в агент:
        
ssh-add ~/.ssh/id_ed25519
ssh-add ~/.ssh/id_rsa_prod # Если у вас несколько ключей
        
        При этом вам будет предложено ввести парольную фразу для каждого ключа один раз.
    
    Теперь вы можете подключаться к серверам, не вводя парольную фразу, пока агент активен.

Директива ForwardAgent yes в ~/.ssh/config позволяет "перенаправлять" SSH-агент, чтобы вы могли использовать ключи с вашей локальной машины для аутентификации с сервера на другой сервер (SSH-прыжки), не копируя приватные ключи на промежуточный сервер. Это очень удобно и безопасно.

Дополнительные меры безопасности

    Fail2Ban: Установите и настройте Fail2Ban. Эта утилита автоматически банит IP-адреса, с которых происходят многочисленные неудачные попытки входа по SSH, эффективно защищая от брутфорс-атак.
    Мониторинг логов: Регулярно просматривайте логи SSH-доступа (/var/log/auth.log или /var/log/secure) на предмет подозрительной активности.
    Обновления: Всегда держите SSH-сервер и клиент в актуальном состоянии, устанавливая обновления безопасности.
    Многофакторная аутентификация (MFA/2FA): Для максимальной защиты рассмотрите возможность интеграции MFA с SSH, например, через PAM-модули и Google Authenticator. Это добавит еще один слой безопасности поверх ключей.


Выводы
Правильное управление доступом к серверу через SSH — это не просто рекомендация, а критически важный элемент любой серьезной стратегии кибербезопасности. Отказ от паролей в пользу SSH-ключей, тщательная настройка sshd_config с отключением root-доступа и изменением стандартного порта, а также использование SSH-агента и дополнительных инструментов вроде Fail2Ban, позволяют создать надежный и удобный контур безопасности.
Помните, что безопасность — это непрерывный процесс. Регулярно пересматривайте свои настройки, следите за обновлениями и будьте бдительны. Наши серверы — это наша ответственность, и с Valebyte вы всегда можете рассчитывать на инструменты и знания, которые помогут вам держать их под надежным контролем. Удачи в вашей работе, коллеги!