Служба SSHD

Аутентификация
Вход в систему
SSH-доступ для root
SSHRC
Формат файла authorized keys
Формат файла ssh_known_hosts
Файлы
Предостережения

OpenSSH Daemon - это программа-сервер, обслуживающая запросы программы-клиента ssh. Вместе эти программы заменяют rlogin и rsh и обеспечивают защищённую и зашифрованную связь между двумя непроверенными компьютерами через незащищённую сеть.

sshd - это служба, принимающая запросы на соединения от клиентов. Обычно она запускается при загрузке системы из /etc/rc. Для каждого нового соединения создаётся (с помощью вызова fork) новый экземпляр службы. Ответвлённый экземпляр обрабатывает обмен ключами, шифрование, аутентификацию, выполнение команд и обмен данными.

Параметры определяются при помощи ключей командной строки или файла конфигурации (по умолчанию - sshd_config). Ключи командной строки имеют больший приоритет, чем значения, указанные в файле конфигурации. При получении сигнала отбоя SIGHUP перечитывает свой файл конфигурации путём запуска собственной копии с тем же самым именем, с которым был запущен, например, /usr/sbin/sshd.

Доступны следующие ключи:

Аутентификация

Служба OpenSSH SSH поддерживает версии протокола SSH 1 и 2. Запретить использование одного из протоколов можно, указав в параметре Protocol файла sshd_config. Протокол 2 поддерживает ключи RSA и DSA; протокол 1 поддерживает только ключи RSA. Независимо от протокола, каждый подключающийся хост имеет собственный (обычно 2048-битный) идентифицирующий его ключ.

Для протокола версии 1 подтверждение субъекта сервера обеспечивается 768-битным ключом, который генерируется при запуске сервера. Ключ генерируется заново каждый час, при условии его использования, и не хранится на диске. При получении запроса на подключение со стороны клиента служба посылает в ответ свой открытый ключ и свои ключи. Клиент сравнивает ключ хоста RSA со своими данными, чтобы убедиться в том, что это тот же сервер. Затем клиент генерирует 256-битное произвольное число, шифрует его при помощи обоих ключей (своего и сервера) и отправляет результат серверу. Это число становится ключом сеанса, и с его помощью выполняется кодирование всей последующих данных, по согласованному методу - Blowfish или 3DES (клиент выбирает метод из предложенных сервером). В настоящее время по умолчанию используется 3DES.

Для протокола версии 2 подтверждение субъекта сервера обеспечивается по схеме Диффи—Хеллмана, в результате которой также получается общий ключ сеанса. Дальнейший обмен данными шифруется симметричным кодом, 128-битным AES, Blowfish, 3DES, CAST128, Arcfour, 192-битным AES или 256-битным AES, который выбирает клиент из предложенных сервером. Кроме того, целостность передаваемых данных обеспечивается кодом подтверждения подлинности сообщения (hmac-sha1 или hmac-md5).

Далее сервер и клиент переходят в режим аутентификации. Клиент пытается аутентифицировать себя по своему хосту, открытому ключу, паролю или с помощью беспарольного механизма («вызов-ответ»).

Независимо от типа аутентификации, служба проверяет доступность соответствующей учётной записи в системе. Так, она может быть заблокирована посредством добавления её в параметр DenyUsers или её группы в DenyGroups. Механизм общесистемной блокировки учётной записи выполняется разными системами по-разному. Одни системы ведут собственную базу данных учётных записей (AIX), другие вносят соответствующие изменения в поля файла passwd («*LK*» - Solaris и UnixWare, «*» - на HP-UX, «Nologin» - Tru64, «*LOCKED*» во FreeBSD и «!!» в GNU/Linux). Для запрета только аутентификации по паролю укажите в файле passwd «NP» или «*NP*».

После успешной аутентификации себя клиентом связь переходит в режим подготовки сеанса. В этот момент клиент может запросить такие вещи, как выделение псевдо-терминала, перенаправление соединения Х11, перенаправление соединения TCP/IP или перенаправление соединения агента аутентификации через защищённый канал.

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

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

Вход в систему

После успешной аутентификации пользователя выполняются следующие действия:

• Если регистрация в системе произведена на терминале (tty) и не указана никакая команда, то отображается время последнего входа в систему и содержимое файла /etc/motd (если только это не отключено в файле конфигурации или ~/.hushlogin).
• Если регистрация в системе произведена на терминале, записывается время регистрации.
• Проверяется /etc/nologin, если он присутствует, выводится его содержимое и завершается работа (исключение - root).
• Осуществляется переход к выполнению с правами обычного пользователя.
• Устанавливаются значения основных переменных среды.
• Интерпретируется файл ~/.ssh/environment, если таковой имеется, и пользователям разрешено изменять среду.
• Переходит в домашний каталог пользователя.
• Если имеется файл ~/.ssh/rc, то производится его выполнение, а если нет, но имеется /etc/ssh/sshrc, то выполняется он, в противном случае не выполняется ничего.  Файлам «rc» на стандартный ввод передаётся протокол аутентификации Х11 и cookie.
• Запускается оболочка пользователя или выполняется указанная команда.

SSH-доступ для root

В начале установки операционной системы РЕД ОС предоставляется возможность разрешить вход пользователем root с паролем через ssh.

Но даже если не указывать данное разрешение при установке, его можно настроить после завершения установки системы.

Для этого на рабочем столе необходимо открыть меню и перейти в файловую систему (/). Затем требуется найти папку /etc и перейти в неё.

В папке /etc необходимо открыть папку /ssh от имени администратора.

Затем нужно найти файл sshd_config и отредактировать в нем строку PermitRootLogin prohibit-password на PermitRootLogin yes.

После редактирования необходимо сохранить внесенные изменения.

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

systemctl restart sshd

Теперь можно подключаться по SSH от имени суперпользователя root.

SSHRC

Если файл ~/.ssh/rc существует, он будет выполняться после файлов определения переменных среды, но перед запуском оболочки пользователя или команды. Если используется подмена Х11, то на его стандартный ввод будет передана пара «proto cookie», также ему будет доступна переменная среды DISPLAY. Сценарий должен вызывать xauth(1) самостоятельно для добавления cookie X11.

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

Этот файл будет, вероятно, содержать блок аналогичный следующему:

if read proto cookie && [ -n "$DISPLAY" ]; then
if [ 'echo $DISPLAY | cut -c1-10' = 'localhost:' ]; then
 X11UseLocalhost=yes
echo add unix:'echo $DISPLAY
| cut -c11-' $proto $cookie
else
 X11UseLocalhost=no
echo add $DISPLAY $proto $cookie
fi | xauth -q -
fi

Если этот файл отсутствует, то выполняется /etc/ssh/sshrc, а если отсутствует и он, то для добавления cookie используется xauth.

Формат файла authorized keys

Параметр файла конфигурации AuthorizedKeysFile определяет путь к файлу с открытыми ключами. Значение по умолчанию —/.ssh/authorized_keys. Каждая строка файла содержит один ключ (пустые строки или строки, начинающиеся с символа «#», считаются комментариями и игнорируются). Открытые ключи протокола 1 (RSA) состоят из следующих полей, разделённых пробелами: параметры, битность, порядок, модуль, комментарий. Открытые ключи протокола версии 2 состоят из: параметра, типа ключа, ключа в виде base64, комментария. Поля параметров необязательны; их отсутствие определяется наличием в начале строки цифры (поле параметра никогда не начинается с цифры). Поля битности, порядка, модуля и комментарии определяют ключ RSA; поле комментария не используется (но может быть удобно пользователю для отметки ключа). Для протокола версии 2 типом ключа является ssh-dss или ssh-rsa.

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

Пример файла authorized_keys:

# допустимы комментарии только на всю строку
ssh-rsa AAAAB3Nza...LiPk== user@example.net
from="*.sales.example.net,!pc.sales.example.net" ssh-rsa
AAAAB2...19Q== john@example.net
command="dump /home",no-pty,no-port-forwarding ssh-dss
AAAAC3...51R== example.net
permitopen="192.0.2.1:80",permitopen="192.0.2.2:25" ssh-dss
AAAAB5...21S==
tunnel="0",command="sh /etc/netstart tun0" ssh-rsa AAAA...==
jane@example.net

Формат файла ssh_known_hosts

В файлах /etc/ssh/ssh_known_hosts и ~/.ssh/known_hosts хранятся открытые ключи всех машин, с которыми когда-либо устанавливалась связь. 

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

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

Имена хостов - это разделённый запятыми список шаблонов (символы подстановки - «*» и «?»); каждый шаблон сопоставляется с каноническим именем машины (при аутентификации клиента) или с именем, которое указано пользователем (при аутентификации сервера). Этот шаблон может также быть предварён знаком «!» для обозначения отрицания: если имя машины соответствует отрицаемому шаблону, оно будет отвергнуто (этой строкой) даже если оно соответствует другому шаблону в этой же строке. Также можно, заключив имя хоста или IP-адрес в квадратные скобки «[» и «]», через «:» указать нестандартный порт.

Вместо имён хостов можно записывать их хэши. Это позволит скрыть их от злоумышленника в случае попадания файла в его руки. Для различия хэшей от имён хостов первые предваряются символом «|». На одной строке может быть не больше одного хэша, операция отрицания в этом случае не доступна.

Разрядность, порядок и модуль копируются из ключа хоста RSA, например, /etc/ssh/ssh_host_key.pub. Необязательное поле комментария занимает всю оставшуюся часть строки и игнорируется.

Комментариями также считаются пустые и строки начинающиеся с «#».

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

Пример файла ssh_known_hosts:

# допустимы явные комментарии только на всю строку
closenet       192.0.2.53 1024 37 159...93 closenet.example.net
cvs.example.net,192.0.2.10 ssh-rsa AAAA1234 =
# хэш имени хоста
|1|JfKTdBh7rNbXkVAQCRp4OQoPfmI=|USECr3SWf1JUPsms5AqfD5QfxkM= ssh-rsa
AAAA1234 =

Файлы

Предостережения

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

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