Пошаговое руководство по безопасной аутентификации на основе ключей SSH

Повысьте безопасность удаленного доступа с помощью этого всеобъемлющего пошагового руководства по аутентификации на основе ключей SSH. Узнайте, как генерировать надежные пары ключей ED25519, безопасно распространять свой открытый ключ и, что особенно важно, отключать уязвимый вход по паролю на вашем сервере. В этом руководстве представлены практические команды и основные лучшие практики, включая использование кодовых фраз и управление ключами, что гарантирует удобство и высокую безопасность ваших SSH-соединений. Повысьте защиту своего сервера от атак методом подбора (brute-force) уже сегодня.

27 просмотров

Пошаговое руководство по настройке безопасной аутентификации на основе SSH-ключей

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

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

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

Аутентификация на основе SSH-ключей опирается на пару криптографически связанных ключей: закрытый ключ и открытый ключ.

  • Закрытый ключ (Private Key): Этот ключ должен оставаться секретным и защищенным на вашей локальной машине. Он подобен очень сложному паролю, который есть только у вас.
  • Открытый ключ (Public Key): Этот ключ можно свободно распространять, и он размещается на удаленном сервере, к которому вы хотите получить доступ. Сервер использует его для проверки вашей личности.

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

Шаг 1: Генерация пары SSH-ключей

Утилита ssh-keygen используется для создания новых пар SSH-ключей. Рекомендуется использовать современные, сильные алгоритмы, такие как ED25519.

Выберите тип и стойкость ключа

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

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

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

ssh-keygen -t ed25519 -C "[email protected]"
  • -t ed25519: Указывает тип ключа как ED25519.
  • -C "[email protected]": Добавляет комментарий к открытому ключу, часто используемый для идентификации. Замените на свой реальный адрес электронной почты или описательную метку.

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

Generating public/private ed25519 key pair.
Enter file in which to save the key (/home/youruser/.ssh/id_ed25519): 
Enter passphrase (empty for no passphrase): 
Enter same passphrase again: 
Your identification has been saved in /home/youruser/.ssh/id_ed25519
Your public key has been saved in /home/youruser/.ssh/id_ed25519.pub
The key fingerprint is: SHA256:...
The key's randomart image is: ...

Установите надежную кодовую фразу (настоятельно рекомендуется)

Когда будет предложено, всегда устанавливайте надежную кодовую фразу для вашего закрытого ключа. Эта кодовая фраза шифрует ваш закрытый ключ на вашей локальной машине, обеспечивая дополнительный уровень безопасности. Если ваш закрытый ключ когда-либо попадет в чужие руки, он будет бесполезен без кодовой фразы. Вы можете использовать ssh-agent, чтобы избежать многократного ввода кодовой фразы (см. Шаг 4).

Расположение файлов ключей

По умолчанию ssh-keygen сохраняет ваш закрытый ключ в ~/.ssh/id_ed25519 и ваш открытый ключ в ~/.ssh/id_ed25519.pub.

Разрешения для вашего закрытого ключа

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

chmod 600 ~/.ssh/id_ed25519

Шаг 2: Распространение вашего открытого ключа на сервер

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

Метод 1: Использование ssh-copy-id (рекомендуется)

ssh-copy-id — самый простой и безопасный метод. Он входит на удаленный сервер (используя ваш пароль), создает каталог ~/.ssh, если он не существует, устанавливает правильные разрешения и добавляет ваш открытый ключ в ~/.ssh/authorized_keys.

ssh-copy-id user@your_server_ip

Замените user на ваше имя пользователя на удаленном сервере, а your_server_ip — на IP-адрес или имя хоста сервера. Вам будет предложено ввести пароль на удаленном сервере.

Метод 2: Ручное копирование

Если ssh-copy-id недоступен, вы можете скопировать открытый ключ вручную.

  1. Скопируйте содержимое открытого ключа со своей локальной машины:
    bash cat ~/.ssh/id_ed25519.pub
    Скопируйте весь вывод в буфер обмена (он начинается с ssh-ed25519 ...).

  2. Войдите на удаленный сервер, используя свой пароль:
    bash ssh user@your_server_ip

  3. Создайте каталог ~/.ssh, если он не существует, и установите разрешения:
    bash mkdir -p ~/.ssh chmod 700 ~/.ssh

  4. Добавьте ваш открытый ключ в authorized_keys:
    bash echo "PASTE_YOUR_PUBLIC_KEY_HERE" >> ~/.ssh/authorized_keys
    Убедитесь, что вы заменили PASTE_YOUR_PUBLIC_KEY_HERE на фактическое содержимое, которое вы скопировали. Использование >> (добавление) важно, чтобы избежать перезаписи существующих ключей, если таковые имеются.

  5. Установите правильные разрешения для authorized_keys:
    bash chmod 600 ~/.ssh/authorized_keys

    • Внимание: Неправильные разрешения на ~/.ssh или ~/.ssh/authorized_keys предотвратят работу аутентификации на основе ключей.

Шаг 3: Проверьте аутентификацию на основе SSH-ключей

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

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

ssh user@your_server_ip
  • Если вы установили кодовую фразу для своего закрытого ключа, вам будет предложено ввести ее.
  • Если соединение успешно без запроса пароля (после кодовой фразы, если применимо), ваша аутентификация на основе ключей работает. Вы должны увидеть приглашение удаленного сервера.

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

Шаг 4: Повышение безопасности — Отключение аутентификации по паролю

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

  1. Войдите на удаленный сервер, используя свой SSH-ключ.
    bash ssh user@your_server_ip

  2. Отредактируйте файл конфигурации демона SSH. Этот файл обычно находится по адресу /etc/ssh/sshd_config.
    bash sudo nano /etc/ssh/sshd_config
    (Вы можете использовать vi или ваш предпочтительный текстовый редактор вместо nano.)

  3. Найдите и измените следующие директивы:

    • Найдите PasswordAuthentication и измените его значение на no.
      #PasswordAuthentication yes PasswordAuthentication no
      (Раскомментируйте строку, если она закомментирована #)

    • Найдите ChallengeResponseAuthentication и измените его значение на no.
      #ChallengeResponseAuthentication yes ChallengeResponseAuthentication no

    • (Необязательно, но рекомендуется) Рассмотрите возможность отключения прямого входа root через SSH, если вы планируете использовать sudo после входа в систему как обычный пользователь.
      PermitRootLogin no

    • (Необязательно) Рассмотрите возможность изменения стандартного порта SSH с 22 на нестандартный высокий порт (например, 2222). Это не повышает безопасность от целенаправленных атак, но может уменьшить шум от автоматических сканеров портов.
      #Port 22 Port 2222
      Если вы измените порт, не забудьте указать его с флагом -p при подключении (например, ssh -p 2222 user@your_server_ip).

  4. Сохраните изменения и выйдите из текстового редактора.

  5. Перезапустите службу SSH, чтобы применить новую конфигурацию. Команда немного варьируется в зависимости от вашей операционной системы (например, Ubuntu/Debian против CentOS/RHEL).

    • Системы на основе Systemd (большинство современных дистрибутивов Linux):
      bash sudo systemctl restart sshd

    • Старые системы на основе SysVinit:
      bash sudo service ssh restart

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

    bash ssh user@your_server_ip
    Если вы изменили порт:
    bash ssh -p 2222 user@your_server_ip

    Если соединение успешно, вы можете безопасно закрыть свою исходную SSH-сессию.

    Если новый вход не удался, немедленно отмените изменения в sshd_config в вашей исходной, все еще активной SSH-сессии и снова перезапустите службу SSH, затем переоцените ситуацию.

Лучшие практики и советы

  • Всегда используйте надежную кодовую фразу для вашего закрытого ключа. Это ваша последняя линия защиты, если ваш закрытый ключ скомпрометирован.
  • Защитите свой закрытый ключ. Никогда не делитесь им и убедитесь, что он надежно хранится со строгими разрешениями файлов (chmod 600 ~/.ssh/id_ed25519). Рассмотрите аппаратные модули безопасности (HSM) или YubiKey для максимальной защиты.
  • Используйте ssh-agent для удобства. ssh-agent позволяет загружать ваши закрытые ключи в память и вводить кодовую фразу только один раз за сеанс, даже при нескольких SSH-подключениях. Добавьте свой ключ в агент с помощью ssh-add ~/.ssh/id_ed25519.
  • Регулярно меняйте свои SSH-ключи. Периодически генерируйте новые пары ключей и удаляйте старые открытые ключи с ваших серверов, особенно если член команды уходит или есть подозрения на компрометацию ключа.
  • Ограничьте PermitRootLogin до no или prohibit-password. Обычно лучше входить как обычный пользователь и использовать sudo для административных задач.
  • Настройте брандмауэр. Убедитесь, что только необходимые порты (например, ваш SSH-порт) открыты для Интернета. Инструменты, такие как ufw или firewalld, могут помочь.

Заключение

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

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