Настройка доступа к серверу по SSH ключу

В современной цифровой инфраструктуре безопасный и автоматизированный доступ к серверу необходим системным администраторам, разработчикам и инженерам DevOps. Аутентификация на основе ключей SSH является наиболее распространенным и надежным способом. SSH-ключи повышают безопасность, устраняя необходимость входа по паролю, и позволяют упростить автоматизацию, особенно при управлении несколькими серверами или интеграции конвейеров CI/CD. В этой статье мы подробно рассмотрим настройку доступа к серверу с помощью ключей SSH и рассмотрим ее с практической и административной точек зрения.

Что такое SSH и аутентификации на основе ключей

SSH, или Secure Shell, - это протокол, обеспечивающий безопасный удаленный вход в систему и выполнение команд на удаленном сервере. По умолчанию SSH использует аутентификацию по паролю, но этот метод подвержен атакам перебора и утечке учетных данных. Аутентификация на основе ключей SSH - очевидный выбор: более безопасный и удобный.

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

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

Генерация ключей SSH

Прежде чем настраивать сервер для доступа по ключу SSH, необходимо сгенерировать пару ключей. Обычно это делается на клиентской машине с помощью инструмента ssh-keygen, который по умолчанию доступен во всех основных Unix-подобных системах.

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

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

    Расположение: По умолчанию ключ хранится в ~/.ssh/id_rsa (приватный) и ~/.ssh/id_rsa.pub (публичный).
    Ключевая фраза: Необязательна, но настоятельно рекомендуется для дополнительной безопасности. С ее помощью закрытый ключ шифруется локально.

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

Копирование открытого ключа на сервер

После того как пара ключей сгенерирована, открытый ключ необходимо скопировать на целевой сервер. Это можно сделать вручную или с помощью средств автоматизации. Проще всего это сделать с помощью ssh-copy-id:

    ssh-copy-id -i ~/.ssh/id_rsa.pub user@remote_host

Эта команда добавляет открытый ключ в файл ~/.ssh/authorized_keys указанного пользователя на сервере. Она также обеспечивает правильные права доступа к каталогу .ssh и файлу authorized_keys - оба эти параметра важны для успешной аутентификации.

В качестве альтернативы можно скопировать открытый ключ вручную:

    cat ~/.ssh/id_rsa.pub | ssh user@remote_host «mkdir -p ~/.ssh && chmod 700 ~/.ssh && cat >> ~/.ssh/authorized_keys && chmod 600 ~/.ssh/authorized_keys»

С точки зрения безопасности очень важно, чтобы каталог ~/.ssh имел права 700, а authorized_keys был установлен на 600. В противном случае OpenSSH может отказаться использовать ключ для аутентификации.

Отключение проверки подлинности пароля (необязательно, но рекомендуется)

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

    sudo nano /etc/ssh/sshd_config

Найдите или добавьте следующие строки:

    PasswordAuthentication no
    ChallengeResponseAuthentication no
    UsePAM no

После внесения изменений перезапустите службу SSH:

    sudo systemctl restart sshd

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

Другие полезные статьи в нашем Блоге:

    - Передача файлов с помощью SSH в Linux

    - Краткое руководство по базовой настройке SSH на вашем сервере Debian

    - Команда Linux scp и примеры ее использования

    - Как использовать Rsync для синхронизации локальных и удаленных каталогов

Управление несколькими ключами и пользователями

В средах, где нескольким пользователям требуется доступ к одному серверу или где системы автоматизации (например, Ansible или CI/CD runners) требуют отдельного доступа, важно тщательно управлять открытыми ключами.

Каждый открытый ключ должен быть уникально идентифицируемым и может быть добавлен в файл authorized_keys вместе с комментарием:

    ssh-rsa AAAAB3Nza... user1@laptop
    ssh-ed25519 AAAAC3Nza... deploy-bot@ci

Для упрощения управления инструменты управления конфигурацией, такие как Ansible, Puppet или Chef, могут автоматически распределять и управлять ключами SSH на нескольких узлах. Кроме того, такие инструменты, как HashiCorp Vault или AWS Secrets Manager, обеспечивают безопасное хранение и ротацию ключей.

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

Использование конфигурации SSH для упрощения доступа

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

    Host web-server
    HostName 192.168.1.100
    User ubuntu
    IdentityFile ~/.ssh/id_rsa

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

Например, чтобы подключиться через бастионный хост (jump host):

    Host internal-server
    HostName 10.0.0.2
    User dev
    IdentityFile ~/.ssh/dev_key
    ProxyJump bastion-host

Лучшие практики безопасности

Несмотря на присущую SSH-ключам безопасность, следует соблюдать несколько лучших практик:

    - Используйте надежную парольную фразу для закрытых ключей, особенно если они хранятся на ноутбуках или в общих системах.
    - Избегайте входа в систему с правами root: Разрешайте аутентификацию только обычным пользователям, а затем повышайте привилегии с помощью sudo.
    - Контролируйте доступ к SSH с помощью файлов журналов (/var/log/auth.log) или таких инструментов безопасности, как Fail2Ban, которые блокируют IP-адреса после нескольких неудачных попыток.
    - Ограничьте диапазоны IP-адресов, с которых разрешен доступ к SSH, с помощью правил брандмауэра или sshd_config с параметрами AllowUsers или Match Address.
    - Рассмотрите возможность использования аппаратных модулей безопасности (HSM) или YubiKeys для хранения закрытых ключей, особенно в средах с высоким уровнем безопасности.

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

Заключение

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

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