ssh sshd чем отличаются

Что такое SSH и чем он отличается от FTP

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

«Оболочка» и учётная запись «оболочки»

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

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

Учётная запись в оболочке, является личной учётной записью, которая предоставляет пользователю доступ к оболочке на другом компьютере. Раньше они были обычным явлением и поставлялись провайдерами Интернет-услуг, которые использовались для хранения файлов, учетных записей электронной почты, групп новостей и многого другого. Общим знаменателем является то, что учетная запись оболочки используется для ввода команд на удаленном компьютере.

SSH использует шифрование с открытым ключом и был разработан в качестве замены Telnet и других небезопасных протоколов. Две основные версии, SSH-1 и SSH-2, в настоящее время являются доминирующими протоколами для доступа к учетным записям оболочки.

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

Протокол безопасной передачи файлов (SFTP) и FTP

Хоть это и не указано в документации для конечного пользователя, SFTP можно рассматривать как надежного родственника FTP. Последний передает все данные в виде простого текста. Таким образом, перехват пакетов может раскрыть важные и личные данные, включая ваше имя пользователя и пароль! SFTP, являясь расширением SSH-2, использует защиту с помощью открытого ключа. Это означает, что данные зашифрованы, когда они передаются, и потенциальные перехваты относительно бесполезны.

Я надеюсь, что вы узнали что-то из этой статьи. Если у вас есть какие-либо вопросы или предложения, отправляйтесь в раздел комментариев ниже!

Источник

Difference between ssh and sshd

I’m trying to secure my environment to possible intruders and i’m wondering what is the difference between ssh and sshd. I’ve already disabled clear text passwords and i’d like to know if i can turn off sshd? Or will that stop me from logging in myself. Thanks.

Related

Join 1M+ other developers and:

These answers are provided by our Community. If you find them useful, show some love by clicking the heart. If you run into issues leave a comment, or add your own answer to help others.

sshd is what listens for an incoming connection – i.e. when you attempt to connect via SSH from your local PC/Mac/Laptop/etc.

So i do need sshd, do you recommend changing the port from 22 to something else? I’ve read a lot for it and against it and i’m not really sure. But i’ve created my server yesterday and i’m getting spammed with constant fail2ban emails about unauthorized attempts to log in 🙁

There are plenty of tools online that one could use to scan for open ports, so even if 22 is closed off, a port scan would most likely reveal that another port is open, which they can then target.

The only way around this would be to firewall off the port and limit it’s access to a certain IP or IP range. If you have a dynamic IP, you’d need to setup a VPN that will allow you to have a static IP, otherwise you’d end up locking yourself out the moment your ISP changes your IP.

Using the firewall to block access by IP will ensure that connection attempts from any IP that isn’t white listed will fail.

Источник

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

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

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

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

Источник

Что такое протокол SSH

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

Иными словами, SSH — это дистанционная командная строка. Визуально вы работаете на своем компьютере, но в реальности — на другом.

Что значит «протокол»?

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

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

Что значит «защищенный»?

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

Для чего нужен SSH?

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

Как подключаться по SSH?

Для подключения к удаленной машине по SSH нужен клиент — специальная программа. В *nix-подобных системах (Linux, macOS) клиент обычно установлен в системе по умолчанию, и достаточно открыть терминал. В Windows нужно скачать сторонний клиент, например, Putty.

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

Например, для подключения к серверу 52.307.149.244 в аккаунт ivan нужно ввести:

В графическом клиенте вроде Putty нужно ввести ту же информацию в соответствующие поля:

Fingerprint

При первом подключении появится сообщение:

Введите yes в первый раз.

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

Если fingerprint не меняется, то такое сообщение не будет появляться.

Подключение по SSH по паролю

Простейший вариант — подключение по паролю. После ввода команды ssh система запросит пароль:

Пароль придется вводить каждый раз.

Подключение по SSH по ключу, без пароля

Для удобного подключения по SSH (и многим другим сервисам) без ввода пароля можно использовать ключи.

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

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

Генерация ключей

Создадим пару ключей:

Программа запустится и спросит, куда сохранять ключи:

Программа запросит passphrase. Это вроде пароля для ключа. Можно просто нажать Enter и пропустить этот шаг. Или ввести passphrase — тогда его нужно будет вводить каждый раз, когда используется ключ.

Теперь у вас есть два файла:

/.ssh/id_rsa — приватный ключ. Никогда никому и никуда не передавайте его!

/.ssh/id_rsa.pub — публичный ключ. Спокойно распространяйте его.

В Windows можно использовать ssh-gen в подсистеме Ubuntu for Windows или в командной строке Git for Windows. Или создавать ключи графической утилитой вроде PuTTYgen.

Загрузка публичного ключа на сервер

Нужно добавить публичный ключ на сервер в файл

Другой способ — подключиться по паролю, открыть в редакторе файл

/.ssh/authorized_keys и добавить в конец текст из вашего файла

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

ssh-agent

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

ssh-agent решает эти проблемы. Этот агент аутентификации (authentication agent) работает на фоне в *nix-системах. В зависимости от системы, вам, возможно, придется установить и настроить его автозапуск самостоятельно.

Если добавить ключ к агенту, то:

ssh-add /home/demo/.ssh/id_rsa добавит ключ id_rsa в запущенный в системе агент. Если у него есть passphrase, то агент попросит ввести его.

Если запустить ssh-add без аргументов, то будут добавлены ключи

ssh-agent привязан к сессии. Поэтому, например, если перезагрузить компьютер, то ключи нужно будет добавлять в агент заново.

Форвардинг (проброс) ключей

Если вы подключились к удаленному серверу X, и с него хотите подключиться к другому серверу Y, например, чтобы сделать git pull с GitHub’а, то придется держать копию ваших ключей на сервере X.

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

Частые вопросы

Чем Telnet отличается от SSH?

Telnet это конкретная программа с графическим интерфейсом, с помощью которой можно соединяться по SSH. Обычно ей пользуются только Windows пользователи, в Linux и MacOS используют консольную утилиту ssh.

Источник

Interent в нашей стране становится все распространеннее. Но вместе с тем становятся все реальнее угрозы безопасности, в том числе, и со стороны хакеров, а точнее говоря, кракеров — как доморощенных, так и зарубежных. Одновременно расширяется применение Unix-систем: ее повсеместно используют как Internet-провайдеры, так и потребители и поставщики ресурсов Сети.

Банковские и некоторые другие виды транзакций в корпоративных сетях предъявляют особые требования к системе безопасности. Появляются и новые Internet-приложения, требующие повышенных мер безопасности, в частности, электронная коммерция. Все это означает повышенное внимание к средствам обеспечения компьютерной безопасности в ОС Unix.

Причиной нашего внимания к этой теме является не только популярность ssh среди пользователей, работающих в самых разных областях. Хотя ssh появился лишь в 1995 г., в настоящее время он уже рассматривается как проект стандарта Internet, подготовкой которого занимается специальная рабочая группа secsh в IETF Security Area (http://www. ietf.org/html/charters/secsh-charter.html). Строго говоря, в этой рабочей группе стандартизуется, конечно, не ssh как программный продукт, а набор протоколов ssh.

Тем временем, ssh уже завоевал статус фактического стандарта Internet на безопасные терминальные соединения. Автором первоначального варианта ssh является Т. Ялонен (ylo@cs.hut.fi). В настоящее время выпущена вторая версия ssh; разработкой программного продукта SSH2 занимается компания SSH Communication Security (http://www.ssh.fi).

Кроме версии ssh, доступной бесплатно, имеется и усовершенствованный коммерчески доступный вариант. Кроме того, с использованием этой программы разработаны и некоторые другие коммерческие продукты. Поставками коммерческой версии ssh занимается Data Fellows (http://www. datafellows.com/f-secure); эта компания предлагает, в частности, программные продукты F-secure SSH Server и F-Secure SSH Tunell & Terminal.

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

Что касается типов обеспечиваемого удаленного доступа, ssh поддерживает возможности работы с telnet; безопасную работу с протоколом X11 благодаря возможности перенаправления соответствующих данных по надежным ssh-каналам; безопасную замену многим «r»-командам Unix (rsh, rlogin и т.д.), с которыми, как известно, традиционно связаны проблемы обеспечения безопасности.

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

Протокол ssh

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

Протокол транспортного уровня предусматривает возможность сжатия данных. Этот протокол работает поверх соединения TCP/IP. Протокол аутентификации работает поверх протокола транспортного уровня, а протокол соединения — поверх протокола аутентификации.

Клиент шлет запрос на обслуживание в первый раз, когда устанавливается безопасное соединение транспортного уровня ssh. Второй запрос направляется уже после завершения аутентификации пользователя (клиента).

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

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

Протоколом предусмотрена возможность отказа от проверки ключа хоста-сервера при самом первом обращении клиента к этому серверу. При этом соединение клиент-сервер будет защищено от пассивного прослушивания сети, но возникает опасность атаки типа «человек в середине» (man-in-the-middle), т. е. попытки временной подмены сервера. Если эта возможность используется, ключ хоста-сервера будет автоматически передан клиенту и сохранен в его локальном файле.

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

Таблица 1. Номера сообщений ssh и их назначение

Наконец, несколько слов о кодировании сетевых адресов. Поскольку DNS — ненадежный протокол, в ssh он не используется. При адресации применяются IP-адреса, причем в проекте заложена поддержка IPv6.

Установка

При установке всякого бесплатно распространяемого по Internet программного продукта — и ssh здесь не исключение — часто приходится сталкиваться с тем, что используемая Вами версия ОС Unix «чуть-чуть» отличается от того, чего ждали от нее разработчики данного продукта. В результате программный продукт может оказаться не вполне работоспособен, или вовсе транслироваться с ошибками. Автор столкнулся с некоторыми особенностями установки ssh в средах SGI Irix и Linux; о них будет рассказано ниже. Формально наше изложение относится к ssh версии 1.2.26, если явно не оговорено противное (процедуры установки различных версий ничем кардинальным не отличаются).

После того, как дистрибутив ssh получен и разархивирован, процедура установки включает три простых стадии. На первой следует выполнить командный файл configure. Все основные особенности создаваемого варианта ssh задаются параметрами, указываемыми при запуске configure. Можно задать целый ряд ключей (операндов).

В частности, указывается, какие методы шифрования сеанса будут использованы при работе ssh (предлагается, в частности, IDEA, DES, «тройной» DES, ARCFOUR, BLOWFISH). Поскольку в ARCFOUR найдена «дыра», по умолчанию этот метод исключается, а остальные, наоборот, включены. Основным по умолчанию является IDEA, использующий 128-разрядные ключи. Если он исключен, основным алгоритмом становится 3DES, трехкратное последовательное DES-шифрование c 56-разрядным ключом. Учитывая несколько нашумевших «вскрытий» однократного DES-ключа, это выглядит разумной предосторожностью. Нужно отметить также метод BLOWFISH, который при той же длине ключа (от 32 до 448 разрядов) работает быстрее IDEA и DES. Используемый по умолчанию метод шифрования можно указать явно, установив нужное значение SSH_FALL BACK_CIPHER во включаемом файле ssh.h.

Можно задать также замену стандартных команд rlogin и rsh соответствующими одноименными модулями из дистрибутива ssh. Тогда для соединений будет использоваться протокол ssh — конечно, если удаленный компьютер его поддерживает (в противном случае после предупреждения будет осуществлен переход к обычным средствам rlogin/rsh).

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

где ПУТЬ задает путь к библиотеке libwarp.a, которая требуется при использовании tcp_wrapper (в этом случае кроме libwrap.a для установки ssh понадобится также файл tcp.h). Последний операнд указывает на работу с протоколом X11.

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

На второй стадии установки запуск make приводит к компиляции всех основных модулей ssh. Наконец, третья стадия установки запускается по команде make install. При этом происходит запись порожденных программ в «целевые» каталоги (по умолчанию /usr/local/bin, /usr/local/sbin, /usr/local/man), а также создание нескольких файлов в каталоге /etc: ssh_config, sshd_config и ssh_host_key_pub.

В случае неудачи команда make distclean должна удалить все следы проделанного «эксперимента», кроме самого дистрибутива. Так написано в документации; на самом деле: в /usr/local/sbin и /usr/local/bin все остается.

В реальной жизни, конечно, возникают проблемы. Приведем некоторые конкретные примеры. Так, с ОС Irix не рекомендуется использовать версии ssh от 1.2.21 и более ранние из-за большого числа ошибок; желательно применять версии 1.2.25 и выше.

Поскольку применение ssh может вызвать задержки из-за загрузки процессора операциями шифрования, ssh желательно компилировать с оптимизацией. configure, кстати, имеет специальный операнд, разрешающий оптимизацию на уровне ассемблера. В качестве иллюстрации укажем, что для рабочей станции SGI O2 c микропроцессором R5000SC и ОС Irix 6.3, включение оптимизации Си-компилятора дает прирост производительности примерно на 25%. Однако есть сообщения, что такая оптимизация иногда вызывает ошибки при перенаправлении портов X11.

Таблица 2. Некоторые поддерживаемые ssh
операционные системы

В ssh 2.0.8 при трансляции в ОС Irix рекомендуется использовать Си-компилятор версии 7.2, поскольку он позволяет создать более производительную программу по сравнению с 7.1. Однако следует использовать cc 7.2.1, поскольку «исходный» Си-компилятор версии 7.2 дает неработоспособный ssh.

Файлы ssh

Обратимся сначала к образующимся после установки исполняемым файлам. Основных файлов два: cобственно демон sshd в /usr/local/sbin и клиент ssh в /usr/local/bin. В последнем каталоге располагается также модуль scp (ssh-аналог rcp) и ряд модулей с префиксом ssh_, среди которых отметим модули ssh_agent (аутентификационный агент, хранящий RSA-ключи аутентификации) и ssh_add, служащий для регистрации новых ключей в этом агенте. Кроме того, в /usr/local/bin имеется две важных вспомогательных утилиты: ssh-keygen и make-ssh-known-hosts.

Неисполняемые файлы ssh (кроме справочных файлов, помещаемых в /usr/local/man) располагаются в каталогe /etc и в домашних каталогах пользователей. В каталоге /etc расположены конфигурационные файлы sshd_config и ssh_config, задающие конфигурационные параметры соответственно sshd и ssh; эти файлы образуются автоматически по завершению установки.

В каталог /etc помещается информация о ключах. В файле ssh_host_key задается ключ хоста-сервеssh_host_key_pub) помещается в файл ssh_known_hosts. Естественно, его надо создавать самостоятельно.

В каталоге /etc образуется также рабочий файл ssh_random_seed, который автоматически модифицируется при запуске демона sshd. Наконец, в каталоге /etc могут располагаться еще два файла. Файл shosts.equiv является аналогом файла rhosts.equiv при работе с ssh. Файл sshrc выполняется при процедуре login перед вызовом оболочки.

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

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

ssh-keygen [-b длина] [-N парольная_фраза] [-c комментарий]

Утилита make-ssh-known-hosts представляет собой сценарий на языке Perl5 и служит для автоматизации создания файлов типа ssh_known_hosts. Если на компьютере Perl5 не установлен, подобные файлы придется создавать вручную.

Данная утилита обладает развитые средства взаимодействия с DNS-серверами и позволяет выполнять достаточно изощренный опрос этих серверов. Простейшая форма вызова имеет следующий вид:

make-ssh-known-hosts some.domain > /etc/ssh_known_hosts

Это позволяет найти и записать в файл ssh_known_hosts открытые ключи всех хостов домена some.domain. Утилита имеет, в частности, средства работы с WKS-записями DNS-сервера. Если в этих записях указан признак наличия ssh, то можно сразу отобрать только хосты, поддерживающие ssh. Аналогично можно отобрать хосты, поддерживающие telnet:

Утилита может работать аналогичным образом с записями hinfo. Механизм ее работы следующий.

Демон sshd

Запуск демона sshd обычно происходит автоматически при загрузке операционной системы из командного файла наподобие /etc/rc.local. Поскольку sshd должен сгенерировать ключ еще до установления соединения, что требует определенного времени, sshd не рекомендуют запускать через демон inetd. Однако, если процессор достаточно быстр, и длина ключа мала (меньше 512 разрядов), демон может периодически запускаться через inetd при каждой попытке соединиться на порт 22.

Параметры демон sshd читает из файла /etc/sshd_conf. В нем задаются, в частности, ссылки на файлы ssh_host_key и ssh_random_seed, длина ключа сервера, разрешенные методы шифрования, номер используемого sshd порта, уровень протоколирования работы sshd в системном журнале и др. Обычно этот файл является вполне подходящим, и необходимости его корректировать не возникает.

Клиент ssh

Клиент ssh cлужит в качестве замены командам rsh и rlogin. Типичная форма вызова ssh выглядит так:

ssh [-l имя_пользоваетля] ИМЯ_ХОСТА [команда]

Здесь ИМЯ_ПОЛЬЗОВАТЕЛЯ означает имя пользователя на удаленном хосте, с которым происходит соединение (задается операндом ИМЯ_ХОСТА). Операнд КОМАНДА, если он не опущен, указывает выполняемую на удаленном хосте команду.

Два операнда позволяют осуществлять перенаправление портов:

позволяет перенаправить ПОРТ локального компьютера на ПОРТХОСТА удаленного компьютера, заданного в аргументе ХОСТ;

осуществляет перенаправление ПОРТа на удаленном ХОСТе на порт локального хоста (последний аргумент).

Конфигурационные файлы клиента включают общий файл /etc/ssh_config и личные пользовательские config-файлы. Последние «перекрывают» действие общего файла, и их, в свою очередь, можно заменить явным заданием операндов ssh. В конфигурационном файле задаются такие параметры, как методы шифрования, возможность перенаправления портов, разрешение на использование обычных механизмов rsh/rlogin при невозможности ssh-аутентификации, номер используемого на удаленном сервере порта и др.

Отметим, что на локальном компьютере клиент ssh использует не порт 22, а выбранный случайно из диапазона непривилегированных портов.

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

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

Клиент проверяет ключ хоста-сервера, и если эта аутентификация проходит, генерирует 256-разрядное случайное число, шифрует его с помощью ключей хоста-сервера и sshd, и пересылает серверу. Это случайное число затем используется обеими сторонами в качестве ключа сеанса, используемого во всех последующих передачах данных в этом сеансе.

Остаток сеанса шифруется симметрично. Клиент выбирает алгоритм шифрования из числа тех, что предлагает ему sshd. Поэтому, в частности, ssh как программный продукт позволяет легко добавлять новые криптографические алгоритмы, например, национальные стандарты. Никаких паролей «в чистом виде» не передается, поскольку шифрование начинается до аутентификации.

Клиенты и серверы ssh разных версий успешно взаимодействуют друг с другом. Однако в случае большой «разницы в возрасте» (например, между версиями 1.2.13 и 1.2.26) некоторые возможности более новых версий работать не будут.

Отметим в заключение, что ssh-клиенты разработаны не только для Unix, но и для других операционных систем, в том числе для Windows (http:// www-acg.ncsa.uiuc.edu/ssh).

Заключение

Полезно упомянуть основные ssh-ресурсы: Web-узел группы пользователей ssh (http://www.ssh.org); группу новостей comp.security.ssh; список рассылки ssh@clinet.fi на сервере majordomo@clinet.fi. Имеются и коммерческие продукты, использующие ssh: IPSEC Express Toolkit, ISAKMP/Oakley Toolkit, X.509 Certificate Toolkit и др. В Web можно найти и такие «полезные мелочи», как, например, Java-апплет для ssh (http://www.cl.cam.ac.uk/

В статье не ставилась попытка дать полное описание ssh, и многие вопросы вообще остались без рассмотрения(в частности, работа с X11). В то же время автор старался обратить внимание на основные (с его точки зрения) характеристики ssh и указать на потенциально существенные для системных администраторов особенности конкретных операционных систем, с которыми он сталкивался сам.

Автор благодарит РФФИ (проект 98-07-90290) за поддержку.

Поделитесь материалом с коллегами и друзьями

Источник