What is ssh daemon linux

Настройка удаленного выполнения

Часто очень полезно выполнить команду на удаленном компьютере. Причем ввод и вывод команды осуществляются по сети.

Традиционные команды, используемые для выполнения задач на удаленных компьютерах rlogin, rsh и rcp. Пример команды rlogin приведен в главе 1. Я кратко показал проблемы защиты, связанные с этим, в разделе о защите системы в главе 1 и предложил в качестве замены пакет ssh. Он обеспечивает команды slogin, ssh и scp.

Каждая из этих команд порождает оболочку на удаленном компьютере и позволяет пользователю выполнять команды. Конечно, пользователь должен быть зарегистрирован на том удаленном компьютере, где должна быть выполнена команда. Таким образом, все эти команды используют процесс авторизации. Старые r-команды просто обменивались с удаленным компьютером именем пользователя и его паролем в открытом виде. Поэтому любая программа сетевого наблюдения легко перехватывала пароли. Пакет ssh обеспечивает более высокий уровень защиты: он использует методику Public Key Cryptography для авторизации и шифрования обменов между компьютерами, чтобы гарантировать, что ни пароли, ни другие данные сеанса не перехвачены. В принципе, их как и раньше можно перехватить, но они будут зашифрованы стойким криптоалгоритмом, так что никакой пользы перехватившему от них не будет.

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

Для повышения безопасности нужно выключить r-команды и настроить ssh на работу вместо них.

Выключение r-команд

Установка и конфигурирование ssh

OpenSSH свободная версия набора программ ssh. Linux-версия есть на http://violet.ibs.com.au/openssh и во многих дистрибутивах Linux. Здесь я не буду рассматривать компиляцию: подробные указания есть в пакете с исходными текстами. Если Вы можете установить программу из откомпилированных модулей, лучше всего это сделать.

Для работы ssh нужно два компонента: клиент ssh, которого Вы должны конфигурировать и выполнить на локальном компьютере, и ssh daemon, который должен работать на удаленном компьютер, к которому нужно подключиться.

Ssh daemon

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

В конце сказано, что два файла были созданы. Первый называется секретным ключом, и должен быть сохранен в тайне. Он попал в файл /etc/ssh/ssh_host_key . Второй называется публичным ключом и должен распространяться. Он хранится в файле /etc/ssh/ssh_host_key.pub .

Теперь нужно создать файл конфигурации. Пакет ssh очень мощный, и файл конфигурации может содержать много параметров. Следующий код показывает безопасный и минимальный файл конфигурации для sshd. Остальные опции детально описаны на man-странице sshd(8):

Клиент ssh

Имеется ряд клиентов ssh: slogin, scp и ssh. Они используют один файл конфигурации, обычно /etc/ssh/ssh_config , и файлы настроек из каталога .ssh в домашнем каталоге пользователя, который их вызвал. Наиболее важные из этих файлов: .ssh/config , который может содержать параметры, отменяющие заданные в /etc/ssh/ssh_config , .ssh/identity , который содержит собственный секретный ключ пользователя и .ssh/identity.pub , содержащий публичный ключ пользователя. Другие важные файлы: .ssh/known_hosts и .ssh/authorized_keys ; они будут рассмотрены ниже. Сначала надо создать глобальный файл настроек и файл ключа пользователя.

Файл /etc/ssh/ssh_config очень похож на файл настройки сервера. Есть большое количество свойств, которые Вы можете конфигурировать, но минимальная конфигурация приведена в примере 12-5. Остальная часть параметров рассмотрена на man-странице sshd(8). Вы можете добавлять секции для конкретных компьютеров или их групп. Параметром команды Host может быть любое полное имя компьютера или набор символов подстановки. В данном примере задано соответствие всем хостам. Можно, например, создать запись Host *.vbrew.com , соответствующую всем хостам в домене vbrew.com .

Пример 12-5. Клиентский файл настроек ssh

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

/.ssh/indentity . Чтобы генерировать ключ, используйте команду ssh-keygen, но Вы не должны определять имя файла, в котором сохраняете ключ. По умолчанию ssh-keygen использует правильное расположение, но попросит Вас ввести имя файла в случае, если Вы хотите сохранить ключ в другом месте. Иногда полезно иметь много авторизационных файлов. Как и прежде ssh-keygen запросит у Вас пароль, что добавляет другой уровень защиты, и его стоит использовать. Пароль не будет отображен на экране, когда Вы его напечатаете.

Пароль нельзя восстановить, если он забыт. Требования к паролю такие же, как и ко всем прочим паролям. Он должен быть длиной от 10 до 30 символов. Если пароль забыт, придется сгенерировать новый ключ.

/.ssh/ с соответствующими правами доступа, а также их секретный и публичный ключи в .ssh/identity и .ssh/identity.pub , соответственно. Типовой сеанс:

Теперь ssh готов к работе.

Использование ssh

Теперь пакет ssh и связанные с ним команды установлены и готовы к выполнению.

Сначала опробуем удаленный вход в систему. Можно использовать программу slogin точно так же, как использовалась программа rlogin в примере в первой главе. Первый раз, когда Вы делаете попытку подключения к компьютеру, ssh получит публичный ключ хоста и запросит подтверждение с помощью электронной подписи fingerprint.

Администратор удаленного компьютера должен предоставить электронную подпись, которую Вы должны добавить к Вашему файлу .ssh/known_hosts . Если он этого не сделал, Вы можете соединиться с удаленным компьютером, но ssh предупредит Вас о возникшей ситуации. Допустим, что Вы уверены в том, что работаете с тем компьютером, с которым хотели связаться (никто не перехватил DNS). Тогда ответьте на запрос положительно. Соответствующий ключ будет автоматически сохранен в Вашем файле .ssh/known_hosts без повторных запросов. Если при следующей попытке подключения, публичный ключ с этого компьютера не соответствует тому, который сохранен, Вы будете предупреждены, потому что это представляет потенциальную опасность.

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

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

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

Здесь выполняемая команда взята в кавычки, чтобы она вся была воспринята как параметр ssh, а не обрабатывалась локальной оболочкой. Эта команда выполняет tar на удаленном компьютере, чтобы архивировать каталог /etc , и пишет результат на стандартный вывод. Мы имеем перенаправление на команду tar на локальном компьютере в режиме извлечения, причем чтение архива идет из стандартного ввода.

Публичный ключ представляет собой длинную одиночную строку текста. Если Вы используете копирование и вставку, чтобы копировать ключ в локальный файл, убедитесь, что удалили символы конца строки. Файл .ssh/authorized_keys может содержать много таких ключей по одному на строке.

Набор инструментальных средств ssh очень мощен и имеет многие другие полезные свойства и параметры. Для дальнейшего его изучения обратитесь к man-страницам и другой документации, которая поставляется вместе с пакетом.

Источник

What is ssh daemon linux

sshd это демон, который ожидает соединения от клиентов. Обычно он запускается при загрузке системы из /etc/rc . Он создает нового демона для каждого нового соединения. Ответвленный демон обрабатывает обмен ключами, шифрование, аутентификацию, выполнение команд и обмен данными. Эта реализация sshd поддерживает обе версии протокола SSH, 1 и 2, одновременно. sshd работает следующим образом.

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

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

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

Затем, сервер и клиент переходят в диалог аутентификации. Клиент пытается идентифицировать себя, с использованием .rhosts аутентификации, .rhosts аутентификации комбинированной с RSA аутентификацией машины, RSA аутентификацией запроса-ответа, или аутентификацией с паролем.

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).

Протокол версии 2 обеспечивает метод аутентификации пользователя, основанный на методе публичного ключа (PubkeyAuthentication) или методе аутентификации машины-клиента (HostbasedAuthentication), обычной аутентификации паролем и по принципу запрос — ответ.

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

Если клиент аутентифицировал себя удачно, то будет выведен диалог для подготовки сеанса. В этот момент клиент может запросить такие вещи как назначение псевдо-терминала, перенаправление соединения Х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, если на машинах-клиентах подключаемых к серверу имеется что-то важное.

Значение по умолчанию — 3. Если вы установите значение интервала ClientAliveInterval (см.выше) равным 15 и оставите этот параметр без изменений, то не отвечающие ssh-клиенты будут отключены примерно через 45 секунд. DenyGroups Это ключевое слово может следовать после списка имен групп разделенных пробелами. Если указано, регистрация в системе пользователям, чья главная или вспомогательная группа соответствуют содержащимся в списке шаблонам, не разрешается. «*» и «?» могут быть использованы как символы подстановки в шаблонах. Допустимы только имена групп; числовой идентификатор группы не распознается. По умолчанию разрешена регистрация в системе независимо от списка группы.

DenyUsers Это ключевое слово может следовать после списка имен пользователей, разделенных пробелами. Если указано, регистрация в системе пользователям, чьи имена пользователей соответствуют содержащимся в списке шаблонам, не разрешается. «*» и «?» могут быть использованы как символы подстановки в шаблонах. Допустимы только имена пользователей; числовой идентификатор пользователя не распознается. По умолчанию разрешена регистрация в системе независимо от имени пользователя. GatewayPorts Определяет, позволено ли удаленным машинам подключение к портам, перенаправленным для клиента. Параметр должен быть «yes» или «no». По умолчанию «no». HostbasedAuthentication Указывает, разрешен ли rhosts или аутентификация /etc/hosts.equiv в сочетании с успешной аутентификацией посредством аутентификации с открытым ключём машины-клиента (по-машинная аутентификация). Этот параметр схож с RhostsRSAAuthentication и применим только к протоколу версии 2. По умолчанию «no». HostKey Указывает файл содержащий приватные ключи машины (по умолчанию /etc/openssh/ssh_host_key ) используемые для протоколов SSH версии 1 и 2. Имейте ввиду, что sshd будет отвергать использование этого файла, если он доступен группе/всем для чтения. Это позволяет иметь несколько файлов с ключами машины. Ключи «rsa1» используются для версии 1, и «dsa» или «rsa» для версии 2 протокола SSH. IgnoreRhosts Указывает, что файлы .rhosts и .shosts не должны использоваться при RhostsAuthentication , RhostsRSAAuthentication или HostbasedAuthentication .

/etc/hosts.equiv и /etc/openssh/shosts.equiv при этом по прежнему используются. Значение по умолчанию «yes». IgnoreUserKnownHosts Указывает, будет ли sshd игнорировать пользовательский $HOME/.ssh/known_hosts в процессе RhostsRSAAuthentication или HostbasedAuthentication . По умолчанию «no». KeepAlive Указывает, будет ли система посылать другой стороне контрольные сообщения для удержания соединения активным. Если они посылаются, то разрыв соединения или аварийный отказ одной из машин будет должным образом замечен. Однако, при этом временная потеря маршрута повлечет за собой разрыв соединения и некоторые люди сочтут это раздражающим. С другой стороны, если контрольные сообщения не посланы, сеанс на сервере может зависнуть, оставив после себя «пользователей-привидений» и отнимая ресурсы сервера.

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

Для отключения контрольных сообщений в файлах конфигурации сервера и клиента должно быть установлено значение «no». KerberosAuthentication Определяет, дозволена ли аутентификация Kerberos. Это может быть либо в форме тикетов Kerberos или, если PasswordAuthentication установлена в «yes», пароль, предоставленный пользователем, будет утвержден через Kerberos KDC. Для использования этого параметра серверу необходима Kerberos servtab, которая разрешит проверку идентификации KDC. Значение по умолчанию «yes». KerberosOrLocalPasswd Если это используется и аутентификация паролем через Kerberos не удалась, тогда пароль будет проверен через любой дополнительный локальный механизм, такой как /etc/passwd . Значение по умолчанию «yes». KerberosTgtPassing Определяет, может ли быть перенаправлен Kerberos TGT к серверу. Значение по умолчанию «no», это работает таким образом когда Kerberos KDC — фактически AFS kaserver. KerberosTicketCleanup Определяет, уничтожать ли автоматически файл кэша тикета пользователя при отключении от системы. Значение по умолчанию «yes». KeyRegenerationInterval В протоколе версии 1, эфемерный ключ сервера будет автоматечески воссоздан по истечении этого количества секунд (если это используется). Цель регенерации состоит в том, чтобы предохранить шифрованные установленные сеансы от более поздних вторжений на машину и захвата ключей. Ключ нигде не сохраняется. Если установлено значение 0, то ключ никогда не будет воссоздан. Значение по умолчанию 3600 (секунд). ListenAddress Указывает с каких локальных адресов sshd должен ожидать соединения. Может быт использован следующий формат записей:

ListenAddress host | IPv4_addr | IPv6_addr

ListenAddress host | IPv4_addr : port

ListenAddress [ host | IPv6_addr ]: port

Если не указан порт, sshd ожидает соединение со всех адресов и на все указанные ранее параметры Port . По умолчанию ожидается соединение со всех локальных адресов. Допустимы множественные значения ListenAddress . Дополнительно, любые парамеры Порт должны предшествовать этому параметру. LoginGraceTime Сервер отключается по истечении этого времени, если пользователю не удалась регистрация в системе. Если стоит значение 0, то время ожидания не ограничено. Значение по умолчанию 60 (секунд). LogLevel Задает степень многословности, который используется при регистрации сообщений от sshd . Допустимыми являются значения: QUIET, FATAL, ERROR, INFO, VERBOSE и DEBUG. По умолчанию используется INFO. Регистрация с уровнем DEBUG нарушает секретность пользователей и не рекомендуется. MACs Определяет допустимый алгоритм MAC (код установления подлинности сообщения). Алгоритм MAC используется в протоколе версии 2 для защиты целостности данных. Множественные алгоритмы должны быть разделены через запятую. Значение по умолчанию

«hmac-md5,hmac-sha1,hmac-ripemd160,hmac-ripemd160@openssh.com,
hmac-sha1-96,hmac-md5-96» MaxStartups Определяет максимальное число одновременных неавторизованных подключений к демону sshd . Дополнительные подключения будут отвергнуты до тех пор, пока не будет произведена аутентификация или не истечет LoginGraceTime для соединения. Значение по умолчанию 10.

Как альтернатива может быть задействован ранний произвольный сброс путем указания трех разделенных через двоеточие значений «старт:норма:полная» (т.е., «10:30:60″). sshd отвергнет соединение с вероятностью «норма/100» (30%) если имеется «старт» (10) неавторизованных соединений. Вероятность возрастает линейно и все попытки соединения будут отвергнуты при достижении числа неавторизованных соединений значения «полная» (60). PAMAuthenticationViaKbdInt Указывает, разрешена ли обратная проверка подлинности вызова при запросе PAM-аутентификации. Это сделает возможным использование модулей аутентификации PAM, но это также позволит идентификацию паролем независимо от того, заблокирован ли PasswordAuthentication . Значение по умолчанию «no». PasswordAuthentication Указывает, разрешена ли аутентификация паролем. Значение по умолчанию «yes». .TP PermitEmptyPasswords Когда разрешена аутентификация паролем, это указывает, позволяет ли сервер регистрацию в системе с пустой строкой пароля. Значение по умолчанию «no». PermitRootLogin Определяет, разрешена ли суперпользователю регистрация в системе с использованием ssh(1). Параметр должен быть «yes», «without-password», «forced-commands-only» или «no». Значение по умолчанию `no».

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

Если этот параметр установлен в значение «forced-commands-only», то будет разрешена регистрация суперпользователя в системе с публичным ключем, но только если был указан параметр команда (что может быть полезно для снятия удаленных резервных копий, даже если регистрация суперпользователя в системе обычно не разрешена). Все другие методы аутентификации для суперпользователя отключены. PidFile Определяет файл, который содержит идентификатор процесса для демона sshd . По умолчанию это /var/run/sshd.pid . Port Определяет номер порта по умолчанию, на котором sshd ожидает соединения. По умолчанию это 22. Допустимы множественные значения для параметра этого типа. Смотри также ListenAddress . PrintLastLog Указывает, будет ли sshd выводить дату и время последнего входа пользователя в систему. По умолчанию «yes». PrintMotd Определяет, будет ли sshd выводить /etc/motd , когда пользователь регистрируется в системе в интерактивном режиме. (В некоторых системах это может быть также напечатано оболочкой, /etc/profile , или эквивалентом.) Значение по умолчанию «yes». Protocol Определяет версию протокола, которую должен поддерживать sshd . Допустимые значения «1» и «2». Множество версий должно быть перечислено через запятую. Значение по умолчанию «2,1». PubkeyAuthentication Определяет, дозволена ли аутентификация публичным ключем. По умолчанию «yes». Имейте ввиду, что это применимо только к протоколу версии 2. ReverseMappingCheck Определяет, будет ли sshd предпринимать попытки проверить имя удаленной машины и проверять, что полученное имя машины для удаленного IP-адреса указывает обратно на тот же IP-адрес. Значение по умолчанию «no». RhostsAuthentication Определяет, является ли использование rhosth или /etc/hosts.equiv достаточным для аутентификации. Обычно, этот метод не должен быть разрешен, так как он небезопасен. Вместо этого должна быть использована RhostsRSAAuthentication , так как это осуществляет RSA-базирующуюся аутентификацию машины в дополнение к нормальной rhosts или /etc/hosts.equiv аутентификации. Значение по умолчанию «no». Этот параметр применим к протоколу версии 1. RhostsRSAAuthentication Определяет, допустимо ли использование rhosts или /etc/hosts.equiv аутентификации вместе с успешной RSA аутентификацией машины. Значение по умолчанию «no». Этот параметр применим только для протокола версии 1. RSAAuthentication Определяет, разрешена ли чистая RSA аутентификация. Знамение по умолчанию «yes». Имейте ввиду, что этот параметр применим только для протокола версии 1. ServerKeyBits Определяет количество бит в ключе сервера эфемерного протокола версии 1. Минимальное значение 512, значение по умолчанию 768. StrictModes Определяет, будет ли sshd проводить проверку режимов и права доступа пользовательских файлов и домашнего каталога перед разрешением регистрации в системе. Это желательно потому, что новички иногда оставляют свои каталоги или файлы доступными для записи всем. Значение по умолчанию «yes». Subsystem Конфигурирует внешнюю подсистему (напр., демон передачи файлов). Параметрами должны быть название подсистемы и команда для выполнения по запросу подсистемы. Команда sftp-server(8) задействует подсистему передачи файлов «sftp». По умолчанию подсистемы не определены. Обратите внимание, что это применимо только к протоколу версии 2. SyslogFacility Присваивает код гибкости, который используется при регистрации сообщений от sshd . Допустимые значения: DAEMON, USER, AUTH, LOCAL0, LOCAL1, LOCAL2, LOCAL3, LOCAL4, LOCAL5, LOCAL6, LOCAL7. По умолчанию используется AUTH. UseLogin Определяет, будет ли использован login(1) для интерактивного сеанса регистрации в системе. Имейте ввиду, что login(1) никогда не используется для удаленного выполнения команд. Значение по умолчанию «no». X11DisplayOffset Определяет первый доступный номер дисплея для перенаправления Х11 для sshd . Это предохраняет sshd от конфликтов с настоящими серверами Х11. Значение по умолчанию 10. X11Forwarding Определяет, разрешено ли перенаправление Х11. Значение по умолчанию «yes». Примите к сведению, что отключение перенаправления Х11 в любом случае не усилит защиту, так как пользователи всегда могут установить свои собственные перенаправления. XAuthLocation Определяет месторасположение программы xauth(1). По умолчанию это /usr/X11R6/bin/xauth . SshVersion Определяет версию программного обеспечения, которая будет отображена. По умолчанию это текущая версия, т.e. OpenSSH_2.9p2.

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

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

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

Обратите внимание, что строки в этих файлах, обычно, имеют несколько сотен байт длины (из-за размера модуля ключа RSA). Вы не должны его вводить туда; вместо этого скопируйте файлы identity.pub , id_dsa.pub или id_rsa.pub и отредактируйте.

Параметры (если имеются) состоят из разделенных через запятую определений параметров. Пробелы не допустимы, кроме заключенных в двойные кавычки. Поддерживаются следующие определения параметров: from=»список-шаблонов» Указывает, что в дополнение к RSA аутентификации, в списке шаблонов, через запятую должно быть представлено каноническое имя удаленной машины. ( `*’ и `?’ используются как символы подстановки). Этот список может также содержать шаблон инвертированный знаком `!’ в начале; если каноническое имя соответствует инвертированному шаблону, то ключ не будет акцептирован. Назначение этого параметра, произвольное увеличение защиты: RSA аутентификация сама по себе на доверяет сети или серверу имен или чему-либо (кроме ключа); однако, если кто-нибудь как-нибудь перехватит ключ, то ключ позволит вторгшемуся войти в систему из любой точки мира. Этот дополнительный параметр делает использование ворованных ключей более затруднительным (в дополнение к одному только ключу компроментировали бы серверы имен и/или маршрутизаторы). command=»команда» Указывает, что команда будет выполнена всякий раз, когда при аутентификации используется данный ключ. Команда, данная (любым) пользователем, игнорируется. Команда выполняется на псевдо-терминале, если соединение требует псевдо-терминала; в противном случае это выполняется без терминала. Обратите внимание, если вы имеете чистый 8-ми битный канал, вы не должны запрашивать псевдо-терминал или указать no-pty . В команду может быть включена кавычка, предварённая символом обратного слэша. Этот параметр полезен для ограничения некоторых RSA-ключей выполнением только специфических операций. Примером может служить ключ, которому разрешено выполнять удаленные операции резервного копирования и ничего более. Учтите, что клиент может указать перенаправление TCP/IP и/или X11, если они не запрещены явно. environment=»ИМЯ=значение» Определяет, что при регистрации в системе с использованием данного ключа к окружению добавляется строка. Переменные окружения указанные таким способом перепишут прочие значения заданного по умолчанию окружения. Допускается использование множества параметров этого типа. no-port-forwarding Запрещает перенаправление TCP/IP, когда для аутентификации используется данный ключ. Любой запрос на перенаправление порта возвратит клиенту сообщение об ошибке. Это может быть использовано, например, вместе с параметром command . no-X11-forwarding Запрещает перенаправление Х11, когда для аутентификации используется данный ключ. Любой запрос на перенаправление порта возвратит клиенту сообщение об ошибке. no-agent-forwarding Запрещает перенаправление агента аутентификации, если при аутентификации используется данный ключ. no-pty Предотвращает назначение терминала (запрос на назначение псевдо-терминала закончится неудачей). permitopen=»машина:порт» Ограничивает локальное «ssh -L» перенаправление портов таким образом, что соединение может быть сделано только к указанной машине и порту. Допускается множественное использование параметров permitopen разделённых через запятую. Не допускается использование шаблонов в названиях машин, только литеральные домены или адреса. restricted-forwarding-to=»шаблон-списка-пар» Определяет, что перенаправление будет запрещено в соответствии со списком разделенных через запятую пар образцов в формате машина:порт (`*’ и `?’ зарезервированы как знаки подстановки). Список также может содержать шаблоны, отрицаемые при помощи знака `!’.

Примеры

from=»*.niksula.hut.fi ,!pc.niksula.hut.fi » 1024 35 23. 2334 ylo@niksula

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

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

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

Биты, экспоненты и модули берутся прямо из RSA ключа машины; они могут быть получены, например, из /etc/openssh/ssh_host_key.pub . Необязательное поле комментария простирается до конца строки и не используется.

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

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

Обратите внимание, что строки в этих файлах обычно имеют длину в несколько сотен знаков и вы определенно не захотите заносить эту информацию в ключи машин от руки. Скорее, вы сделаете это при помощи сценария оболочки или взяв /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. =

ФАЙЛЫ

Эти группы файлов создаются с использованием ssh-keygen(1). /etc/openssh/primes Содержит группы Диффи-Хеллмана, используемые для «Diffie-Hellman Group Exchange». /var/run/sshd.pid Содержит идентификатор процесса sshd ожидающего соединения (если имеются несколько демонов запущенных одновременно для разных портов, то содержит идентификатор процесса для стартовавшего последним). Содержимое этого файла не критично; он может быть открыт на запись для всех. $HOME/.ssh/authorized_keys Описывает ключи RSA которые могут быть использованы для регистрации пользователя. Этот файл должен быть доступен для чтения суперпользователю (что может на некоторых машинах подразумевать доступ для чтения всем, если домашний каталог пользователя расположен на NFS). Рекомендуется чтобы был он недоступен для остальных. Формат этого файла описан выше. Пользователь должен поместить содержимое своего файла identity.pub внутрь этого файла, как описано в ssh-keygen(1). $HOME/.ssh/authorized_keys2 Описывает публичные ключи (RSA или DSA) которые могут быть использованы для регистрации пользователя. Этот файл должен быть доступен для чтения суперпользователю (что может на некоторых машинах подразумевать доступ для чтения всем, если домашний каталог пользователя расположен на NFS). Рекомендуется чтобы он был недоступен для остальных. Формат этого файла описан выше. Пользователь должен поместить содержимое своих файлов id_dsa.pub и/или id_dsa.pub внутрь этого файла, как описано в ssh-keygen(1). «/etc/openssh/ssh_known_hosts» и «$HOME/.ssh/known_hosts» Эти файлы просматриваются когда используется rhosts с RSA аутентификацией машин для проверки публичного ключа машины. Ключ, для того, чтобы он был акцептирован, должен быть описан в одном из этих файлов. Клиент использует те же самые файлы для сверки, что удаленная машина та самая, которая подразумевается для связи. Эти файлы должны быть доступны для записи только суперпользователю/владельцу. /etc/openssh/ssh_known_hosts должен быть доступен для чтения всем, $HOME/.ssh/known_hosts также может, но не обязательно. «/etc/openssh/ssh_known_hosts2» и «$HOME/.ssh/known_hosts2» Эти файлы просматриваются когда используется при аутентификации машин с использованием протокола версии 2 для проверки публичного ключа машины. Ключ, для того, чтобы он был акцептирован, должен быть описан в одном из этих файлов. Клиент использует те же самые файлы для сверки, что удаленная машина та самая, которая подразумевается для связи. Эти файлы должны быть доступны для записи только суперпользователю/владельцу. /etc/openssh/ssh_known_hosts2 должен быть доступен для чтения всем, $HOME/.ssh/known_hosts2 также может, но не обязательно. /etc/nologin Если имеется этот файл sshd отвергнет попытки соединения для любого пользователя, за исключением суперпользователя. Любому кто пытается зарегистрироваться, будет показано содержимое этого файла и соединения не суперпользователя будут отвергнуты. Этот файл дожен быть доступен для чтения всем. /etc/hosts.allow, /etc/hosts.deny Если скомпилирован с поддержкой LIBWRAP , здесь может быть определен контроль доступа tcp-оболочек как описано в hosts_access(5). $HOME/.rhosts Этот файл содержит пары, машина — имя пользователя, разделенные пробелом, по одной на строку. Заданному пользователю на соответствующей машине разрешена регистрация в системе без пароля. Этот же файл используется для rlogind и rshd. Файл должен быть доступен для записи только пользователю; рекомендуется, чтобы он был недоступен для остальных.

Также возможно использование в этом файле сетевых групп. Либо имя машины, либо имя пользователя могут быть в формате +@имя_группы для указания всех машин или всех пользователей в группе. $HOME/.shosts Этот файл для ssh аналогичен файлу .rhosts . Однако этот файл не используется для rlogin и rshd, так что его использование допустимо только с SSH. /etc/hosts.equiv Этот файл используется в процессе аутентификации .rhosts . В самой простой форме этот файл содержит имена машин, по одному на строку. Пользователям на этих машинах разрешается регистрация в системе без указания пароля с использованием одного имени пользователя на обоих машинах. Имя машины так же может следовать за именем пользователя; так пользователям будет разрешена регистрация в системе от имени любого пользователя на этой машине (за исключением суперпользователя). Дополнительно, синтаксис «+@group» может быть использован для указания сетевых групп. Отрицаются записи, начинающиеся с `-‘.

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

Предупреждение: Использование имен пользователей в hosts.equiv всегда является плохой идеей . Остерегайтесь этого, так как это означает, что пользователь может зарегистрироваться в системе под любым именем, включая bin, daemon, adm, и бюджеты других пользователей владеющих важными файлами и каталогами. Использование имени пользователя практически гарантирует пользователю права суперпользователя. Единственное допустимое использование имен пользователей, я думаю, находится в отрицании записей.

Имейте в виду, что это предупреждение также относится к rsh/rlogin. /etc/openssh/shosts.equiv Он обрабатывается аналогично /etc/hosts.equiv . Однако, этот файл может быть полезен в среде, где имеется желание выполнять и rsh/rlogin и ssh. $HOME/.ssh/environment Этот файл (при его наличии) считывается в окружение при регистрации в системе. Он может содержать только пустые строки, строки комментария (те, которые начинаются с `#’) и стоки назначения форм имя=значение. Правом на запись этого файла должен обладать только пользователь; при необходимости не должен быть читаем для остальных. $HOME/.ssh/rc При наличии, этот файл будет выполнен после считывания файлов окружения, но перед запуском оболочки пользователя или команды. Если используется подмена Х11, то на его стандартный ввод будет получена пара «proto cookie» (и DISPLAY в окружение). В этом случае он должен вызываться xauth(1).

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

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

if read proto cookie; then
echo add $DISPLAY $proto $cookie | xauth -q -;

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

Этот файл должен быть доступен для записи пользователю и не должен быть читаем для остальных. /etc/openssh/sshrc Подобен $HOME/.ssh/rc . Может быть использован для определения машино-зависимых глобальных инициализаций во время регистрации в системе. Этот файл должен быть доступен для записи только суперпользователю, а доступен для чтения остальным.

АВТОРЫ

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

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

Александр Блохин — перевод на русский язык.

Источник