Работа с клиентом и сервером SSH

Описание принципов работы и используемых приложений
Установка
Настройка сервера
Рекомендуемые параметры безопасности
Максимальное число попыток аутентификации
Время ожидания регистрации пользователя в системе
Списки пользователей sshd
Запрещение удаленного доступа для суперпользователя
Парольная аутентификация
Аутентификация на основе SSH2 RSA-ключей
Настройка SSH-клиента
Утилита screen
SSH aliases
SFTP
Монтирование удаленной директории с помощью sshfs
Запуск графических приложений через SSH
Копирование файлов SCP
Подключение через MC (Midnight Commander)
Диагностика проблем подключения

Данная статья посвящена клиенту и серверу защищенного терминала (secure shell) в РЕД ОС, их настройке и использованию. SSH — это специальный сетевой протокол, позволяющий получать удаленный доступ к компьютеру с большой степенью безопасности соединения.

Описание принципов работы и используемых приложений

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

Установка

По умолчанию сервер и клиент OpenSSH уже установлен в РЕД ОС. Однако, при необходимости, его можно установить из терминала командой:

sudo dnf install openssh

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

Для его остановки и запуска используйте команды:

sudo systemctl stop sshd
sudo systemctl start sshd

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

sudo systemctl restart sshd

Рекомендуемые параметры безопасности

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

Port, ListenAddress и AddressFamily

Эти три параметра определяют, на каких портах и адресах ваш сервер будет ждать входящие соединения. Во-первых, имеет смысл по возможности ограничить семейство обрабатываемых адресов реально используемыми, т. е. если вы используете только IPv4 — отключите IРv6, и наоборот. Сделать это можно при помощи параметра AddressFamily, например (для разрешения IPv4 и запрета IPv6):

AddressFamily inet

Во-вторых, если ваш ssh-сервер имеет выход в интернет, либо находится в незащищённой сети, желательно сменить стандартный порт (22), на котором слушает sshd. Это связано с тем, что многочисленные сетевые сканеры постоянно пытаются соединиться с 22-м портом и, как минимум, получить доступ путем перебора логинов/паролей из своей базы. Даже если у вас и отключена парольная аутентификация — эти попытки сильно засоряют журналы и (в большом количестве) могут негативно повлиять на скорость работы ssh-сервера. Если же вы по какой-либо причине не желаете изменить стандартный порт, вы можете использовать различные внешние утилиты для борьбы брутфорсерами, например fail2ban.
Задать порт можно как абсолютным значением для всех интерфейсов при помощи директивы Port, так и конкретным значением для каждого интерфейса, при помощи директивы ListenAddress. Например:

Port 2002

или

ListenAddress 192.168.0.1:2003
ListenAddress 192.168.1.1:2004

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

sudo semanage port -a -t ssh_port_t -p tcp #PORTNUMBER

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

ssh -p 2002 user@server

Максимальное число попыток аутентификации

MaxAuthTries

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

Время ожидания регистрации пользователя в системе

LoginGraceTime

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

Списки пользователей sshd

AllowUsers user

В файле настроек /etc/ssh/sshd_config может быть прописан список пользователей, разделённых пробелом, которым можно пользоваться sshd. По умолчанию — не указан = разрешено всем. Т.е. если указан хотя бы один пользователь, ssh доступ к серверу доступен только для него.

AllowGroups users

Список шаблонов имён групп через пробел. Если параметр определён, регистрация в системе разрешается только пользователям, чья главная или вспомогательная группы соответствуют какому-либо из шаблонов. Допустимы только имена групп; числовой идентификатор группы не распознаётся. По умолчанию разрешена регистрация в системе для членов всех групп. Разрешающие/запрещающие (allow/deny) директивы обрабатываются в следующем порядке: DenyUsers AllowUsers DenyGroups AllowGroups. Подробнее см. "Конфигурационный файл SSHD_CONFIG"

Запрещение удаленного доступа для суперпользователя

Учетная запись root часто является целью хакеров. Доступ к учетной записи через root по протоколу SSH на сервере Linux, который работает в сети или в Интернете, может представлять серьезную угрозу безопасности.
По умолчанию root-доступ по паролю разрешён. Если есть пользователь, который имеет возможность решать все административные задачи через sudo, то рекомендуется совсем отключить root-доступ по ssh. Отключить эту опцию можно так:

PermitRootLogin no

Парольная аутентификация

Разрешенная по умолчанию парольная аутентификация является практически самым примитивным способом авторизации в sshd. С одной стороны, это упрощает конфигурацию и подключение новых пользователей (пользователю достаточно знать свой системный логин/пароль), с другой стороны пароль всегда можно подобрать, а пользователи часто пренебрегают созданием сложных и длинных паролей. Специальные боты постоянно сканируют доступные из интернета ssh-сервера и пытаются авторизоваться на них путем перебора логинов/паролей из своей базы. Настоятельно не рекомендуется использовать парольную аутентификацию. Отключить ее можно так:

PasswordAuthentication no

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

PermitEmptyPasswords no

Аутентификация на основе SSH2 RSA-ключей

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

Для включения аутентификации по публичному ключу в файле конфигурации сервера /etc/ssh/sshd_config для параметра PubkeyAuthentication укажите значение yes:

PubkeyAuthentication yes

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

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

• для схемы с общим файлом:

AuthorizedKeysFile /etc/ssh/authorized_keys

• для схемы пользователь — файл:

AuthorizedKeysFile .ssh/authorized_keys

По умолчанию SSH-клиент ищет ключи в файле .ssh/authorized_keys, т. е. по схеме пользователь-файл.

Настройка SSH-клиента

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

ssh-keygen -t rsa

Получаем предложение ввести пароль для защиты файла ключа (оказывается полезным при попадании файла в чужие руки). Если мы собираемся по SSH выполнять скрипты, то оставляем пароль пустым. Передаём публичный ключ на сервер командой:

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

Всё, можно заходить:

ssh user@server

Когда ssh работает на нестандартном порту:

ssh-copy-id -i ~/.ssh/id_rsa.pub -p port user@server

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

ssh-copy-id ’-i /home/user/.ssh/id_rsa.pub -p port user@server’

Завершающий этап настройки: отключение парольной аутентификации на сервере, см. «Парольная аутентификация».

tcp_wrapper выполняет управление доступом только для приложений, разработанных на основе протокола TCP и вызывающих библиотеку libwrap. После удаления зависимости libwrap из openssh перестанут действовать правила, определенные в файле /etc/hosts.deny. Для блокирования нежелательного трафика необходимо использовать брандмауэры iptables/nftables на сетевом уровне или использовать аналогичную фильтрацию на уровне приложений, поскольку они не имеют подобных ограничений.

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

sudo dnf install tcp_wrappers

1. Отключите службу sshd:

systemctl disable sshd

2. Создайте каталог /etc/systemd/system/sshd@.service.d/ для переопределения конфигурации:

mkdir -p /etc/systemd/system/sshd@.service.d/

3. Создайте переопределяющий файл конфигурации для службы SSH /etc/systemd/system/sshd@.service.d/override.conf:

nano /etc/systemd/system/sshd@.service.d/override.conf

4. В переопределяющий файл добавьте параметр ExecStart из файла конфигурации по умолчанию, добавив в значение @-/usr/sbin/tcpd:

grep '^ExecStart=' /usr/lib/systemd/system/sshd@.service | sed 's#[^\/]*\(.*\)#ExecStart=@-/usr/sbin/tcpd \1#' >>/etc/systemd/system/sshd@.service.d/override.conf

Пример содержимого переопределяющего файла конфигурации:

 cat /etc/systemd/system/sshd@.service.d/override.conf 

[Unit] 
ConditionFileIsExecutable=/usr/sbin/tcpd 

[Service] 
ExecStart= 
ExecStart=@-/usr/sbin/tcpd /usr/sbin/sshd -i $OPTIONS

5. Измените политику SELinux для отслеживания трафика по TCP:

setsebool -P ssh_use_tcpd=1

6. Перезапустите конфигурацию systemctl:

systemctl daemon-reload

7. Запустите и добавьте в автозагрузку сокет sshd:

systemctl enable --now sshd.socket

8. Проверьте подключение к новой службе:

ssh localhost

Подключение должно произойти вне зависимости от содержимого файлов /etc/hosts.allow и /etc/hosts.deny.

9. Внесите изменения в файл запрещенных соединений /etc/hosts.deny:

nano /etc/hosts.deny

10. Убедитесь, что содержимое файла /etc/hosts.deny зафиксировано:

 ssh localhost 

kex_exchange_identification: read: Connection reset by peer 
Connection reset by ::1 port 22 

Соединение должно быть заблокировано.

11. Заблокированное соединение также должно быть зафиксировано в журнале:

 journalctl -t sshd | grep refused 

окт 17 16:19:44 localhost.localdomain sshd[4249]: refused connect from ::1 (::1)

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

Утилита screen

Screen – это приложение, позволяющее запускать несколько виртуальных терминалов в режиме сессий. После того как сессия создана, от неё можно отключиться, а позже — снова подключиться, причём с любого другого хоста, на котором установлен SSH-клиент. Процессы, запущенные в screen, продолжают выполняться и после того как пользователь отключается от сессии или вообще от хоста в целом.

Для установки программы screen на сервере выполните команду:

dnf install screen

Подключаемся к серверу:

ssh user@server

После подключения создаем новую сессию screen с названием session1:

screen -S session1

Затем выполняем на сервере необходимые действия и команды. Для примера запустим ping до ресурса ya.ru:

ping ya.ru

Для отключения от сессии нажмем сочетание «Ctrl+a d». При этом процесс ping продолжит выполнение, даже если разорвать ssh-подключение к серверу. Чтобы вернуться в нашу сессию выполним команду:

screen -r session1

Можно увидеть, что утилита ping все еще будет работать.

Более подробную информацию о работе с терминальными мультиплексорами описана в статье Терминальные мультиплексоры.

SSH aliases

При использовании нескольких серверов с различными параметрами доступа (нестандартный порт, длинное имя хоста, логин отличный от локального, и т.п.) приходится каждый раз вводить настройки подключения заново. Чтобы облегчить этот процесс, можно использовать псевдонимы — aliases.

Настройки хранятся в ~/.ssh/config для одного пользователя и в /etc/ssh/ssh_config глобально для всех пользователей.

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

Открываем с помощью текстового редактора нужный нам файл настроек (для одного пользователя или глобальный) и добавляем следующие строки:

Host AliasName 
HostName 1.2.3.4 
User YourUserName 
Port YourSSHPort

Где:

• Host  — алиас (псевдоним) для удаленного сервера;
• HostName  — IP-адрес или доменное имя (если работает DNS) удаленного сервера;
• User  — имя пользователя для соединения по SSH;
• Port  — порт SSH на удаленном сервере.

Таким образом может быть описано множество серверов.

После этого можно подключаться к серверу командой

ssh AliasName

SFTP

В sshd по умолчанию встроен SFTP-сервер. Протокол SFTP (SSH File Transfer Protocol) — SSH-протокол для передачи файлов. Он предназначен для копирования и выполнения других операций с файлами поверх надёжного и безопасного соединения. Как правило, в качестве базового протокола, обеспечивающего соединение, и используется протокол SSH2. Для того чтобы включить поддержку SFTP, добавьте в sshd_config строку:

subsystem sftp /usr/libexec/openssh/sftp-server

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

Монтирование удаленной директории с помощью sshfs

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

Установка:

sudo dnf install sshfs

Монтирование:

sshfs user@server:/home/userdir ~/sshfsdir

Директория, в которую производится монтирование, должна быть предварительно создана:

mkdir ~/sshfsdir

Размонтирование:

fusermount -u ~/sshfsdir

Пример:

Запуск графических приложений через SSH (X11Forwarding)

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

В файле конфигурации /etc/ssh/sshd_config прописываем:

…
X11Forwarding yes
…

Перезапускаем ssh-сервер:

systemctl restart sshd

Настройка клиента.

В файле конфигурации /etc/ssh/ssh_config прописываем:

…
ForwardX11 yes
…

После того, как настройка закончена, заходим на удаленный хост и потом запускаем приложение, например, текстовый редактор pluma:

ssh -XC user@server
pluma

Чтобы сразу запустить приложение pluma:

ssh -XC user@server "pluma"

Опции:

X : перенаправлять графический вывод
С : компрессия передаваемых данных

Пример.

Запуск:

Результат выполнения:

Создаваемый файл будет сохранён на удалённой машине.

Копирование файлов SCP

С помощью этой консольной утилиты можно перемещать файлы между удалённой и локальной системой.

Копирование файла на удалённую машину:

scp /srcfolder/file1 user@server:/destfolder/file1

Копирование файла на локальную машину с удалённой:

scp user@server:/srcfolder/file1 /destfolder/file1

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

Доступные опции :

C : сжимать данные при их отправке на конечный компьютер.
r : рекурсивно копировать каталоги.

Пример.

Копирование на удалённую машину:

  Копирование из удалённой системы в локальную:

Подключение через MC (Midnight Commander)

Midnight Commander (MC) — это визуальный файловый менеджер. Это программа, которая позволяет вам копировать, перемещать и удалять файлы и директории, производить поиск файлов и запускать на выполнение команды оболочки.

Также Midnight Commander позволяет подключиться к ssh-серверу.

Для запуска программы в консоли вводим:

mc

После чего, клавишей F9 активируем верхнее меню. В нём выбираем панель, левую или правую, в которой будет произведено подключение к ssh-серверу. В выпадающем меню выбираем пункт «SFTP-соединение».

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

Диагностика проблем подключения

Для анализа лога подключения используется команда:

ssh -vvv user@server

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

man ssh #
man sshd #

Дата последнего изменения: 10.09.2024

Если вы нашли ошибку, пожалуйста, выделите текст и нажмите Ctrl+Enter.