База знаний
Войти

Доступ по OpenSSH

Общие сведения об OpenSSH

OpenSSH представляет собой набор программных средств для защищенного удаленного доступа к компьютерам по протоколу SSH.

Для установки SSH-сервера необходимо выполнить команду:

sudo dnf install openssh-server

Далее следует добавить SSH-сервер в автозагрузку. При следующем запуске сервера ОС выполнит автоматический запуск SSH-сервера. Как и в случае с другими службами, systemd позволяет управлять параметрами запуска, автозагрузки и перезапуска службы OpenSSH. Автозапуск включается командой:

sudo systemctl enable --now sshd

Работоспособность утилиты проверяется командой:

ssh localhost

Настройка SSH

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

Настройка выполняется в конфигурационном файле. Перед его модификацией создают резервную копию.

sudo cp /etc/ssh/sshd_config /etc/ssh/sshd_config.factory-defaults

Все изменения конфигурации SSH вносятся в файл /etc/ssh/sshd_config. Для его редактирования нужно выполнить команду:

sudo nano /etc/ssh/sshd_config

В файле необходимо раскомментировать строку Port и указать выбранный номер порта, например 55555 (рисунок 157).

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

Рисунок 157 – Изменение стандартного порта подключения

Далее необходимо запретить вход на сервер от имени суперпользователя root и разрешить аутентификацию по ключу. Для этого следует установить для параметра PermitRootLogin значение "no", а для параметра PubkeyAuthentication – значение "yes" (рисунок 158).

Рисунок 158 – Изменение параметров <!-- Serif_start -->PermitRootLogin<!-- Serif_end --> и <!-- Serif_start -->PubkeyAuthentication<!-- Serif_end -->

Перед применением конфигурации следует проверить ее синтаксис:

sudo sshd -t

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

sudo systemctl reload sshd

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

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

ssh -p 55555 ansible@192.168.0.104

После успешного подключения можно продолжать работу с сервером.

Аутентификация по ключу

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

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

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

Рисунок 159 – Принцип применения пары открытого и закрытого ключей RSA

OpenSSH поддерживает различные алгоритмы формирования ключей. Для создания новых ключей рекомендуется использовать Ed25519. Ключи RSA допускается применять при наличии требований совместимости или ограничений, установленных политикой безопасности.

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

ssh-keygen -t ed25519

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

  • ~/.ssh/id_ed25519 – закрытый ключ;
  • ~/.ssh/id_ed25519.pub – открытый ключ.

Если использование Ed25519 невозможно из-за требований совместимости или действующей политики безопасности, допускается создание ключа RSA длиной не менее 3072 бит:

ssh-keygen -t rsa -b 3072

Важно – Не допускается передавать закрытый ключ другим пользователям или копировать его на удаленный сервер.

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

ssh-copy-id -i ~/.ssh/id_ed25519.pub -p 55555 rosa@192.168.0.104

где:

  • ~/.ssh/id_ed25519.pub – файл открытого ключа;
  • 55555 – порт, используемый службой SSH;
  • rosa – имя учетной записи на удаленном сервере;
  • 192.168.0.104 – IP-адрес удаленного сервера.

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

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

ssh -p 55555 -o PreferredAuthentications=publickey -o PasswordAuthentication=no -o KbdInteractiveAuthentication=no rosa@192.168.0.104

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

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

Для отключения парольной аутентификации необходимо в файле /etc/ssh/sshd_config установить для параметра PasswordAuthentication значение no (рисунок 160).

Рисунок 160 – Редактирование параметра <!-- Serif_start -->PasswordAuthentication<!-- Serif_end -->

После изменения настроек необходимо перезапустить службу SSH:

sudo systemctl restart sshd

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

При этом подключение при помощи ключа будет успешным.

Отключение доступа по паролю значительно повышает безопасность сервера.

Сохранение пользовательских процессов после завершения сеанса

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

Для сохранения таких процессов после завершения сеанса используется пользовательский экземпляр systemd. Для соответствующего пользователя предварительно включается режим lingering, позволяющий сохранять работу пользовательского экземпляра systemd --user после завершения последнего пользовательского сеанса.

Для включения режима lingering необходимо выполнить команду:

sudo loginctl enable-linger username

где username – имя пользователя.

После включения режима lingering необходимый процесс запускается с использованием пользовательского экземпляра systemd. Например, для запуска screen необходимо выполнить команду:

systemd-run --scope --user screen

Параметр --user указывает на использование пользовательского экземпляра systemd, параметр --scope – на создание отдельного scope-юнита для запускаемого процесса.

Таким образом, для сохранения процесса, например screen, после завершения SSH-сеанса необходимо выполнить следующие команды:

sudo loginctl enable-linger username
systemd-run --scope --user screen

где username – имя пользователя, процессы которого необходимо сохранить.

Практический пример сохранения процесса

Далее приведен практический пример сохранения процесса после завершения SSH-сеанса.

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

В примере используется пользователь с именем test1, учетная запись которого должна быть предварительно создана командами (рисунок 161):

sudo useradd test1
sudo passwd test1

Рисунок 161 – Создание пользователя <!-- Serif_start -->test1<!-- Serif_end -->

Для сохранения процесса необходимо выполнить следующие действия:

  1. включить режим lingering для пользователя test1:
sudo loginctl enable-linger test1
  1. подключиться к серверу по SSH под учетной записью пользователя test1 (рисунок 162):
ssh test1@192.168.1.131

где:

  • test1 – имя пользователя;
  • 192.168.1.131 – IP-адрес машины, к которой выполняется подключение.

Рисунок 162 – Успешное подключение пользователя <!-- Serif_start -->test1<!-- Serif_end -->

  1. запустить сеанс screen с использованием пользовательского экземпляра systemd:
systemd-run --scope --user screen

После выполнения команды открывается консоль screen;

  1. в открывшейся консоли запустить тестовый процесс бесконечного ожидания:
sleep infinity

Рисунок 163 – Запуск процесса бесконечного ожидания

  1. отсоединиться от сеанса screen, последовательно нажав сочетание клавиш Ctrl+A, затем клавишу D;
  2. завершить SSH-сеанс одним из следующих способов:
  • выполнить команду:
exit
  • использовать сочетание клавиш Ctrl+D;
  • закрыть окно терминала.
  1. повторно подключиться к серверу по SSH:
ssh test1@192.168.1.131

где:

  • test1 – имя пользователя;
  • 192.168.1.131 – IP-адрес машины, к которой выполняется подключение.
  1. подключиться к ранее запущенному сеансу screen:
screen -r

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

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

loginctl show-user test1 -p Linger

При включенном режиме в выводе команды отображается:

Linger=yes

При необходимости режим lingering отключается командой:

sudo loginctl disable-linger test1

Изменение политики завершения пользовательских процессов

В качестве альтернативного способа сохранения пользовательских процессов после завершения сеанса в Системе может использоваться пакет systemd-settings-disable-kill-user-processes.

Установка пакета изменяет всю политику завершения пользовательских процессов в Системе и позволяет сохранять их выполнение после завершения пользовательского сеанса без необходимости запуска каждого процесса командой systemd-run.

Важно – Установка пакета выполняется с правами суперпользователя и влияет на политику завершения пользовательских процессов в Системе в целом.

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

dnf search systemd-settings-disable-kill-user-processes

Для установки пакета необходимо выполнить команду:

sudo dnf install systemd-settings-disable-kill-user-processes

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

sudo systemctl reboot

Настройки также могут быть применены без перезагрузки Системы путем перезапуска службы systemd-logind:

sudo systemctl restart systemd-logind

Важно – Перезапуск службы systemd-logind приводит к завершению активных пользовательских сеансов.

Для проверки сохранения процессов после установки пакета необходимо выполнить следующие действия:

  1. подключиться к серверу по SSH под учетной записью пользователя test1:
ssh test1@192.168.1.131

Рисунок 164 – Успешное подключение пользователя <!-- Serif_start -->test1<!-- Serif_end -->

  1. запустить screen:
screen
  1. в открывшейся консоли запустить тестовый процесс бесконечного ожидания (рисунок 165):
sleep infinity

Рисунок 165 – Запуск процесса бесконечного ожидания

  1. отсоединиться от сеанса screen, последовательно нажав сочетание клавиш Ctrl+A, затем клавишу D;
  2. завершить SSH-сеанс;
  3. повторно подключиться к серверу по SSH:
ssh test1@192.168.1.131

где:

  • test1 – имя пользователя;
  • 192.168.1.131 – IP-адрес машины, к которой выполняется подключение.
  1. подключиться к ранее запущенному сеансу screen:
screen -r

В результате открывается ранее созданный сеанс screen, в котором продолжает выполняться процесс sleep. Это подтверждает сохранение пользовательских процессов после завершения SSH-сеанса при установленном пакете systemd-settings-disable-kill-user-processes.

Для удаления пакета необходимо выполнить команду:

sudo dnf remove systemd-settings-disable-kill-user-processes