Тату Улёнен

Содержание
Введение
SSH
Другая активность
Статья SSH — Безопасные подключения для входа в Систему через Интернет

Введение

(фин. Tatu Ylönen; 1968 г. рождения) — изобретатель и разработчик протокола Secure Shell.

Также основатель компании SSH Communications Security Corp, предоставляющей услуги в области информационной безопасности .

В 1992-м он окончил технический университет Хельсинки со степенью магистра наук в области компьютерных наук (ныне Aalto University).

Также основатель компаний Applied Computing Research (ACR) Ltd, Clausal Computing.

SSH

Толчком к разработке SSH стала хакерская атака на финскую университетскую сеть.

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

Этот инцидент побудил разработчика изучать криптографию и изобрести способ безопасного удаленного доступа к серверу через интернет.

Улёнен вместе с единомышленниками разработал Secure Shell для собственного использования и опубликовал исходный код (OpenSSH) в июле 1995 года, но в том же году он основал SSH Communications Security.

В 1996-м году Улёненом была опубликована статья «SSH — Secure Login Connections over the Internet» описывающая новый протокол.

Через несколько лет Sun Microsystems стала клиентом компании, что способствовало распространению протокола.

Тату Иленен увеличил объем продаж компании до 20 миллионов долларов и 190 сотрудников за пять лет, а в 2000 году вывел компанию на публичный листинг на Nasdaq Nordic.

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

Другая активность

Улёнен автор многих стандартов IETF (RFC). Secure Shell на данный момент - один из базовых протоколов интернета.

Тату Улёнен получил награду Finnish Engineering Award в 2000 году.

Для получения дополнительной информации см. его личную страницу .

SSH — Secure Login Connections over the Internet

Примерное содержание статьи SSH — Secure Login Connections over the Internet

SSH — Безопасные подключения для входа в Систему через Интернет
Тату Улёнен
Компания SSH Communications Security Ltd.
Tekniikantie 12, FIN-02150 ЭСПОО, Финляндия
Тел. (международный) +358-0-4354 3205 факс +358-0-4354 3206 SSH обеспечивает безопасный вход в систему, передачу файлов, соединения X11 и TCP/IP по ненадежной сети. Он использует криптографическую аутентификацию, автоматическое шифрование сеанса и защиту целостности передаваемых данных. RSA используется для обмена ключами и аутентификации, а симметричные алгоритмы (например, IDEA или triple-DES с тремя ключами) - для шифрования передаваемых данных.

SSH предназначен для замены существующих протоколов rsh, rlogin, rcp, rdist и telnet. SSH в настоящее время (март 1996 года) используется на тысячах сайтов по меньшей мере в 50 странах. Его пользователями являются ведущие университеты, исследовательские лаборатории, многие крупные корпорации, а также множество небольших компаний и частных лиц.

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

1 Введение

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

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

Угрозы из Интернета включают в себя:

Мониторинг сети: легко записывать пароли, финансовые данные, личные сообщения или корпоративные секреты из сети.

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

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

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

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

Атаки типа «Отказ в обслуживании» : здесь цель состоит в том, чтобы помешать другим пользователям использовать определенную услугу.

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

Текущий протокол IP никоим образом не гарантирует какие-либо аспекты информационной безопасности (например, аутентификацию, конфиденциальность, целостность данных).

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

Если необходима безопасность, она должна быть полностью реализована на уровне приложения.

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

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

Надежное шифрование, по-видимому, является единственным решением для обеспечения сетевой безопасности.

Поскольку несколько крупных правительств продемонстрировали растущий интерес к экономическому шпионажу (включая, например, Соединенные Штаты, Россию, Францию и Японию), коммерческие системы в настоящее время сталкиваются с некоторыми из самых опытных и находчивых противников в мире, и их необходимо разрабатывать с использованием самых сильных возможных методов, чтобы быть полезными.

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

2 Обзор безопасного удаленного входа по SSH

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

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

Значения, возвращаемые такими службами, как DNS или сетевые протоколы (например, TCP/IP [10]), считаются только рекомендательными и проверяются с использованием криптографии.

SSH также автоматически и безопасно пересылает соединения X11 с удаленного компьютера и может быть настроен для пересылки произвольных портов TCP/IP.

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

3 Протокол SSH

SSH использует двоичный протокол на основе пакетов, который работает поверх любого транспорта, который будет передавать поток двоичных данных. Обычно в качестве транспорта используется TCP/IP, но текущая реализация также позволяет использовать произвольную прокси-программу для передачи данных на сервер/с сервера и включает прямую поддержку брандмауэров на основе SOCKS и FWTK.

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

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

Весь пакет шифруется с использованием подходящего алгоритма, такого как IDEA-CFB [2, 9 ], 3DES-CBC [ 9] или эквивалентного алгоритма RC4 [9] (RC4 является торговой маркой RSA Data Security, Inc).

Тип пакета и поля данных могут быть сжаты с помощью алгоритма gzip перед шифрованием. Сжатие уменьшает объем передаваемых данных примерно на треть для типичных интерактивных сеансов.

В настоящее время (март 1996 г.) защита целостности обеспечивается включением CRC32 [1] пакета под шифрованием.

Однако он заменяется HMAC-SHA; см. Раздел 5.

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

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

Протокол SSH работает поверх протокола пакетного уровня и выполняется на следующих этапах:

Клиент открывает соединение с сервером. (Обратите внимание, что злоумышленник может привести к тому, что соединение фактически перейдет на другую машину.)

Сервер отправляет свой открытый ключ хоста RSA и другой открытый ключ RSA (`ключ сервера"), который меняется каждый час. Клиент сравнивает полученный ключ хоста со своей собственной базой данных известных ключей хоста (в будущем он будет проверять ключ хоста с использованием инфраструктуры открытых ключей; однако в настоящее время такой инфраструктуры не существует).

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

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

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

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

На этом этапе серверная машина прошла проверку подлинности, и используются шифрование и защита целостности на транспортном уровне.

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

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

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

Комбинация традиционной аутентификации .rhosts или hosts.equiv и аутентификации хоста на основе RSA.

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

Затем клиент отправляет это значение на сервер; сервер производит соответствующие вычисления и сравнивает значения.

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

Поддержка также включена, например, для карт Security Dynamics SecurID. Добавить новые методы аутентификации очень просто.

После успешной аутентификации начинается подготовительный этап. На этом этапе клиент отправляет запросы, которые подготавливают к фактическому сеансу. Такие запросы включают выделение псевдо-tty, перенаправление X11, перенаправление TCP/IP и т.д. Добавление новых подготовительных операций несложно.

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

Во время интерактивного сеанса обеим сторонам разрешается отправлять пакеты асинхронно. Пакеты могут содержать данные, открытые запросы на соединения X11, перенаправленные порты TCP/IP или агент и т.д. Наконец, в какой-то момент клиент обычно отправляет сообщение EOF. Когда пользовательская оболочка или команда завершает работу, сервер отправляет клиенту свой статус завершения, и клиент подтверждает сообщение и закрывает соединение.

Более подробную информацию о протоколе можно найти в [13].


3.1 X11 и переадресация TCP/IP


SSH может автоматически перенаправлять соединение на X-сервер пользователя по защищенному каналу. Перенаправление выполняется путем создания прокси-сервера X на удаленной машине путем выделения следующего доступного номера порта TCP/IP выше 6001 (они соответствуют номерам отображения X, так что порт, соответствующий отображению n, равен 6000+n).

Затем SSH-сервер прослушивает соединения на этом порту, пересылает запрос на подключение и любые данные по защищенному каналу и устанавливает соединение с реальным X-сервером с помощью SSH-клиента. Переменная ОТОБРАЖЕНИЯ автоматически устанавливается на нужное значение. Обратите внимание, что пересылка может быть последовательной, что позволяет безопасно использовать приложения X по произвольной цепочке SSH-соединений.

SSH также автоматически сохраняет данные Xauthority [8] на сервере.

Фактически, клиент генерирует случайный файл cookie аутентификации MIT-MAGIC-COOKIE-1 и отправляет этот файл cookie на сервер, который его хранит.Xавторитет.

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

Перенаправление TCP/IP работает аналогично: сервер прослушивает сокет на нужном порту, пересылает запрос и данные по защищенному каналу и устанавливает соединение с указанным целевым портом с другой стороны. Для пересылаемых соединений TCP/IP проверка подлинности отсутствует.


3.2 Агент аутентификации


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

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

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

4 Криптографические методы, используемые в SSH

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

Его безопасность основана на криптографических методах.

SSH использует RSA [6, 9] для аутентификации хоста и аутентификации пользователя. Ключи хоста и ключи аутентификации пользователя обычно составляют 1024 бита.

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

Обмен ключами выполняется путем двойного шифрования 256-битного ключа сеанса с использованием RSA. Он дополняется ненулевыми случайными байтами перед каждым шифрованием (в соответствии с PKCS#1 [5]).

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

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

Обмен ключами передает 256 бит ключевых данных на сервер. Различные методы шифрования используют различное количество ключа: IDEA-CFB использует 128 бит, 3DES-CBC 168 бит, RC4 - эквивалент 128 бит в каждом направлении и DES-CBC 56 бит.

Причины использования IDEA в режиме CFB в основном исторические; вместо этого в новом протоколе (раздел 5) будет использоваться IDEA-CBC.

Передаваемые данные в настоящее время защищены от модификации путем вычисления CRC32 всех пакетных данных (включая случайное заполнение) перед шифрованием.

Контрольная сумма и все пакетные данные зашифрованы. Предположительно, злоумышленнику будет трудно изменить текстовые данные таким образом, чтобы контрольная сумма все еще совпадала, не нарушая сначала шифрование. (Механизм обеспечения целостности изменился в новом протоколе; см. Раздел 5.)

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

При первом запуске он использует несколько команд для сбора энтропии из системы (в Unix "ps laxww", `ps -al", `ls -alni/tmp/.", `w", `netstat -s", `netstat -an" и `netstat -in").

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

Дополнительный шум получается из различных системных параметров (например, количество операций ввода-вывода на диске, количество подкачек страниц, количество прерываний, загрузка ЦП) каждый раз, когда пул перемешивается, и если доступен /dev/random, 128 бит шума берутся оттуда каждые несколько минут и перемешиваются в пул.

5 Новый Протокол

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


5.1 Новый Протокол Транспортного Уровня


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

Он выполняет полное согласование алгоритма, обмен ключами и взаимную аутентификацию хоста в общей сложности в 1,5 раза в оба конца, как правило, и в 2,5 раза в худшем случае. Минимальное количество поездок туда и обратно будет становиться все более важным в будущем по мере увеличения пропускной способности сети, но скорость света остается постоянной. Мобильные вычисления, в частности, будут предъявлять высокие требования к количеству поездок туда и обратно; например, по GSM-телефону поездка туда и обратно занимает около секунды.

Было сделано несколько криптографических улучшений. Все данные, которыми обмениваются во время обмена ключами, аутентифицируются. Для защиты целостности данных используется внешнее шифрование HMAC-MD5 или HMAC-SHA. ИДЕЯ теперь используется в режиме CBC. Все данные, включая длину пакета, теперь зашифрованы (кроме MAC). Периодически происходит повторный обмен ключами. Протокол также может взаимодействовать с инфраструктурой открытых ключей.


5.2 Новый протокол SSH


Новый протокол SSH работает по протоколу транспортного уровня, который обеспечивает безопасный канал.

Протокол SSH выполняет аутентификацию пользователя, управление сеансами и подтверждение связи для нескольких одновременных подключений (перенаправленные соединения X11 и т. Д.).

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

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

Новый протокол также поддерживает надлежащее управление потоком для отдельных каналов (например, перенаправленных клиентов X11).

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

6 Текущая Реализация

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

В настоящее время SSH работает практически во всех вариантах Unix, включая, например, AIX, BSD, Convex, DGUX, HPUX, IRIX, Linux , Mach3, OSF/1, SysV, Solaris, SunOS, Ultrix и Unicos.

Коммерческая версия для Windows доступна на сайте Data Fellows, а версия для Macintosh должна появиться осенью 1996 года. Также доступна бесплатная версия OS/2.

Текущая версия Unix поддерживает брандмауэры на основе SOCKS и FWTK и позволяет использовать произвольную прокси-программу для установления соединения.

В большинстве сред его можно установить просто с помощью ./configure make make install

7 Производительность

Производительность SSH можно разделить на два важных параметра: время запуска и скорость передачи.

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

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

В случае SSH это зависит от используемого алгоритма шифрования. На машинах класса 486 скорость составляет 1-2 мегабита в секунду для IDEA, 3-4 мегабита в секунду для DES и около 5 мегабит в секунду для эквивалента RC4.

Скорость почти прямо пропорциональна скорости машин; некоторые более быстрые машины работают на RC4-эквиваленте в программном обеспечении со скоростью, превышающей 40 мегабит в секунду.

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

В большинстве случаев скорость передачи данных ограничивается не шифрованием, а скоростью передачи данных в сети. Кроме того, при междугородних соединениях SSH может быть значительно быстрее, чем telnet или rlogin, из-за сжатия передаваемых данных.

8 Заключение

SSH решает одну из самых острых проблем безопасности в Интернете: безопасный вход с одной машины на другую и безопасная передача файлов между машинами.

Он делает это удобным и полностью прозрачным для пользователей способом. В то же время он автоматизирует передачу соединения X11 и делает использование соединения X11 на большие расстояния безопасным.

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

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

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

Опыт показывает, что нагрузка на процессор, вызванная сильным шифрованием, незначительна. Не нужно пытаться оправдать, зачем шифровать; это почти ничего не стоит.

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

Слабое шифрование просто сделает передаваемые данные доступными для иностранных спецслужб и преступных организаций.

SSH в настоящее время (июнь 1996 года) используется на тысячах или десятках тысяч сайтов по меньшей мере в 50 странах по всему миру.

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

Доступ к страницам SSH WWW осуществляется примерно 1000-2000 раз в день (примерно раз в минуту).

В течение примерно десяти дней (рассмотренных в феврале 1996 года) доступы поступали примерно с 6000 хостов (многие из них прокси-серверы WWW/серверы кэша) в 55 доменах верхнего уровня. Фактическое количество людей, использующих SSH, неизвестно.

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

Его домашняя страница WWW, включая указатели на ftp-сайты и коммерческие версии, доступна по адресу https://www.cs.hut.fi/ssh .

Источники

[1] J. Campbell. C Programmer's Guide to Serial Communications, Sams, 1993.

[2] Lai, X. On the Design and Security of Block Ciphers. ETH Series in Information Processing, vol. 1, Hartung-Gorre Verlag, Konstantz, 1992.

[3] M. Leech, M. Ganis, Y. Lee, R. Kuris, D. Koblas, and L. Jones. SOCKS Protocol Version 5, RFC 1928, 1996.

[4] Mockapetris, P. Domain Names -- Concepts and Facilities, RFC 1034, Internet Engineering Task Force, 1987.

[5] Public Key Cryptography Standards, #1. RSA Laboratories. Available for anonymous ftp at ftp.rsa.com.

[6] Rivest, R., Shamir, A., and Adleman, L. M. A Method for Obtaining Digital Signatures and Public-Key Cryptosystems. Communications of the ACM, vol. 21, no. 2, 1978, pp. 120-126.

[7] Rivest, R. The MD5 Message Digest Algorithm, RFC 1321, Internet Engineering Task Force, 1992.

[8] Scheifler, R. X Window System Protocol. X Consortium Standard, Version 11, Release 6. Laboratory of Computer Science, Massachusetts Institute of Technology, 1994.

[9] Schneier, Bruce. Applied Cryptography, 2nd edition. John Wiley &em; Sons, 1996.

[10] Stevens, W. Richard. TCP/IP Illustrated. Volume 1: The Protocols. Addison-Wesley, 1994.

[11] TIS Firewall Toolkit, Trusted Information Systems Inc., 1993.

[12] Wiener, M. J. Efficient DES Key Search. Technical Report TR-244, School of Computer Science, Carleton University, 1994.

[13] Ylönen, Tatu. The SSH (Secure Shell) Remote Login Protocol , 1996. Available on the Internet from the SSH Home Page at https://www.cs.hut.fi/ssh. Also included in the SSH distribution.

Полезные ссылки

https://www.cs.hut.fi/~ylo/ Tatu Ylonen's home page.

https://www.cs.hut.fi/ssh/ SSH Home Page.

https://www.ssh.fi/ SSH Communications Security Ltd.

https://www.datafellows.com/ Data Fellows Ltd.

This paper was originally published in the proceedings of The Sixth USENIX Security Symposium, July 22–25, 1996, San Jose, California, USA

Last changed: 10 Jan 2003 aw

Похожие статьи
SSH
SSH туннель
Ошибки SSH
Linux
Bash
Настройка сети
sudo
SCP: обмен файлами;
C
C++
Сети
Кибербезопасность
RDP через SSH
Telnet
Make

Поиск по сайту

Подпишитесь на Telegram канал @aofeed чтобы следить за выходом новых статей и обновлением старых

Перейти на канал

@aofeed

Задать вопрос в Телеграм-группе

@aofeedchat

Контакты и сотрудничество:
Рекомендую наш хостинг beget.ru
Пишите на info@urn.su если Вы:
1. Хотите написать статью для нашего сайта или перевести статью на свой родной язык.
2. Хотите разместить на сайте рекламу, подходящую по тематике.
3. Реклама на моём сайте имеет максимальный уровень цензуры. Если Вы увидели рекламный блок недопустимый для просмотра детьми школьного возраста, вызывающий шок или вводящий в заблуждение - пожалуйста свяжитесь с нами по электронной почте
4. Нашли на сайте ошибку, неточности, баг и т.д. ... .......
5. Статьи можно расшарить в соцсетях, нажав на иконку сети: