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

Основы использования протокола SSH

Настройка SSH доступа к вашему серверу

Шаг 1: Логинемся под пользователем root

По делу: не работайте от root, пожалуйста!

Шаг 2: Создание нового пользователя SSH

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

Вам будет задано несколько вопросов, начиная с пароля учетной записи.

Введите надежный пароль и, при желании, введите любую дополнительную информацию. Это не обязательно, и вы можете просто нажать ENTER в любом поле, которое хотите пропустить.

Шаг 3: Предоставление административных привилегий

Чтобы избежать необходимости выходить из системы обычного пользователя и снова входить в систему как учетная запись root, мы можем настроить так называемые привилегии суперпользователя или root для нашей обычной учетной записи. Это позволит нашему обычному пользователю запускать команды с административными привилегиями, помещая слово sudo перед каждой командой.

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

От имени пользователя root выполните команду usermod, чтобы добавить нового пользователя в группу sudo (замените имя пользователя своим новым пользователем:

Проверим командой id добавился ли пользователь в группу sudo

Теперь, когда вы войдя в систему как обычный пользователь remuserbak, можете ввести sudo перед командами, чтобы выполнять действия с привилегиями суперпользователя (root).

Шаг 4: Защита демона sshd

После установки сервера SSH, первым делом исправить файл sshd_config. В нем запретить удалённый доступ пользователя root и разрешить доступ только для доверенных пользователей. Настраиваем от непривилегированного пользователя, используя sudo.

Посмотреть текущее настройки демона ssh

Отключение SSH-логин для пользователя root, используя параметр PermitRootLogin no.

Теперь при попытке залогинеться с пользователем root, в логах вы увидите запись:

Всё, у вас демон SSH минимально защищен!

Дополнительные параметры sshd_config, которые можно менять, под ваши задачи и условия, но не делайте это без нужды и предварительно изучите руководство man 5 sshd_config

Шаг 5: Расширенная защита демона sshd

Дополнительно о SSH

Зачем файл sshrc

man sshd раздел SSHRC рассказывает об использовании файла /etc/ssh/sshrc. Если этот файл создан с правами на выполнение, то он будет запускать после успешного логина пользователя, но до запуска оболочки пользователя, например bash.

Пример. Настройка опций подключения для отдельных хоcтов ssh

Если вам достался шел с неудобочитаемым именем типа hoster2956@super.puper.shell.net.org то сложно его набирать при запуске ssh(scp,sftp), да и запомнить (пусть даже и с автодополнением как тут. И допустим нужно указывать подключиться к определенному хосту по ssh1. В

протестируем скопировав на этот хост файл

Пример. multiple ssh private keys

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

итак: делаем ssh-ключи для беспарольной авторизации.

Мы обзавелись ключами, раскидали их публичные части в authorized_keys соотвествующих хостов. Теперь определим с каким ключем куда ходить:

с содержимым, например

это подтянет соотв. конфиги при

Конечно, при подключении к хосту, который не определен в

/.ssh/id_rsa, или логин/пароль если иначе не прописано в конфиге.

ssh-keygen

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

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

Пример. Использование ssh-keygen

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

/.ssh/id_rsa, а публичный в

/.ssh/id_rsa.pub (для ключей DSA и RSA соответственно). Для включения аутентификации по ключам публичный ключ должен быть помещен в файл

/.ssh/authorized_keys на удаленном компьютере.

Это позволяет соединяться с удаленным компьютером с помощью SSH-ключей вместо паролей.

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

Пример. Скрипт. Копирование файла с удаленного компьютера.

Задача. На удаленном компьютере Anacron запускает скрипт для резервирования БД PostgreSQL один раз в сутки. Нужно создать скрипт который будет копировать удаленные backup-копии на локальный сервер бекапов. Скрипт запустим при помощи Использование планировщика cron в Linux.

Поместим публичный ключ файл

/.ssh/authorized_keys на удаленном компьютере.

Скрипт:

Пример. ssh-keygen. Ключи для Azure

Создание ssh ключей для виртуальной Linux в Microsoft Azure. Для создания и использования ключей SSH с Azure выполните описанные ниже действия.

Будут созданы два ключа azuressh и публичный azuressh.pub. Чтобы без ошибок скопировать содержимое azuressh.pub и вставить его в поле при создании VE, используйте ssh-keygen. Весь вывод, без исключений нужно копировать.

Не забудьте настроить файл config, для большего удобства.

Источник

Тонкая настройка демона SSH на Linux VPS

SSH – это основной способ подключения к удаленным Linux- и Unix-подобным серверам с помощью командной строки. SSH обеспечивает безопасное соединение, которое позволяет запускать команды, взаимодействовать с системой и создавать туннели.

Большинство пользователей знают об основных принципах запуска и подключения к удаленному серверу. Обычно это делается с помощью такой команды:

Есть еще много вариантов настройки SSH-демона, которые могут повысить безопасность, улучшить управление пользовательскими подключениями и т. д. В данном руководстве рассматриваются опции тонкой настройки SSH.

Примечание: Руководство выполнено на сервере Ubuntu 12.04, но любой современный дистрибутив Linux должен работать аналогичным образом.

1: Конфигурационный файл SSHD

Основным конфигурационным файлом демона SSH является /etc/ssh/sshd_config.

Примечание: Не путайте этот файл с ssh_config, который определяет параметры клиентов.

Откройте файл в редакторе:

sudo nano /etc/ssh/sshd_config

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

Рассмотрим базовые опции в файле дистрибутива Ubuntu 12.04.

Порты и протоколы

Ключи

Логирование и ограничения

Отображение на экране

Подключения и среда

2: Другие опции SSHD

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

Фильтрация пользователей и групп

Некоторые параметры позволяют контролировать, какие пользователи будут иметь возможность входа через SSH. Эти опции следует рассматривать как взаимоисключающие. Например, параметр AllowUsers подразумевает, что всем остальным пользователям доступ запрещен.

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

Дополнительные опции

Существует несколько параметров для настройки сетевого трафика, который будет прослушивать демон SSH:

Доступны также параметры для настройки аутентификации на основе сертификатов, параметры ограничения подключения (ClientAliveCountMax и ClientAliveInterval), а также опции, которые могут изолировать вошедшего в систему пользователя в предварительно сконфигурированной среде chroot (опция ChrootDirectory).

3: Ограничение входа

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

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

AllowUsers demouser fakeuser madeupuser

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

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

Эта строка сделает то же самое:

разрешит доступ в систему пользователям tim, jim, vim и т.п.

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

AllowUsers demouser@host1.com fakeuser

Эта опция заблокирует доступ всем пользователям с именем fakeuser и пользователю demouser, если он принадлежит хосту host1.

Также ограничить доступ по хосту вне файла sshd_config через TCP-упаковщики. Это настраивается с помощью файлов /etc/hosts.allow и /etc/hosts.deny.

Например, ограничить доступ можно на основе трафика SSH; для этого нужно добавить такие строки в файл hosts.allow:

Предположим, что в файле hosts.deny есть строка, которая выглядит так:

Она разрешит вход в систему только тем пользователям, которые приходят с домена example.com или субдомена.

4: Опция match

Опция match определяет шаблон критериев, согласно которому будут применяться или не применяться остальные параметры.

Опция Match содержит пары «ключ-значение». Она может использовать ключи User, Group, Host, Address. Их можно отделить друг от друга пробелами. Сами шаблоны отделяются запятыми. Также тут можно использовать подстановочные символы и инвертированные параметры.

Шаблон сработает только тогда, когда пользователь – не demouser или fakeuser, входит в группу sshusers и привязан к example.com или поддомену.

Ключ Address может обрабатывать CIDR.

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

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

Чтобы увидеть полный список параметров Match, посмотрите справочную страницу sshd_config:

Найдите раздел Match.

Заключение

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

Файл /etc/ssh/sshd_config позволяет управлять доступом к серверу. Умение настраивать SSH – очень важный навык для всех пользователей Linux.

Источник

Что такое демон 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.

Источник

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.

Источник