что такое демон ssh

Что такое демон ssh

Протокол SSH веосии 1

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

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

Rhosts аутентификация обычно отключена, так как она абсолютно небезопасна, но может быть задействована, при желании, в файле конфигурации сервера. Защита системы не совершенна, если не задействованы rshd(8), rlogind(8), rexecd(8) и rexd(8) (это полностью отключает на машине rlogin(1) и rsh(1)).

Протокол SSH версии 2

Версия 2 работает похоже: Каждый компьютер имеет машино-зависимый DSA-ключ используемый для идентификации машины. Однако, при старте демона он не генерирует ключ сервера. Первичная защита обеспечивается посредством соглашения ключа Diffie-Hellman. Это соглашение ключа заключается в разделяемом ключе сеанса.

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

Выполнение команд и перенаправление данных

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

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

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

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

При получении сигнала отбоя SIGHUP, sshd перечитывает свой файл конфигурации путём запуска собственной копии с тем же самым именем с которым был запущен, например, /usr/sbin/sshd.

ПАРАМЕТРЫ

ФАЙЛ КОНФИГУРАЦИИ

Допустимы следующие ключевые слова. AFSTokenPassing Определяет, может ли AFS быть переадресован серверу. По умолчанию стоит «yes». AllowGroups Это ключевое слово может следовать за списком группы имен разделенных пробелами. Если указано, регистрация в системе разрешается только пользователям, чья главная или вспомогательная группы соответствуют какому-либо из шаблонов. «*» и «?» могут быть использованы как символы подстановки в шаблонах. Допустимы только имена групп; числовой идентификатор группы не распознается. По умолчанию разрешена регистрация в системе независимо от списка группы.

AllowTcpForwarding Определяет, будет ли разрешено перенаправление TCP. По умолчанию «yes». Имейте ввиду, что отключение пересылки TCP не увеличит безопасность пока пользователям не запрещен доступ к командной оболочке, так как они всегда могут установить свои собственные перенаправления.

AllowUsers После этого ключевого слова может следовать разделённый пробелами список имен пользователей. Если определено, регистрация в системе разрешена только пользователям, чьи имена соответствуют одному из шаблонов. «*» и «?» могут быть использованы как символы подстановки в шаблонах. Допустимы только имена пользователей; числовой идентификатор пользователя не распознается. По умолчанию разрешена регистрация в системе независимо от имени пользователя.

Banner В некоторых местах послание предупредительного сообщения перед аутентификацией может быть уместно в целях достижения легитимности защиты. Содержимое указанного файла будет отправлено удаленному пользователю прежде, чем будет разрешена аутентификация. Этот параметр доступен только с протоколом версии 2. ChallengeResponseAuthentication Определяет, разрешается ли обратная проверка подлинности вызова. В настоящее время есть поддержка только для skey(1) аутентификации. Значение по умолчанию «yes». Ciphers Определяет допустимые, для протокола версии 2, шифры. Множество шифров должно быть разделено через запятую. По умолчанию это «blowfish-cbc,aes128-cbc,3des-cbc,cast128-cbc,arcfour». CheckMail Определяет, должен ли sshd проверять наличие новой почты при интерактивной регистрации в системе. По умолчанию это установлено в «yes». ClientAliveInterval Устанавливает время ожидания в секундах после которого, если не поступает информация со стороны клиента, sshd отправит через защищённый канал запрос отклика клиенту. По умолчанию используется 0, что означает, что клиенту не будет направлен такой запрос. Этот параметр применим только с протоколом версии 2. ClientAliveCountMax Устанавливает количество запросов клиенту (см.выше), которое может быть отправленно без получения sshd на них отклика. Если предел достигнут, sshd разъединится с клиентом и завершит сеанс. Имейте в виду, использование запросов client alive очень сильно отличается от Keepalive (см.далее). Данные запросы отправляются через защищённый канал и поэтому не могут быть подменены. Параметр TCP keepalive включаемый при помощи Keepalive может быть подменён. Вы захотите использовать механизм client alive, если на машинах-клиентах подключаемых к серверу имеется что-то важное.

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

ListenAddress host | IPv4_addr | IPv6_addr

ListenAddress host | IPv4_addr : port

ListenAddress [ host | IPv6_addr ]: port

Если этот параметр установлен в значение «without-password», то аутентификация паролем для суперпользователя будет выключена.

ПРОЦЕСС ВХОДА В СИСТЕМУ

ФОРМАТ ФАЙЛА AUTHORIZED_KEYS

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

Примеры

command=»dump /home»,no-pty,no-port-forwarding 1024 33 23. 2323 backup.hut.fi

permitopen=»10.2.1.55:80″,permitopen=»10.2.1.56:25″ 1024 33 23. 2323

ФОРМАТ ФАЙЛА SSH_KNOWN_HOSTS

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

Имена машин, это разделенный запятыми список шаблонов (‘*’ и ‘?’ используются как знаки подстановки); каждый шаблон согласуется с соответствующим каноническим именем машины (когда аутентифицирует клиент) или согласуется с именем допустимого пользователя (когда аутентифицирует сервер). Этот шаблон может также быть предварен знаком `!’ для обозначения отрицания: если имя машины соответствует отрицаемому шаблону, оно будет отвергнуто (этой строкой) даже если оно соответствует другому шаблону в этой же строке.

Строки, начинающиеся с `#’ и пустые строки, игнорируются как комментарии.

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

Обратите внимание, что строки в этих файлах обычно имеют длину в несколько сотен знаков и вы определенно не захотите заносить эту информацию в ключи машин от руки. Скорее, вы сделаете это при помощи сценария оболочки или взяв /etc/openssh/ssh_host_key.pub и добавив впереди имя машины.

Примеры

closenet. 130.233.208.41 1024 37 159. 93 closenet.hut.fi
cvs.openbsd.org,199.185.137.3 ssh-rsa AAAA1234. =

ФАЙЛЫ

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

Этот файл будет вероятно содержать некоторый код инициализации похожий на что нибудь типа:

АВТОРЫ

Aaron Campbell, Bob Beck, Markus Friedl, Niels Provos, Theo de Raadt и Dug Song удалили много ошибок, добавили обновленные возможности и создали OpenSSH.

Markus Friedl внес вклад в виде поддержки для протокола SSH версий 1.5 и 2.0.

Источник

HackWare.ru

Этичный хакинг и тестирование на проникновение, информационная безопасность

SSH (ч.1): Что такое SSH. Утилиты SSH

Оглавление

Что такое и для чего нужен SSH

SSH — это набор программ, которые позволяют выполнить вход на удалённую машину для выполнения команд на ней. Он предназначен для обеспечения защищённой зашифрованной связи между двумя узлами через незащищённую сеть. Соединения X11, произвольные порты TCP и сокеты домена UNIX также могут быть переадресованы по защищённому каналу. В SSH входят программы, которые дополнительно позволяют передавать файлы по зашифрованному соединению.

SSH несёт в себе различные улучшения безопасности, среди них аутентификация пользователя/хоста, шифрование данных и целостность данных, благодаря чему невозможны популярные атаки вроде подслушивания (сниффинга), DNS/IP спуфинга, подделка данных (data forgery), перехват соединения (connection hijacking) и т. д. Пользователям ftp, telnet или rlogin, которые используют протокол, передающий данные в виде открытого текста, крайне рекомендуется переключиться на SSH.

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

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

Утилиты SSH

К серверным утилитам OpenSSH относятся:

Итак, на сервере основного внимания требует sshd, а программа sftp-server будет запущена автоматически по мере необходимости.

К клиентским утилитам OpenSSH относятся:

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

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

Как установить OpenSSH

Для некоторых конфигураций служба OpenSSH установлена и включена по умолчанию. Как правило, это относится к системам, к которым затруднительно получить доступ иным способом, кроме как по SSH. Например, на хостингах VPS (виртуальных частных серверов) устанавливаемые системы практически всегда даже в минимальной конфигурации уже имеют установленную и запущенную службу SSH, поэтому после развёртывания нового сервера, клиенту достаточно подключиться используя присланные учётные данные.

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

В Debain и производных (Kali Linux, Linux Mint, Ubuntu), программы OpenSSH можно установить по отдельности, например, имеются пакеты для клиента и для сервера openssh-client и openssh-server. Либо можно установить метапакет ssh, который содержит и клиентскую, и серверную часть.

В Arch Linux клиент и сервер OpenSSH собраны в один пакет. Для установки OpenSSH в Arch Linux выполните:

В других дистрибутивах Linux поищите пакет openssh или ssh.

Управление службой OpenSSH

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

Запуск службы OpenSSH требуется только на сервере.

OpenSSH поставляется с файлами служб systemd (смотрите также «Как использовать Systemctl для управления службами Systemd и юнитами») двух видов:

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

Они добавят демона SSH в автозагрузку и запустят его прямо сейчас.

Для второй модели (запуск SSH только по требованию), сделайте так:

sudo systemctl start sshd.socket

sudo systemctl enable sshd.socket

Для проверки статуса службы:

Либо если вы используете сокет:

systemctl status sshd.socket

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

Как проверить журнал событий SSH службы

События SSH можно разделить на события:

Просмотреть логи SSH можно различными способами, один из вариантов (помните, что в некоторых системах служба называется ssh.service, без буквы d):

Например, для вывода последних 100 записей:

Также можно просмотреть события SSH с помощью:

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

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

Как увидеть неудачные попытки входа SSH

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

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

При неудачной попытке входа из-за неверного ключа, при уровне вербальности (LogLevel) по умолчанию (INFO) специальные сообщения не записываются в журнал. Подобные неудачные попытки можно обнаружить по записи «Connection closed by authenticating user», но она означает отключение на этапе аутентификации, независимо от способа аутентификации — по паролю или по ключу.

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

Подробнее об этой настройке во второй часте.

Как просмотреть журнал подключений пользователей SSH

Чтобы показать подключения, когда вход был сделан по паролю:

Чтобы показать подключения аутентификации по публичному ключу:

Другой вариант просмотреть историю входов, это использовать следующую команду:

Источник

7.5 Служба sshd — OpenSSH, сервер протокола SSH, описание

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 и других соединений сервер посылает клиенту команду со статусом выхода и сеанс завершается.

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

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

SSHRC

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

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

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

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

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

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

Минимальная длина модуля RSA независимо от протокола составляет 768 бит.

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

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

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

В файлах /etc/ssh/ssh_known_hosts и

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

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

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

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

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

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

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

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

Файлы

/.ssh/authorized_keysСодержит список открытых ключей (RSA/DSA), которые могут быть использованы для регистрации данного пользователя. Формат файла описан выше. Этот файл не очень важен для злоумышленника, но мы рекомендуем сделать его доступным только пользователю (чтение/запись).

Если этот файл, каталог

/.ssh или домашний каталог пользователя доступны для записи другим пользователям, этот файл может быть изменён или заменён любым пользователем системы, имеющим сколько угодно мало прав. В этом случае sshd не будет использовать этот файл, если только параметр StrictModes не имеет значение «no». Установить рекомендуемый набор прав доступа можно командой chmod go-w

/.ssh/authorized_keys.

/.ssh/environmentЭтот файл (при его наличии) считывается в среду при регистрации в системе. Он может содержать только пустые строки, строки комментария (начинающиеся с «#») и определения значений переменных в виде: переменная=значение. Правом на запись этого файла должен обладать только пользователь; он не должен быть доступен остальным. Задание переменных среды отключено по умолчанию, за что отвечает параметр PermitUserEnvironment.

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

/.ssh/rcСценарий инициализации, запускаемый перед запуском оболочки пользователя или команды. Этот файл должен быть доступен для записи только пользователю и не должен быть вообще доступен другим./etc/hosts.allow
/etc/hosts.denyДанные о разрешении и запрете соединений с хостами для надстроек TCP. См. hosts_access(5)./etc/hosts.equivИспользуется для аутентификации на основе хоста (см. ssh(1)). Должен быть доступен для записи только root./etc/moduliГруппы для схемы Диффи—Хеллмана. Формат файла описан в moduli(5)./etc/motdСм. motd(5)./etc/nologinЕсли существует, подключение будет разрешено только суперпользователю. Любому, кто пытается войти в систему, будет показано содержимое этого файла и запросы на регистрацию в качестве не суперпользователя будут отвергнуты. Этот файл должен быть доступен для чтения всем./etc/shosts.equivАналогичен hosts.equiv, но позволяет проводить аутентификацию на основе хоста, не разрешая вход в систему с помощью rlogin/rsh./etc/ssh/ssh_known_hostsОбщесистемный список известных хостов и их ключей. Этот файл должен составляться администратором. В него следует включать открытые ключи всех компьютеров организации. Формат файла описан выше. Файл должен быть доступен всем для чтения и владельцу/администратору для записи./etc/ssh/ssh_host_key
/etc/ssh/ssh_host_dsa_key
/etc/ssh/ssh_host_rsa_keyСодержат частные ключи хостов. Файлы должны принадлежать root и быть доступными только для него. Не запустится, если эти файлы доступны для чтения кому-либо кроме суперпользователя./etc/ssh/ssh_host_key.pub
/etc/ssh/ssh_host_dsa_key.pub
/etc/ssh/ssh_host_rsa_key.pubСодержат открытые ключи хостов. Должны быть доступны всем для чтения и только суперпользователю для записи. Содержимое файлов должно соответствовать содержимому соответствующих файлов с частными ключами. Эти файлы не используются программой и предназначены для копирования пользователем в файлы known_hosts. Эти файлы создаются командой ssh-keygen(1)./etc/ssh/sshd_configКонфигурация службы sshd. Формат файла и параметры конфигурации описаны в sshd_config(5)./etc/ssh/sshrcАналогичен

/.ssh/rc, позволяет задавать инициализационный сценарий глобально для всех пользователей. Должен быть доступен всем для чтения и только root для записи./var/emptyКаталог chroot(2), используемый при отделении полномочий на предаутентификационном этапе. В папке не должно быть никаких файлов, она должна принадлежать только root и не должна быть доступна другим для записи./var/run/sshd.pidИдентификатор процесса, ожидающего запросов на подключение (если одновременно работает несколько экземпляров служб для нескольких портов, в него записывается идентификатор экземпляра запущенного последним). Содержимое этого файла может не быть защищено и может быть доступно всем.

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

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

Источник