Настройка сервера SSH

Сервер SSH (sshd) служит для безопасного удаленного администрирования компьютеров, серверов и других устройств. Информация в данной статье будет полезна для пользователей и администраторов Linux (Ubuntu, Debian, др.) и FreeBSD.

Подключение к серверу SSH

У пользователей UNIX-подобных операционных систем: Linux, Ubuntu, Debian, FreeBSD и др. клиент SSH по умолчанию доступен в системе. Подключение к удаленному устройству не составит труда и осуществляется простой командой: ssh USER@HOSTNAME_OR_IP.

В Windows, для подключения по SSH приходится использовать сторонние утилиты. Самая популярная из них - терминал с открытым исходным кодом PuTTy (putty.exe).

Редактирование настроек сервера SSH

Редактирование настроек сервера SSH производится в файле /etc/ssh/sshd_config. Обратите внимание, файл называется sshD_config, а в файле с очень похожим названием, только без буквы D, настраивается клиент.

Если редактирование конфига SSH проводится удаленно, очень важно не потерять доступ к серверу, после изменения настроек. Всегда, перед использованием, проверяйте sshd_config на ошибки: /usr/sbin/sshd -t. Также, стоит заранее позаботится о резервном доступе к устройству при помощи сервисов провайдера (IP-KVM, Rescue-система и т.п.). В качестве еще одного варианта - можно настроить откат изменений в sshd_config по cron.

Журнал работы (log) sshd ведет в /var/log/auth или /var/log/secure, в зависимости от ОС. Важность и кол-во сообщений в лог-файле зависит от настроек в файле sshd_config (отвечает параметр LogLevel, подробнее о нем - ниже). Если log-файл был удален, то для того, чтобы он вновь появился, необходимо перезапустить Syslog (FreeBSD: service syslogd restart, Ubuntu: sudo service rsyslog restart).

Все изменения, внесенные в /etc/ssh/sshd_config, вступят в силу только после перезагрузки сервиса sshd: service ssh reload или service ssh restart (в CentOS 7 - systemctl restart sshd.service).

Посмотреть статус SSHd можно при помощи такой команды: systemctl status sshd.service (для CentOs 7).

Довольно детальное описание настроек sshd_config на русском находится тут: Настройка SSH - help.ubuntu.ru/wiki/ssh, ниже - список самых востребованных с объяснениями, на что они влияют.

Безопасность sshd

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

В ssh-server время от времени находят серьезные ошибки, позволяющие хакеру, использующему найденные уязвимости, провести успешную попытку взлома системы. Самый простой путь для решения этой проблемы - всегда следить за актуальностью программного обеспечения SSH-сервера и обновлять его сразу, после выхода заплаток или новых стабильных версий. Для более опытных администраторов можно предложить еще один путь: изменить приветственное сообщение, выдаваемое sshd каждому, кто к нему подключается, например: "SSH-2.0-OpenSSH_3.9.1p1 Debian-7.sarge.2". Используя данные из этого приветствия, можно довольно легко проверить, уязвима данная версия или нет, и чтобы не предоставлять лишнюю информацию кому не попадя, стоит воспользоваться инструкцией: Как изменить приветствие SSH-сервиса.

AddressFamily - определяет из каких семейств IP адресов может произойти подключение к sshd: "inet" - только сети с IPv4, "inet6" - только сети с IPv6, "any" - любые сети (по умолчанию). Поскольку протокол IPv6 до сих пор еще не получил широкого распространения и если он не используется на устройстве - стоит установить AddressFamily в inet: AddressFamily inet (значение параметра в файле sshd_config в кавычки брать не нужно).

Port. Огромное количество роботов сканируют 22 порт, на котором по умолчанию работает sshd, в поисках уязвимых версий сервера или пытаясь подобрать пароль. Буквально через несколько часов после подключения устройства с sshd к сети в логах можно наблюдать многочисленные безуспешные попытки подключения (брутфорс). Хороший вариант - изменить назначенный по умолчанию порт 22 на свой, например 7324. Помощь в выборе номера порта может оказать эта статья: Список портов TCP и UDP .

Можно использовать более одного порта, например:

Port 7325
Port 7326
Port 9231

Даже после смены порта по умолчанию попытки подбора пароля могут продолжиться. Чтобы свести успешность таких попыток к минимуму, нужно блокировать каждый IP, с которого производился брутфорс после нескольких безуспешных аутентификаций. Справиться с этой задачей помогут специальные утилиты: Denyhosts, Fail2ban и другие. Пример настройки и использования Denyhosts находится тут: Denyhosts - защищаем ssh, ftp и не только.

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

Protocol - какой протокол использовать: ssh1 (устаревший и не безопасный) или ssh2. Параметр обязательно должен быть установлен в 2: Protocol 2.

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

SyslogFacility AUTH
LogLevel INFO

UseDNS и GSSAPIAuthentication. Если в логах sshd после каждой аутентификации появляются такие сообщения: "reverse mapping checking getaddrinfo and POSSIBLE BREAK-IN ATTEMPT error messages via SSH" можно установить эти 2 параметра в no и не беспокоится по поводу "reverse mapping checking getaddrinfo" и "POSSIBLE BREAK-IN ATTEMPT" error messages via SSH. Подробнее о том, почему возникают такие ошибки и об альтернативных методах их решения можно узнать тут: Possible break-in attempt (eng).

PermitEmptyPasswords по умолчанию установлен в no, что не позволит зайти в систему пользователю с пустым (не установленным) паролем.

PasswordAuthentication - использовать (yes - по умолчанию) или нет (no) аутентификацию по паролю. Наиболее безопасный способ аутентификации на сегодняшний день - аутентификация по ключам. Для этого нужно предварительно создать пару ключей (публичный и приватный), отправить SSH-серверу публичный ключ, проверить работу аутентификации по ключам и только после этого устанавливать PasswordAuthentication в no. Инструкцию по работе с ssh-key можно прочитать тут: SSH, аутентификация по ключам, ssh-keygen, ssh-agent.

PermitRootLogin - разрешить или нет вход пользователя root по ssh. Возможные значения: "yes" - root может зайти по SSH, "no" - root НЕ может зайти по SSH, "without-password" - root может пройти аутентификацию только с использованием ssh-key, "forced-commands-only" - допускает вход пользователя root по открытому ключу, но только если установлен параметр command.

Sftp на базе sshd

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

  • Параметру Subsystem прописывается такое значение: sftp internal-sftp.
  • После UsePAM yes с новой строки:
    Match Group sftp
        AllowTcpForwarding no
        X11Forwarding no
        ForceCommand internal-sftp
        ChrootDirectory /home/%u
     
  • Перезапустить SSHd

Применив подобные настройки, всем пользователям, которые состоят в группе sftp будет открыт доступ к своим домашним директориям. Чтобы пользователи из группы sftp не смогли зайти в систему по SSH, им нужно в качестве оболочки установить /bin/false. В качестве примера ниже будет создан пользователь ernest, который сможет получить доступ к своим файлам при помощи sftp:

# groupadd sftp
# useradd -d /home/ernest -m ernest -G sftp -s /bin/false
# passwd ernest
# mkdir /home/ernest/files
# chown ernest:ernest /home/ernest/files
# chown root:root /home/ernest

Следует учесть, что директории /home и /home/ernest должны принадлежать пользователю и группе root, для того, чтобы сработала директива ChrootDirectory из файла sshd_conf.

Проверить работоспособность можно так:

# which sftp
# sftp ernest@SERVER_IP_OR_HOSTNAME
sftp> pwd
sftp> quit

Опубликовано: 2016/02/19
HTML-код ссылки на эту страницу:
<a href="https://petrenco.com/freebsd.php?txt=508" target="_blank">Настройка SSH-сервера</a>
7356
Добавить комментарий
Ваш e-mail: (не виден посетителям сайта)
Ваше имя:
Комментарий:
Символы с картинки:
Только выделенные поля формы добавления комментариев обязательны к заполнению.