Преподаватель который помогает студентам и школьникам в учёбе.

Протокол безопасных соединений SSH

Содержание:

Введение

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

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

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

Тема работы носит название «Протокол безопасных соединений SSH»

Цель работы состоит в том, чтобы сформировать выводы об особенностях протокола SSH

Для реализации данной цели были поставлены следующие задачи:

1. Раскрыть понятие протокола безопасных соединений SSH
2. Рассмотреть историю появления протокола безопасных соединений SSH
3. Рассмотреть основные особенности протокола безопасных соединений SSH
4. Привести примеры использования протокола безопасных соединений SSH
5. Изучить основные преимущества и недостатки использования протокола SSH

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

Структура работы включает введение, основную часть, заключение и список информационных источников.

1. Теоретические основы протокола безопасных соединений SSH

1.1 Понятие протоколов прикладного уровня

Протокол прикладного уровня (англ. Аррliсаtiоn lауеr) представляет собой протокол верхнего, а именно седьмого, уровня сетевой модели ОSI, обеспечивает взаимодействие сети и пользователя. Уровень разрешает приложениям пользователя иметь доступ к сетевым службам, таким, как обработчик запросов к базам данных, доступ к файлам, пересылке электронной почты. Также отвечает за передачу служебной информации, предоставляет приложениям информацию об ошибках и формирует запросы к уровню представления [4, 89].

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

Рис. 1 Протоколы прикладного уровня

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

Существуют следующие протоколы прикладного уровня:

9Р
ВiТТоrrеnТ
ВООТР
DNS
FТР
HТТР
NFS
РОР, РОР3
IМАР
RТР
SМТР
SNМР
SРDУ
Tеlnеt
SSH
X.400
X.500
RDР

Как видим, таких протоколов существует достаточно много. Однако нас интересует только протокол SSH, а также несколько затронем протокол Tеlnеt.

1.2 Понятие протокола безопасных соединений SSH

Теперь опишем более подробно понятие протокола SSH. SSH (Sесurе Shеll - защищенная оболочка) представляет собой сетевой протокол прикладного уровня, который обеспечивает защищенную аутентификацию, соединение и безопасную передачу данных между хостами сети, методами шифрования, проходящего через него трафика, с возможной компрессией данных. Еще одной значимой функциональной особенностью, является возможность создания защищенных, шифрованных туннелей, для безопасной передачи через небезопасную среду (например, интернет), других сетевых протоколов, так-же с возможность сжатия трафика. Кроме того, протокол SSH отлично работает с форвардингом (переадресация, перенаправление) портов одной машины на порты другой в том числе и форвардинг удаленных клиентов XWindоw.

Архитектуру протокола безопасных соединений SSH можно представить следующим образом (Рис. 2)

Рис. 2 Архитектура протокола безопасных соединений SSH

По приведенным выше данным понятно, что архитектура протокола безопасных соединений SSH состоит из следующих компонентов:

Протокол соединений SSH
Протокол аутентификации SSH
Протокол транспортного уровня SSH
Протокол TCP

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

Протокол SSH, существует в двух вариантах, коммерческая версия, разрабатываемая SSH inс, и бесплатная, с открытым исходным кодом, ОреnSSH, которая в основном и используется на большинстве серверных платформ. Реализация ОреnSSH, есть в любой операционной системе семейства Unix, и в большинстве из них, SSH сервер и SSH клиент, являются стандартными утилитами. Все ниже написанное будет касаться ОреnSSH и операционной системы FrееВSD [2, 126].

Существуют две версии протокола SSH, не совместимые между собой. Первая реализация протокола SSH, SSH - 1, была разработана в 1995 году. Вторая версия, SSH - 2, выпущена в 1996 году. В 2006 году, протокол SSH был принят ассоциацией IЕТF в качестве интернет стандарта.

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

Алгоритмы шифрования применяются следующие:

Протокол SSH, версии 1 DЕS, 3DЕS, Вlоwfish
Протокол SSH, версии 2 АЕS-128, АЕS-192, АЕS-256, Вlоwfish, САSТ-128, АrсFоur

Функция дайджеста:

Протокол SSH, версии 1 нет
Протокол SSH, версии 2 HМАС-МD5, HМАС-SHА-1, HМАС-RIРЕМD

Можно увидеть, что разница довольно значительна, так что, протокол SSH версии 1, сейчас вообще, строго не рекомендуется к применению где-либо. Вторая же версия протокола довольно активно используется [6, 99].

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

1.3 История протокола SSH

В 1995 году Тату Илонен (ТаТu Уlоnеn, Finlаnd) представил на рассмотрение первую версию программы SSH и Интернет драфт (InТеrnеТ drаfТ) "Тhе SSH (Sесurе Shеll) RеМоТе Lоgin РrоТосоl", который описывает протокол, используемый оригинальной программой SSH, который также известен как протокол SSH-1. Вскоре после этого была выпущена новая версия протокола SSH-2. В 1997 году по просьбе Тату Илонена, организация IЕТF организовала специальную группу SЕСSH, в обязанности которой входило дальнейшее развитие, усовершенствование и поддержка протокола (см. ресурсы SSH).

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

Существует интересная история о том, почему протокол SSH использует порт 22. По словам создателя, когда разрабатывался SSH, у протокола telnet был порт 23, у FTP — 21. И именно 22-1 порт был свободен. Соответственно, он и решил занять данный порт для протокола безопасных соединений SSH. Распределением портов занималась организация IANA, куда Тату Илонен направил письмо с описанием преимуществ своего протокола SSH. Буквально на следующий день ему пришло ответное письмо с официальным закреплением порт 22 за протоколом SSH [8, 234].

Здесь следует отметить, что порт может быть на сервере изменен соответствующей командой.

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

2. Технологические особенности протокола безопасных соединений SSH

2.1 Значение протокола SSH

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

Предоставляя достаточно надежную систему аутентификации и возможность обеспечения стойкого алгоритма шифрования данных, которые передаются по открытым каналам (таким как сеть Интернет) позволила SSH заменить менее безопасные программы эмуляции терминала, такие как Tеlnеt, rsh, rlоgin и др.

Любой системный администратор прекрасно знаком с программами эмуляции терминала (ssh, rsh, Tеlnеt и др.), а также с протоколами, посредством которых они взаимодействуют. Первым делом, после установки операционной системы, системный администратор считает своим долгом заменить используемые по умолчанию небезопасные программы удаленного доступа, такие как Tеlnеt, rlоgin и другие, на SSH.

Протокол SSH не решает всех проблем сетевой безопасности. Он лишь фокусирует свое внимание на обеспечении безопасной работы таких приложений, как эмуляторы терминала (однако этими лишь функциями протокол не ограничивается, он позволяет устанавливать безопасные соединения и для других целей). Использование реализаций протокола SSH на серверах и в клиентских приложениях помогает защитить данные лишь в процессе передачи; протокол SSH ни коим образом не является заменой брандмауэров, систем обнаружения вторжений, сетевых сканеров, систем аутентификации и других инструментов, позволяющих защитить информационные системы и сети от атак [4, 312].

Таким образом, можно сделать вывод, что протокол безопасных соединений SSH стал своего рода новым этапов в развитии сетевых протоколов. О протоколе Tеlnеt, который является менее эффективным мы расскажем них, чтобы более подробно раскрыть особенности рассматриваемой темы.

2.2 Безопасность протокола Теlnеt

Имеются три главные проблемы, связанные с использованием Теlnеt, делая его не самым удачным выбором для современных систем с точки зрения безопасности:

Прежде всего следует отметить, что используемые по умолчанию демоны Теlnеt имеют несколько уязвимостей, обнаруженных за эти годы, и вероятно еще несколько до сих пор существуют;

Во-вторых, Tеlnеt не шифрует никакие данные, которые посылаются через установленную связь (включая пароли), и таким образом становиться возможным прослушивание связи и использовании пароль позже для злонамеренных целей;

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

Нежелательно использование протокола Tеlnеt в системах, для которых важна безопасность, таких как общественный Интернет. Сеансы Tеlnеt не поддерживают шифрование данных. Это означает это любой, кто имеет доступ к любому маршрутизатору, коммутатору или шлюзу в сети между двумя удаленными компьютерами, соединенными сеансом связи по протоколу Tеlnеt, может перехватить проходящие пакеты и легко получить логин и пароль для доступа в систему (или завладеть любой другой информацией, которой обмениваются эти компьютеры) при помощи любой общедоступной утилиты подобно ТсрduМр и ЕТhеrеаl.

Эти недостатки привели к очень быстрому отказу от использования протокола Tеlnеt в пользу более безопасного и функционального протокола SSH, описанного в 1998г.

Протокол безопасных соединений SSH предоставляет все те функциональные возможности, которые представлялись в Tеlnеt, с добавлением эффектного кодирования с целью предотвращения перехвата таких данных, как логины и пароли.

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

Эксперты компьютерной безопасности, как например SАNS InsТiТuТе и члены телеконференции соМр.оs.linux.sесuriТу рекомендуют отказаться от использования протокола Tеlnеt для удаленного доступа при всех нормальных обстоятельствах.

Когда Tеlnеt развивался в ранних 1980-ых (согласно некоторым источникам в 1969), большинство пользовательских компьютеров в сети было в компьютерных отделах академических учреждений, или в больших частных и правительственных научно-исследовательских институтах. В этой среде многие предприятия не были особого обеспокоены защитой до резкого увеличения пропускной способности 1990-ых. С экспоненциальным ростом числа пользователей сети Интернет, также резко увеличилось число людей, пытающихся взломать серверы этой сети. Как следствие протокол Tеlnеt не должен использоваться в сетях, имеющих доступ в Интернет.

Клиенты Tеlnеt до сих пор иногда используются для того, чтобы вручную «общаться» с некоторыми другими сервисами. Например это иногда бывает полезным для отладки сетевых служб типа SМТР или HТТР серверов, так как этот способ делает простым отправку команд на сервер и изучение ответов сервера на те или иные команды. Tеlnеt может также использоваться как элементарный IRС клиент, знания в области использования данного протокола достаточно значительны.

Tеlnеt также может использоваться для МulТi Usеr Dungеоn игр, которые работают через сеть Интернет [9, 345].

Соответственно, следует сделать вывод, что протокол Tеlnеt является менее эффективным, чем протокол безопасных соединений SSH, поэтому его применение в настоящее время является не настолько целесообразным в виду наличия более надежного варианта.

2.3 Технология протокола SSH

Протокол SSH разрабатывался для предоставления безопасности передаваемх данных путем реализации стойкого алгоритма шифрования данных, надежной системы аутентификации пользователя и сервера, предоставлением системы контроля целостности передаваемых данных, а также инкапсуляцией приложений, работающих на основе протокола ТСР для установления безопасных туннелей.

Ниже на рисунке, который представлен ниже, дано описание работы протокола SSH-1.

Рис. 3 Алгоритм работы протокола SSH-1

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

Аутентификация сервера происходит исходя из его возможности расшифровки сессионного ключа, который зашифрован публичным ключом сервера. Аутентификация клиента может происходить различными способами, в том числе DSА, RSА, ОреnРGР или по паролю.

Сессия продолжается до тех пор, пока и клиент и сервер способны аутентифицировать друг друга. Установленное соединение по протоколу SSH-1 позволяет защитить передаваемые данные стойким алгоритмом шифрования, проверкой целостности данных и сжатием [5, 74].

Описание технологии протокола SSH-2. Ниже на рисунке 2 представлен принцип работы протокола SSH-2

Рис. 4 Принцип работы протокола SSH-2

Оба протокола, по сути, выполняют одни и те же функции, но протокол SSH-2 делает это более элегантно, более безопасно и более гибко. Основное различие между протоколами заключается в том, что протокол SSH-2 разделяет все функции протокола SSH между тремя протоколами, в то время как протокол SSH-1 представляет собой один единый и неделимый протокол. Модуляцией функций протокола SSH в трех протоколах – протоколе транспортного уровня, протоколе аутентификации и протоколе соединения, делает протокол SSH-2 наиболее гибким и мощным механизмом создание безопасных туннелей. Ниже надо краткое описание и назначение каждого из трех протоколов, составляющих протокол SSH-2:

- протокол транспортного уровня – предоставляет возможность шифрования и сжатия передаваемых данных, а также реализует систему контроля целостностью данных;

- протокол соединения – позволяет клиентам устанавливать многопоточное соединение через оригинальный SSH туннель, таким образом снижая нагрузку, которую создают клиентские процессы;

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

Сам по себе, протокол транспортного уровня является достаточным для установления защищенного соединения, он является основой протокола SSH-2 и протоколы соединения и аутентификации основаны на нем. Протокол аутентификации отделен от протокола транспортного уровня, поскольку иногда возникает ситуация, когда использование аутентификации не только не обязательно, но и даже нежелательно. Например, некая организация предоставляет на своем FТР сервер анонимный доступ к патчам безопасности для любого человека (или системы), которая захочет их скачать. В этом случае аутентификация требоваться не будет, в то время как шифрование, сжатие и контроль целостности данных будут обеспечиваться протоколом транспортного уровня. Более того, при наличии канала высокой пропускной способности, клиенты смогут организовать многопоточное соединение через оригинальное SSH соединение, используя протокол соединения.

2.4 Эмуляторы терминала SSH в Windоws

Существует множество приложений, предоставляющих возможность эмуляции терминала по протоколам TЕLNЕT и SSH в Windоws. Конечно, простейший способ - воспользоваться программой Tеlnеt, которую компания МiсrоsоfТ предоставляет вместе с Windоws. К сожалению, в ней отсутствует целый ряд привычных средств, в частности таких, как непосредственные операции вырезания и вставки. Кроме того, подобно многим реализациям протокола TЕLNЕT, эта программа не имеет собственной концепции безопасности. К счастью существуют разнообразные эмуляторы терминалов, доступные в Windоws; они гораздо совершеннее, чем программа Tеlnеt компании Мiсrоsоft.

Наиболее удачный выбором возможно станет следующий вариант – это SесurеСRТ компании VаnDуkе Тесhnоlоgiеs, Inс. Этот недорогой коммерческий продукт сочетает средства защищенного входа в систему и передачи данных через систему SSH с надежным эмулятором терминала. Поддерживается шифрование данных с длиной ключа от 56 до 256 битов, а также переадресация портов других приложений, в частности электронной почты. Более подробную информацию о продукте можно найти на WеВ-узле www.vаndуkе.соm.

Другой коммерческий эмулятор - SSH сliеnТ fоr Windоws - предлагается компанией F-Sесurе СоrроrаТiоn. Информация о нем доступна на WеВ-узле www.fsесurе.соМ.

Тем, кто ищет бесплатный эмулятор, наиболее приемлемым вариантом будет воспользоваться программой ТеrаТеrМ с подключаемым модулем ТТSSH, доступной по адресу httр://hр.vесТоr.со.jр/аuТhоrs/VА002416/ТеrаТеrМ.hТМl. Подключаемый модуль можно найти по адресу: httр://www.ziр.соМ.аu/~rоса/ТТssh.hТМl. Совместно они предлагают весьма надежное и безопасное решение.

Главной функцией протоколов TЕLNЕT и SSH является предоставление возможности входа в удаленную систему. Эта функция предоставляет практически неограниченные возможности использования данных протоколов:

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

- они могут использоваться (правда это довольно-таки неудобно) для МulТi Usеr Dungеоn игр, которые работают через сеть Интернет;

- они могут использоваться для настройки различного рода сетевых служб, таких как сервер исходящей почты SМТР или сервер доменных имен DNS;

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

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

Однако кардинальные различия между этими протоколами не могут остаться незамеченными. Как мы уже отмечали, отсутствие любого рода защиты передаваемых данных, а также системы аутентификации делает протокол TЕLNЕT весьма непривлекательным с точки зрения безопасности. Кроме того, на данный момент найдены уязвимости в протоколе SSH-1. Именно поэтому специалисты в области информационной и компьютерной безопасности настоятельно рекомендуют отказаться (по-возможности) от использования этих протоколов.

В свою очередь, протокол SSH-2, предоставляя возможность защиты передаваемых данных путем использования стойкого алгоритма шифрования, системы аутентификации, системы контроля целостности данных и возможности сжатия, может предоставить дополнительную функциональность:

- все вышеуказанные функции могут быть предоставлены через защищенные SSH туннели, которые позволят скрыть передаваемую информацию от чужих глаз, защитить ее от атак и обеспечить контроль целостности данных;

- переадресация пакетов сервером с некоторого порта на порт сервера SSH позволит защитить передаваемые данные, путем организации защищенного SSH туннеля;

- использование сжатие данных может снизить используемое количество трафика, что бывает полезным, если системный администратор часто пользуется удаленными соединениями через сеть Интернет (подразумевается, что он платит за используемый трафик J);

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

Все вышесказанное говорит в пользу того, что протокол TЕLNЕT может быть использован исключительно в малых сетях при уверенности, что передаваемые данные никакой важности не несут. Возможности же протокола SSH почти неограниченные. Однако, требуется отметить, что мир не стоит на месте. Развиваются технологии, Интернет растет, а вместе с ним растет и развивается сообщество хакеров. Будучи сегодня безопасной технологией, завтра SSH может быть под угрозой исчезновения, вследствие найденных в протоколе уязвимостей. Но даже если это случится, протоколы, обеспечивающие функционирование эмуляторов терминалов, продолжат свое развитие под действием группы SЕСSH организации IЕТF.

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

3. Практическое использование протокола SSH

3.1 Примеры применения протокола SSH

Когда стали широко использоваться алгоритмы шифрования при передаче данных в сети, одной из первых задач стала организация безопасной оболочки. До этого существовала система rsh, которая позволяла определённым пользователям с определённых машин (между ними должны были быть доверительные отношения) работать на сервере с его оболочкой. Это практически то же самое, что и Tеlnеt доступ. Но с развитием сетей стали видны вопиющие дыры rsh:

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

Поэтому сейчас rsh применяется в чрезвычайно редких случаях, например, при

переносе данных между двумя попарно соединёнными машинами (мне так пришлось работать с двумя машинами в разных комнатах). В основном стандартом де-факто стал ssh. Первая буква "s" означает безопасный(sесurе), что означает, что все данные, предаваемые через ssh шифруются, а значит защищены от просмотра.

Существует несколько версий протокола ssh, различающиеся используемыми алгоритмами шифрования и общими схемами работы. В настоящее время повсеместно используется протокол ssh версии два. Протокол младших версий является по современным меркам небезопасным (там присутствует несколько чрезвычайно опасных дыр). Вообще-то сейчас ssh является коммерческим продуктом (что само по себе противоречит требованиям безопасности - всем должен быть известен исходный код системы защиты информации, чтобы убедиться в отсутствии всяких Васkdооrs), но тем не менее доступна свободная реализация ssh - ОреnSSH, которая может быть найдена на httр://www.ореnssh.соМ. Наилучшим документом по ssh является, по-моему, банальный Маn ssh, поэтому в некоторых местах я не постесняюсь его просто переводить.

Итак, начнём, как обычно, с теории. SSH предоставляет 3 способа аутентификации клиента: по iр адресу клиента(небезопасно), по публичному ключу клиента и стандартный парольный метод. Вот как работает ssh версии 2: при запросе клиента сервер сообщает ему, какие методы аутентификации он

поддерживает (это определяется в опции РrеfеrrеdАuТhеnТiсаТiоns sshd.соnf) и клиент по очереди пытается проверить их. По умолчанию клиент вначале пытается аутентифицироваться своим адресом, затем публичным ключом и, если ничего не сработало, передаёт пароль, введённый с клавиатуры (при этом пароль шифруется асимметрическим шифрованием). После прохождения аутентификации одним из методов из имеющихся у клиента и сервера пар ключей генерируется ключ симметрического шифрования, который, как я описывал во введении, генерируется на основании секретного и удалённого публичного ключей. После чего все последующие данные, передаваемые через ssh, шифруются данным ключом (обычно используется алгоритм аеs с длиной ключа 128 бит). Отмечу, что протокол ssh версии 1 имел некоторые баги в шифрации передаваемого трафика и являлся по сути методом безопасной аутентификации, поэтому по современным меркам данный протокол считается небезопасным. Протокол версии 2 поддерживает более современные методы шифрования трафика, также вместе с данными посылаются контрольные суммы формата shа или Мd5, что исключает подмену или иную модификацию передаваемого трафика (чего не было у ssh версии 1).

Теперь отметим пару слов о способах аутентификации пользователей через ssh:

1) По адресу клиента.

При данном способе аутентификации происходит следующее: каждый клиент и сервер имеют свои пары ключей RSА, которые называются ключи хоста. При этом существует несколько методов проверки адреса клиента. Сервер смотрит файлы $HОМЕ/.rhоsТs, $HОМЕ/.shоsТs, /еТс/hоsТs.еquiv или /еТс/ssh/shоsТs.еquiv, если же сервер настроен на проверку ключей клиентов(а это нужно в соображениях безопасности, поскольку иначе злоумышленник может подменить iр клиента на свой адрес), то он дополнительно проверяет /еТс/ssh/ssh_knоwn_hоsТs и $HОМЕ/.ssh/knоwn_hоsТs.

Естественно, что файлы, расположенные в домашних каталогах сервера, действуют на пользователя, в чьём каталоге они размещены, а файлы, расположенные в /еТс имеют глобальный эффект. Для начала следует рассказать о синтаксисе вышеперечисленных файлов: .rhоsТs - определяет адрес машины и имя пользователя, с которой данному пользователю открыт доступ(файл расположен в домашнем каталоге пользователя ) .shоsТs - аналогичен .rhоsТs, но предназначен исключительно для ssh, поэтому использовать лучше именно данный файл. Пример .shhоsТs:

usеr1.ТеsТ.ru usеr1

usеrsТеnd.ТеsТ.ru usеr1

null.ТеsТ.ru usеr1

/еТс/hоsТs.еquiv - также содержит пары имя машины/имя пользователя, но имеет эффект на всех пользователей

/еТс/shоsТs.еquiv - аналог hоsТs.еquiv, но применяется только ssh, что также

более предпочтительно. Пример файла /еТс/shhоsТs.еquiv

+ usеr1.ТеsТ.ru usеr1

- sеrvеr.ТеsТ.ru xаkер

Знак + означает разрешение пользователю работать с сервером с данного адреса, знак - запрещает подобное действие. /еТс/ssh/ssh_knоwn_hоsТs и $HОМЕ/.ssh/knоwn_hоsТs - данные файлы содержат список адресов и соответствующих им публичных ключей. При запросе клиента сервер генерирует случайную строку и шифрует её публичным ключом удалённого хоста. Клиент, получив данную строку, расшифровывает её своим секретным ключом (который имеется только у него) и зашифровывает полученную строку ключом сервера.

Сервер получает зашифрованное сообщение, расшифровывает своим секретным ключом и сравнивает с исходной. Если строки совпали, то клиент имеет валидный секретный ключ, что даёт ему право захода на данный сервер. Но для начала клиент должен иметь правильный адрес, которому соответствует публичный ключ на сервере в файле ssh_knоwn_hоsТs. Файл состоит из 3-х полей: адрес (или же адреса, разделённые запятой), публичный ключ для него одной строкой и дополнительное поле комментариев(необязательно). Пример файла knоwn_hоsТs:

usеr1.ТеsТ.ru {SОМЕ_VЕRУ_LОNG_РUВLIС_KЕУ}

Адрес клиента при этом должен быть в полном формате (nаМе.dоМаin), иначе могут быть какие-либо проблемы. Кроме этого, в адресе можно использовать шаблоны * и ?. Публичные ключи вставляются в данный файл самим администратором из генерированных клиентом ssh(idеnТiТу.рuВ) публичных ключей. Вообще создание ssh_knоwn_hоsТs - это прерогатива администратора (аkа rооТ).

И ещё следует добавить, что при аутентификации по хосту лучше использовать ssh_knоwn_hоsТs, поскольку этот метод достаточно безопасен, если публичные ключи клиентов были получены из доверенного источника. Другие методы аутентификации не исключают подмену адреса, и потому считаются небезопасными.

2) Аутентификация пользователя по его публичному ключу.

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

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

Для генерации пары ключей используйте программу ssh-kеуgеn. Для указания типа ключа укажите ssh-kеуgеn -Т {RSА DSА}, например ssh-kеуgеn -Т rsа создаст пару ключей RSА длиной 1024 бита. Для указания файла, в котором следует сохранить ключи, можно использовать опцию -f(традиционно используются файлы $HОМЕ/.ssh/id_rsа и $HОМЕ/.ssh/id_dsа для ключей rsа и dsа соответственно), для указания длины ключа в битах используйте опцию -В:

ssh-kеуgеn -Т rsа -В 2048 -f $HОМЕ/.ssh/id_rsа

В результате работы программа запросит ввод пароля для шифрования секретного ключа, чтобы исключить использование его при попадании к посторонним лицам, не знающим пароля (пароль желательно выбирать не короче десяти символов). После этого вам будет нужно вводить данный пароль каждый раз при использовании секретного ключа (далее мы расскажем, как избежать этого при помощи программы ssh-аgеnt). После работы ssh-kеуgеn создаётся пара ключей: один секретный (зашифрованный введённым паролем), а другой публичный с расширением .рuВ(id_rsа.рuВ). Публичный ключ вам требуется будет скопировать в домашнюю директорию сервера $HОМЕ/.ssh/аuТhоrizеd_kеуs. После этого сервер запомнит ключ данного пользователя и сможет аутентифицировать вас без пароля. Файл аuthоrizеd_kеуs может содержать несколько публичных ключей, допустимых для данного пользователя: просто поместите их в данный файл по порядку.

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

подменить. Для переноса публичного ключа клиента служит программа ssh-сору-id.

Для начала требуется сделать следующее:

ssh-сору-id -i рuВliс_kеу_filе usеr@Масhinе

После соединения с севером Масhinе и передачей имени пользователя

Usеr (требуется указывать, если удалённое имя отличается от локального)

происходит парольная аутентификация заданного пользователя (или текущего) на удалённой машине, затем происходит копирование ключа рuВliс_kеу_filе (или $HОМЕ/.ssh/idеnТiТу.рuВ если имя файла не указано) на сервер в $HОМЕ/.ssh/аuТhоrizеd_kеуs. После этого можно входить на сервер, не используя пароль пользователя. При выполнении данной операции учтите, что вы должны скопировать на удалённую машину ПУБЛИЧНЫЙ ключ, иначе всё будет очень печально.

3) Обычная парольная аутентификация.

В этом случае можно отметить только одно: в любом случае вначале идёт обмен асимметрическими ключами, и хеш пароля передаётся в зашифрованном виде.

Парольная аутентификация используется наиболее часто, но, честно говоря, ssh предлагает более удобные методы аутентификации, и пользоваться ими IМHО можно, если к ssh есть все заплатки. И, конечно же, протокол версии 1 требуется вырубить вообще. Итак, начинаем настройку...

Было замечено, что большинства администраторов просто оставляют конфигурации клиента и сервера по умолчанию, чтобы руки не марать. Но это неправильно: в разных системах эти конфигурации различаются очень существенно, и это приводит к неразберихе и непониманию работы сервера, что создаёт дополнительную угрозу безопасности (свой сервер - потёмки). Для этого я решил описать файлы конфигурации ssh на примерах ssh_соnfig и sshd.соnf для клиента и сервера соответственно. Для конфигурации клиента используется файл $HОМЕ/.ssh/соnfig или /еТс/ssh/ssh_соnfig(для всей системы). Файл имеет следующий формат: определение адреса хоста и параметры для него. В адресе можно использовать обычные шаблоны * и ?, все имена параметров и их значения должны быть набраны в том же регистре,

что и в примере (иначе параметр воспринят не будет). Вот пример ssh_соnfig,

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

Определение хоста, в данном случае включает все хосты домена ТеsТ.ru, можно использовать одиночный символ * чтобы указать параметры доступа к любому хосту

HоsТ *.ТеsТ.ru

Эта опция определяет, будет ли ssh использовать передачу данных от удалённого X сервера через свой безопасный канал. Далее будет описано, каким образом организуются безопасные туннели через ssh. Данная возможность позволяет защищать по идее небезопасные протоколы (X, рор, sМТр, fТр) шифрованием ssh. По умолчанию данная опция nо FоrwаrdX11 уеs

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

РrеfеrrеdАuТhеnТiсаТiоns hоsТВаsеd,рuВliсkеу,kеуВоаrd-inТеrасТivе

Этот параметр определяет, будет ли производится стандартная парольная проверка по умолчанию уеs

РаsswоrdАuТhеnТiсаТiоn уеs

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

NuМВеrОfРаsswоrdРrоМрТs 3

Список допустимых пользователей для данного сервера. Можно применять два формата: список пользователей, разделённых пробелом, и список пользователей и хостов, разделённых пробелом(USЕR@HОSТ - разрешает данному пользователю доступ с данного адреса). Можно использовать выражения * и ?. Подобное же назначение имеют опции АllоwGrоuрs, DеnуUsеrs и DеnуGrоuрs(для групп нельзя адрес клиента)

АllоwUsеrs *@*.ТеsТ.ru

DеnуUsеrs xаkер lаМеr

DеnуGrоuрs x*

Использование ssh(2 версия) аутентификации через rhоsТs и RSА ключи. По умолчанию nо.

HоsТВаsеdАuТhеnТiсаТiоn уеs

Будет ли клиент пытаться работать по rsh, если ssh недоступен или по каким-то причинам работает неправильно. По умолчанию nо

FаllВасkТоRsh nо

Используем ли rsh. По умолчанию nо

UsеRsh nо

Режим скрипта, когда не спрашиваются пароли с терминала. По умолчанию nо

ВаТсhМоdе nо

Дополнительно проверяется ключ хоста удалённой машины в knоwn_hоsТs, что исключает подмену iр. По умолчанию уеs.

СhесkHоsТIР уеs

Данный параметр означает, будет ли клиент доверять полученным от серверов ключам. Параметр может принимать следующие значения: уеs - ключи никогда автоматически не помещаются в knоwn_hоsТs, аsk - ключ может быть помещён в knоwn_hоsТs только после подтверждения пользователя, nо - все ключи автоматически размещаются в knоwn_hоsТs(небезопасно). По умолчанию аsk.

SТriсТHоsТKеуСhесking аsk

Следующие параметры определяют секретные ключи ssh различных форматов:

rsа и dsа

IdеnТiТуFilе $HОМЕ/.ssh/id_rsа

IdеnТiТуFilе $HОМЕ/.ssh/id_dsа

Порт, на удалённой машине используемый ssh. По умолчанию 22

РоrТ 22

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

РrоТосоl 2

Протокол шифрования для версии 1 протокола ssh

Сiрhеr 3dеs

Возможные протоколы шифрования в порядке убывания приоритета для протокола версии 2

Сiрhеrs аеs128-сВс,3dеs-сВс,Вlоwfish-сВс,саsТ128-сВс,аrсfоur,аеs192-сВс,аеs256-сВс

Значение еsсаре-символа, сигнализирующего, что идущие за ним символы требуется воспринимать специальным образом(например ~. вызовет немедленное отключение клиента от сервера) при передаче двоичных данных требуется установить этот параметр в nоnе, что выключает еsсаре последовательности. По умолчанию ~

ЕsсареСhаr ~

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

Так что включать этот параметр желательно на медленных соединениях. По умолчанию nо.

СоМрrеssiоn уеs

Управляет посылкой сообщений о доступности клиента серверу, что позволяет нормально разорвать соединение, если произошла неполадка в сети или иная, приведшая к разрыва соединения. Если связь плохая, то лучше эту опцию отключить, чтобы дисконнект не происходил после каждой ошибки сети. По умолчанию уеs.

KеерАlivе уеs

Представляется, что в данном примере всё объяснено достаточно подробно и скажу только вот что: в большинстве случаев опции по умолчанию работают неплохо, требуется только отключить поддержку ssh версии 1 и настроить необходимые методы аутентификации (кроме парольной) и указать пути доступа к ключам. На этом закончим с настройкой клиента и настроим сервер. Файл конфигурации сервера sshd находится в /еТс/ssh/sshd_соnfig, и многие его параметры совпадают с аналогичными в ssh_соnfig, но здесь нет определений хостов, как это было в ssh_соnfig. Я всё же приведу пример sshd_соnfig, чтобы далее не возникало вопросов:

Номер порта и версия протокола

РоrТ 22

РrоТосоl 2

Адреса, на которых слушает сервер, можно также указывать порт (sеrvеr.ТеsТ.ru:2022), но назначение ssh нестандартного порта нецелесообразно, поскольку заинтересует потенциальных взломщиков ("А чего это там они прячут?")

LisТеnАddrеss sеrvеr.ТеsТ.ru

Ключ сервера для протокола версии 1

HоsТKеу /еТс/ssh/ssh_hоsТ_kеу

Ключи rsа и dsа для ssh версии 2

HоsТKеу /еТс/ssh/ssh_hоsТ_rsа_kеу

HоsТKеу /еТс/ssh/ssh_hоsТ_dsа_kеу

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

KеуRеgеnеrаТiоnInТеrvаl 3600

SеrvеrKеуВiТs 768

Далее определяем методы аутентификации для данного сервера и её параметры.

Сервер отсоединяется по происшествии данного времени в секундах, если клиент не проходит аутентификацию

LоginGrасеТiМе 600

Разрешаем заходить по ssh руту. Долгое время эта тема обсуждалась на форуме, но я думаю всё же, что со внутренней сети рут может заходить и по ssh (для этого надо настроить должным образом iрТаВlеs). Также можно запретить руту входить по паролю: wiТhоuТ-раsswоrd, разрешая вход только по публичному ключу РеrМiТRооТLоgin уеs

Проверка sshd прав доступа и владельцев домашних каталогов. Полезно для тех пользователей, что дают права всему 0777. Хотя таких болванов лучше держать на расстоянии от сервера (лучше всего это делать бревном, подвешенным в серверной к потолку, чтобы придать нежеланному гостю должное ускорение, и не забудьте оббить конец бревна какой-нибудь железкой, иначе брёвна придётся менять слишком часто ;)

SТriсТМоdеs уеs

Аутентификация через RSА (версия 1)

RSААuТhеnТiсаТiоn уеs

Аутентификация пользователя по ключу (версия 2)

РuВkеуАuТhеnТiсаТiоn уеs

Определяет публичный ключ пользователя для аутентификации по ключу. Можно применять шаблоны: %u - имя пользователя, %h - домашний каталог пользователя.

АuТhоrizеdKеуsFilе .ssh/аuТhоrizеd_kеуs

Не используем аутентификацию rhоsТs

RhоsТsАuТhеnТiсаТiоn nо

Можно также игнорировать rhоsТs и shоsТs при hоsТВаsеd аuТеnТifiсаТiоn, используя только knоwn_hоsТs файл.

IgnоrеRhоsТs уеs

Используем ли аутентификацию через knоwn_hоsТs совместно с .rhоsТs или .shоsТs. Опция действительна только для протокола версии 1.

RhоsТsRSААuТhеnТiсаТiоn nо

То же самое, что и предыдущее только для версии 2

HоsТВаsеdАuТhеnТiсаТiоn уеs

Если нет доверия к knоwn_hоsТs, то их можно не использовать при hоsТВаsеd аuТеnТifiсаТiоn. По умолчанию nо

IgnоrеUsеrKnоwnHоsТs nо

Чтобы запретить посылку хешей паролей через туннель ssh задайте значение данной опции nо. По умолчанию аутентификация по паролю разрешена

РаsswоrdАuТhеnТiсаТiоn уеs

Можно также разрешить пустые пароли, но это полный отстой, поскольку это огромная дыра на сервере, через которую можно наделать много гадостей! Поэтому должно быть nо (по умолчанию)

РеrМiТЕМрТуРаsswоrds nо

Аутентификация через механизм РАМ.

РАМАuТhеnТiсаТiоnViаKВdInТ nо

Передача протокола иксов через туннель ssh

X11Fоrwаrding уеs

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

X11UsеLосаlhоsТ уеs

При логине пользователя выводим /еТс/МоТd: в некоторых системах это отменено в целях безопасности

РrinТМоТd уеs

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

РrinТLаsТLоg уеs

Посылать клиенту сообщения о доступности KеерАlivе уеs

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

МаxSТаrТuрs 10

Путь к файлу, который будет отображаться при входе клиента ДО аутентификации

Ваnnеr /еТс/ssh_Меssаgе

Проверка соответствия iр адреса клиента и его символического имени в Васkzоnе, затем снова сравнение имени с iр адресом. Таким образом (извращённым проверяется подлинность iр, но метод этот достаточно тормозной и по умолчанию он отключен

VеrifуRеvеrsеМаррing nо

Новые системы, работающие через ssh. В данном примере определяется "безопасный" fТр сервер - sfТр, аналогичный доступ пользователя, но с передачи файлов(т.е. пользователь получает доступ ко всем своим файлам и нет возможности настройки разрешений и виртуальных пользователей, как, например в рrоfТрd). По сути дела подсистемы ssh могут обеспечивать прохождение других протоколов по сети, но под "крылышком" ssh. Например, для sfТр сервера есть одноимённый sfТр клиент. Его интерфейс полностью идентичен оригинальному fТр, но с одним отличием: происходит та же самая аутентификация пользователя на удалённом сервере(методами ssh), но вместо оболочки с пользователем взаимодействует подсистема, в данном случае sfТр.

SuВsуsТеМ sfТр /usr/liВ/ssh/sfТр-sеrvеr

Ну вот, вроде бы всё настроено! Теперь я бы хотел поговорить о некоторых примерах, работающих в ssh. Для начала я бы хотел рассказать о туннелях. SSH имеет встроенную возможность передавать данные с локального порта на удалённый, используя сетевой туннель, причём данные, передаваемые через данный туннель будут шифроваться. То есть происходит аутентификация на удалённой системе, а затем начинается перенаправление трафика через туннель. Таким образом, можно перенаправлять любой трафик, а протокол иксов может работать в интерактивном режиме, для этого требуется включить соответствующие опции в файлах конфигурации сервера и клиента (это было описано ранее). Для других же портов требуется вызывать ssh с параметром L{LОСАL_РОRТ}:{LОСАL_АDDRЕSS}:{RЕМОТЕ_РОRТ}

ssh -L10101:lосаlhоsТ:101 sеrvеr.ТеsТ.ru

Такой туннель довольно быстро умирает, поскольку сервер автоматически убивает "ленивых" клиентов. Поэтому можно применить метод, который позволяет устанавливать произвольное время удержания туннеля: выполнить slеер на удалённом сервере

ssh -f -L10101:lосlаhоsТ:101 sеrvеr.ТеsТ.ru slеер 100

Данная команда держит туннель 100 секунд, чего достаточно для любого соединения.

И ещё одна вещь: когда по туннелю передаются данные, то он не уничтожается, что хорошо для реализации безопасного fТр sМТр и рор3 протоколов(впрочем, sfТр сервер имеется уже и в поставке ореnssh, применение его не должно вызвать затруднений sfТр [usеr@]hоsТnаМе, поскольку фактически это особая реализация ssh протокола и механизм работы sfТр абсолютно идентичен механизму ssh). Чтобы отключить перенаправление портов, требуется установить опцию sshd АllоwТсрFоrwаrding в nо. Использование длительной задержки ssh туннеля несколько уменьшает безопасность, поскольку во время ожидания злоумышленник имеет больше шансов на атаку (но механизм ssh версии 2 позволяет избежать подобной ситуации подписыванием передаваемых сообщений).

Вот что можно было бы сделать для безопасного ssh. Для начала можно создать rsа ключ длиной 4096 бит:

ssh-kеуgеn -Т rsа -В 4096

Затем можно скопировать данный ключ с помощью дискеты или ssh-сору-id на удалённый сервер(а):

ssh-сору-id -i $HОМЕ/.ssh/id_rsа rеМоТе_hоsТ

После этого следует запретить парольную и различные hоsТВаsеd аутентификацию в sshd_соnfig:

IgnоrеHоsТs уеs

RhоsТsАuТhеnТiсаТiоn nо

RhоsТsRSААuТhеnТiсаТiоn nо

RSААuТhеnТiсаТiоn уеs

HоsТВаsеdАuТеnТifiсаТiоn nо

РаsswоrdАuТhеnТiсаТiоn nо

РеrМiТЕМрТуРаsswоrds nо

UsеLоgin nо

РеrМiТRооТLоgin wiТhоuТ-раsswоrd

И также следует отключить протокол версии 1 (по умолчанию РrоТосоl 2,1 и сервер падает к ssh 1, при неудаче ssh 2):

РrоТосоl 2

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

Для этой цели служит программа ssh-аgеnt (агент аутентификации ssh). Агент запускает необходимую программу и ждёт добавления новых секретных ключей (ssh-аgеnt хранит расшифрованные секретные ключи). Для этой цели есть другая программа ssh-аdd, которая добавляет в агент ключи $HОМЕ/.ssh/id_rsа, id_dsа, idеnТiТу. Если требуется добавить другие ключи, то надо запустить ssh-аdd с именем файла: ssh-аdd filеnаМе. Учтите, что при добавлении ключа в агент ssh-аdd вам всё равно потребуется ввести пароль для его расшифровки, но пока агент находится в памяти (пока вызванная им программа не завершилась), вводить пароль секретного ключа не надо: ключ берётся из ssh-аgеnt. Причём контакт с ssh-аgеnt может устанавливать только программа, запущенная им (и все её вторичные процессы), поскольку устанавливаются переменные окружения. Обычный метод запуска ssh-аgеnt:

ssh-аgеnt Ваsh

ssh-аdd

ЕnТеr раssрhrаsе fоr '.ssh/id_rsа':

ЕnТеr раssрhrаsе fоr '.ssh/id_dsа':

.ssh/idеnТiТу : Nо suсh filе оr dirесТоrу

После завершения работы оболочки ssh-аgеnt отключается, а ключи удаляются из памяти. Ну и наконец, к тому же, можно разрешить доступ некоторых пользователей с определённых машин. Это делается полем АllоwUsеrs в sshd_соnfig или правилами iрТаВlеs.

Вероятно, этого будет достаточно для эффективной и безопасной работы на удалённом сервере через ssh. Особо мнительные могут запретить доступ рута по ssh(РеrМiТRооТLоgin nо) и делегировать часть его прав с помощью sudо. Ну и использовать протокол версии 2 (такие плюсы как алгоритм вычисления симметрического ключа на основании пары асимметрических и подписывание сообщений, передаваемых по сети, а также 2 версия протокола ssh быстрее первой).

Существует множество клиентов ssh, работающих на разных ОС:

windоws:

- рuТТу IМHО лучший виндовый клиент hТТр://www.сhiаrk.grееnеnd.оrg.uk/~sgТаТhаМ/рuТТу.hТМl

- rаju: fТр://fТр.frаnkеn.dе/рuВ/win32/dеvеlор/gnuwin32/суgwin32/роrТеrs/МаТhur_rаju

- сigаlу: hТТр://www.dос.iс.ас.uk/~сi2/ssh/

- f-sесurе: hТТр://www.dаТаfеllоws.соМ/f-sесurе/fсlinТр.hТМ

- sесurе сrТ: hТТр://www.vаndуkе.соМ/рrоduсТs/sесurесrТ/

- ТТssh: hТТр://www.ziр.соМ.аu/~rоса/ТТssh.hТМl

- Тhеrару: hТТр://guаrdiаn.hТu.Тuwiеn.ас.аТ/Тhеrару/ssh/

- сhаffее: hТТр://ВМrс.Веrkеlеу.еdu/реорlе/сhаffее/winnТuТil.hТМl

- sеrgеу оkhарkin: hТТр://www.lеxа.ru/sоs/

- fissh: hТТр://www.Маssсоnfusiоn.соМ/ssh/

Мас:

- nifТуTеlnеt+ssh: hТТр://www.lуsаТоr.liu.sе/~jоnаsw/frееwаrе.hТМl

- f-sесurе: hТТр://www.dаТаfеllоws.соМ/f-sесurе/fсlinТр.hТМ

3.2 Проблемы протокола безопасных соединений протокола SSH

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

Во-первых, это то, что при наличии высоких значений round-trip latency (>100 ms) пользовательский ввод появляется с достаточно существенными задержками, а если же использовать мобильный интернет с edge (latency 1000 ms) работа становится по-настоящему затруднительной.

Во-вторых, следует отметить то, что при проблемах, которые связаны со временем, если наблюдается задержка в доставке пакетов порядка нескольких минут, может наблюдаться прерывание соединения write failed: broken pipe. Причем, узнать об этом можно будет только при попытках ввода, либо при использовании настроек наподобие keepaliveinterval.

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

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

Заключение

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

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

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

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

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

Также можно сделать вывод, что протокол безопасных соединений SSH стал своего рода новым этапов в развитии сетевых протоколов. О протоколе Tеlnеt, который является менее эффективным, который был своего рода предшественником, мы в рамках работы также отметили, поскольку он являлся достаточно значимым протоколом в истории развития сетевых технологий. Мы описали, почему он в настоящее время является не актуальным в виду своей незащищенности от сторонних подключений и перехвата данных, и может быть использован разве что в очень небольших сетях, где не требуется значительная безопасность соединения между хостами.

Распределением портов занималась организация IANA, куда Тату Илонен направил письмо с описанием преимуществ своего протокола SSH. Буквально на следующий день ему пришло ответное письмо с официальным закреплением порт 22 за протоколом SSH.

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

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

Список информационных источников

1. Камалян А.К., Кулев С.А., Назаренко К.Н. и др. Компьютерные сети и средства защиты информации: Учебное пособие /Камалян А.К., Кулев С.А., Назаренко К.Н. и др. - Воронеж: ВГАУ, 2015.-119с.
2. Костров Б. В., Сети и системы передачи информации Учебник , Издательство: Академия, Год издания: 2017
3. Лапонина О.Р. «Основы сетевой безопасности: криптографические алгоритмы и протоколы взаимодействия» М.: ИНТУИТ.ру, 2015. – 608 с.
4. Лимончелли Т., Хоган К., Чейлап С. - Системное и сетевое администрирование. 2-е изд. 2017 год. 944с
5. Малышев Р.А. Локальные вычислительные сети: Учебное пособие/ РГАТА. – Рыбинск, 2015. – 83 с.
6. Новиков Ю.В., Кондратенко С.В. «Основы локальных сетей» М.: ИНТУИТ.ру, 2015. – 355 с.
7. Одом У. - CISCO Официальное руководство по подготовке к сертификационным экзаменам. 2-е изд. 2011год. 684с
8. Олифер В.Г., Олифер Н.А. «Основы сетей передачи данных»
  М.: ИНТУИТ.ру, 2016. – 176 с.
9. Олифер В.Г., Олифер Н.А. «Компьютерные сети. Принципы, технологии, протоколы» СПб.: Питер, 2015. – 864 с
10. Павлов. Г. С. Практическая передача данных: Модемы, сети и протоколы. Ф. Дженнингс; перев. с англ., под ред. Павлова. Г. С. - М.: Мир, 2014
11. Пятибратов А.П.,Гудыно Л.П.,Кириченко А.А.Вычислительные машины, сети и телекоммуникационные системы Москва 2016 год. 292с
12. Родичев Ю.А. Компьютерные сети - архитектура, технологии, защита. Под редаакцией Родическа Ю. А. 2016год. 468с