Безопасная оболочка

редактировать
"SSH" перенаправляется сюда. Чтобы узнать о других значениях, см. SSH (значения).
Безопасная оболочка
Протокол связи
Цель безопасное соединение, удаленный интерфейс командной строки
Разработчики) Тату Юленен, Инженерная группа Интернета (IETF)
Введено 1995 г.
Слой OSI Уровень приложения
Порт (ы) 22
RFC (ы) RFC 4250, RFC 4251, RFC 4252, RFC 4253, RFC 4254

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

SSH обеспечивает безопасный канал в незащищенной сети за счет использования клиент-серверной архитектуры, соединяя клиентское приложение SSH с сервером SSH. В спецификации протокола различаются две основные версии, называемые SSH-1 и SSH-2. Стандартный порт TCP для SSH - 22. SSH обычно используется для доступа к Unix-подобным операционным системам, но его также можно использовать в Microsoft Windows. Windows 10 использует OpenSSH в качестве SSH-клиента и SSH-сервера по умолчанию.

SSH был разработан как замена Telnet и незащищенных протоколов удаленной оболочки, таких как Berkeley rsh и связанные с ними протоколы rlogin и rexec. Эти протоколы отправляют конфиденциальную информацию, в частности пароли, открытым текстом, что делает их уязвимыми для перехвата и раскрытия с помощью анализа пакетов. Шифрования, используемый SSH предназначен для обеспечения конфиденциальности и целостности данных по незащищенной сети, такие как Интернет.

СОДЕРЖАНИЕ
  • 1 Определение
  • 2 Аутентификация: управление ключами OpenSSH
  • 3 Использование
  • 4 История и развитие
    • 4.1 Версия 1.x
    • 4.2 Версия 2.x
    • 4.3 Версия 1.99
    • 4.4 OpenSSH и OSSH
  • 5 применений
    • 5.1 Протоколы передачи файлов
  • 6 Архитектура
  • 7 алгоритмов
  • 8 Уязвимости
    • 8.1 SSH-1
    • 8.2 Восстановление открытого текста CBC
    • 8.3 Возможные уязвимости
  • 9 Документация по стандартам
  • 10 См. Также
  • 11 Источники
  • 12 Дальнейшее чтение
  • 13 Внешние ссылки
Определение

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

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

Аутентификация: управление ключами OpenSSH

В Unix-подобных системах список авторизованных открытых ключей обычно хранится в домашнем каталоге пользователя, которому разрешен удаленный вход, в файле ~ /.ssh / authorized_keys. Этот файл используется SSH только в том случае, если он не доступен для записи никому, кроме владельца и root. Когда открытый ключ присутствует на удаленном конце, а соответствующий закрытый ключ присутствует на локальном конце, ввод пароля больше не требуется. Однако для дополнительной безопасности сам закрытый ключ может быть заблокирован парольной фразой.

Закрытый ключ также можно искать в стандартных местах, а полный путь к нему можно указать в параметрах командной строки (параметр -i для ssh). SSH-серийник утилита производит открытые и закрытые ключи, всегда парами.

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

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

SSH обычно используется для входа на удаленный компьютер и выполнения команд, но он также поддерживает туннелирование, пересылку портов TCP и соединений X11 ; он может передавать файлы, используя соответствующие протоколы передачи файлов SSH (SFTP) или безопасного копирования (SCP). SSH использует модель клиент-сервер.

Клиентская программа SSH обычно используется для установления подключений к демону SSH , принимающему удаленные подключения. Оба обычно присутствуют в большинстве современных операционных систем, включая macOS, большинство дистрибутивов Linux, OpenBSD, FreeBSD, NetBSD, Solaris и OpenVMS. Примечательно, что версии Windows до Windows 10 версии 1709 по умолчанию не включают SSH. Существуют проприетарные, бесплатные программы и версии с открытым исходным кодом (например, PuTTY и версия OpenSSH, которая является частью Cygwin ) различных уровней сложности и полноты. Файловые менеджеры для UNIX-подобных систем (например, Konqueror ) могут использовать протокол FISH для предоставления графического интерфейса с разделенной панелью с перетаскиванием. Программа WinSCP для Windows с открытым исходным кодом предоставляет аналогичные возможности управления файлами (синхронизация, копирование, удаленное удаление) с использованием PuTTY в качестве серверной части. И WinSCP, и PuTTY доступны в упаковке для запуска непосредственно с USB-накопителя, без необходимости установки на клиентском компьютере. Настройка SSH-сервера в Windows обычно включает включение функции в приложении «Настройки». В Windows 10 версии 1709 доступен официальный порт OpenSSH для Win32.

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

IANA присвоила TCP - порт 22, UDP порт 22 и SCTP порт 22 для этого протокола. IANA перечислила стандартный TCP-порт 22 для серверов SSH как один из хорошо известных портов еще в 2001 году. SSH также может быть запущен с использованием SCTP, а не TCP, в качестве протокола транспортного уровня, ориентированного на соединение.

История и развитие

Версия 1.x

В 1995 году Тату Юленен, исследователь из Хельсинкского технологического университета, Финляндия, разработал первую версию протокола (теперь называемого SSH-1), инициированную атакой по перехвату пароля в его университетской сети. Целью SSH было заменить более ранние протоколы rlogin, TELNET, FTP и rsh, которые не обеспечивали строгую аутентификацию и не гарантировали конфиденциальность. Ylönen выпустил свою реализацию как бесплатное ПО в июле 1995 года, и инструмент быстро завоевал популярность. К концу 1995 года база пользователей SSH выросла до 20 000 пользователей в пятидесяти странах.

В декабре 1995 года Илонен основал SSH Communications Security для продвижения и разработки SSH. Первоначальная версия программного обеспечения SSH использовала различные части бесплатного программного обеспечения, такие как GNU libgmp, но более поздние версии, выпущенные SSH Communications Security, превратились во все более проприетарное программное обеспечение.

Было подсчитано, что к 2000 году количество пользователей выросло до 2 миллионов.

Версия 2.x

«Secsh» было официальным интернет - Engineering Task Force имя (IETF) для рабочей группы IETF, ответственной за версию 2 протокола SSH. В 2006 году обновленная версия протокола SSH-2 была принята в качестве стандарта. Эта версия несовместима с SSH-1. SSH-2 отличается как безопасностью, так и улучшенными функциями по сравнению с SSH-1. Например, лучшая безопасность достигается за счет обмена ключами Диффи – Хеллмана и строгой проверки целостности с помощью кодов аутентификации сообщений. Новые функции SSH-2 включают возможность запускать любое количество сеансов оболочки через одно соединение SSH. Из-за превосходства и популярности SSH-2 над SSH-1 некоторые реализации, такие как libssh (v0.8.0 +), Lsh и Dropbear, поддерживают только протокол SSH-2.

Версия 1.99

В январе 2006 года, намного позже, чем была создана версия 2.1, RFC 4253 определил, что сервер SSH, который поддерживает как 2.0, так и предыдущие версии SSH, должен идентифицировать свою прототипную версию как 1.99. Это не актуальная версия, а метод определения обратной совместимости.

OpenSSH и OSSH

В 1999 году разработчики, желая, чтобы была доступна бесплатная версия программного обеспечения, вернулись к старому выпуску 1.2.12 исходной программы SSH, который был последним выпущенным под лицензией с открытым исходным кодом. OSSH Бьорна Грёнвалля был впоследствии разработан на основе этой кодовой базы. Вскоре после этого, OpenBSD разработчиков раздвоенного кода Grönvall и сделали большую работу на нем, создавая OpenSSH, который поставляется с выпуском OpenBSD 2.6. Начиная с этой версии была сформирована ветвь «переносимости» для переноса OpenSSH на другие операционные системы.

По состоянию на 2005 год OpenSSH был единственной самой популярной реализацией SSH, входящей по умолчанию в большое количество операционных систем. OSSH тем временем устарел. OpenSSH продолжает поддерживаться и поддерживает протокол SSH-2, исключив поддержку SSH-1 из кодовой базы с выпуском OpenSSH 7.6.

Использует
Пример туннелирования приложения X11 через SSH: у пользователя josh есть SSHed с локальной машины foofighter на удаленную машину tengwar для запуска xeyes. Вход в OpenWrt через SSH с помощью PuTTY, работающего в Windows.

SSH - это протокол, который можно использовать для многих приложений на многих платформах, включая большинство вариантов Unix ( Linux, BSD, включая MacOS от Apple и Solaris ), а также Microsoft Windows. Некоторым из перечисленных ниже приложений могут потребоваться функции, которые доступны или совместимы только с определенными клиентами или серверами SSH. Например, использование протокола SSH для реализации VPN возможно, но в настоящее время только с сервером OpenSSH и реализацией клиента.

  • Для входа в оболочку на удаленном хосте (заменяет Telnet и rlogin )
  • Для выполнения одной команды на удаленном хосте (замена rsh )
  • Для настройки автоматического (беспарольного) входа на удаленный сервер (например, с помощью OpenSSH )
  • В сочетании с rsync для эффективного и безопасного резервного копирования, копирования и зеркалирования файлов
  • Для переадресации порта
  • Для туннелирования (не путать с VPN, которая маршрутизирует пакеты между разными сетями или соединяет два широковещательных домена в один).
  • Для использования в качестве полноценного зашифрованного VPN. Обратите внимание, что только сервер и клиент OpenSSH поддерживают эту функцию.
  • Для пересылки X с удаленного хоста (возможно через несколько промежуточных хостов)
  • Для просмотра веб-страниц через зашифрованное прокси-соединение с клиентами SSH, которые поддерживают протокол SOCKS.
  • Для безопасного монтирования каталога на удаленном сервере в качестве файловой системы на локальном компьютере с использованием SSHFS.
  • Для автоматического удаленного мониторинга и управления серверами с помощью одного или нескольких механизмов, описанных выше.
  • Для разработки на мобильных или встроенных устройствах, поддерживающих SSH.
  • Для защиты протоколов передачи файлов.

Протоколы передачи файлов

Протоколы Secure Shell используются в нескольких механизмах передачи файлов.

Архитектура
Схема бинарного пакета SSH-2.

Протокол SSH-2 имеет внутреннюю архитектуру (определенную в RFC 4251) с хорошо разделенными уровнями, а именно:

  • Транспортный слой (RFC 4253), который обычно работает поверх TCP / IP. Этот уровень обрабатывает начальный обмен ключами, а также аутентификацию сервера и устанавливает шифрование, сжатие и проверку целостности. Он предоставляет верхнему уровню интерфейс для отправки и получения пакетов с открытым текстом размером до 32 768 байт каждый (реализация может позволить больше). Транспортный уровень также организует повторный обмен ключами, обычно после передачи 1 ГБ данных или по прошествии 1 часа, в зависимости от того, что произойдет раньше.
  • Уровень аутентификации пользователя (RFC 4252). Этот уровень обрабатывает аутентификацию клиента и предоставляет ряд методов аутентификации. Аутентификация управляется клиентом: когда пользователю предлагается ввести пароль, это может быть запрос клиента SSH, а не сервера. Сервер просто отвечает на запросы аутентификации клиента. К широко используемым методам аутентификации пользователей относятся следующие:
    • пароль: метод прямой аутентификации по паролю, включая возможность изменения пароля. Не все программы реализуют этот метод.
    • publickey: метод аутентификации на основе открытого ключа, обычно поддерживающий пары ключей DSA, ECDSA или RSA, а другие реализации также поддерживают сертификаты X.509.
    • keyboard-interactive (RFC 4256): универсальный метод, при котором сервер отправляет одно или несколько приглашений для ввода информации, а клиент отображает их и отправляет обратно ответы, введенные пользователем. Используется для обеспечения аутентификации с одноразовым паролем, например S / Key или SecurID. Используется некоторыми конфигурациями OpenSSH, когда PAM является базовым провайдером аутентификации хоста, чтобы эффективно обеспечивать аутентификацию по паролю, что иногда приводит к невозможности входа в систему с клиентом, который поддерживает только простой метод аутентификации по паролю.
    • Методы аутентификации GSSAPI, которые обеспечивают расширяемую схему для выполнения аутентификации SSH с использованием внешних механизмов, таких как Kerberos 5 или NTLM, обеспечивая возможность единой регистрации для сеансов SSH. Эти методы обычно реализуются коммерческими реализациями SSH для использования в организациях, хотя OpenSSH действительно имеет рабочую реализацию GSSAPI.
  • Уровень подключения (RFC 4254). Этот уровень определяет концепцию каналов, запросов каналов и глобальных запросов, с помощью которых предоставляются услуги SSH. Одно соединение SSH может одновременно обслуживать несколько каналов, каждый из которых передает данные в обоих направлениях. Канальные запросы используются для ретрансляции внеполосных данных, зависящих от канала, таких как измененный размер окна терминала или код выхода серверного процесса. Кроме того, каждый канал выполняет собственное управление потоком, используя размер окна приема. Клиент SSH запрашивает переадресацию порта на стороне сервера с помощью глобального запроса. Стандартные типы каналов включают:
    • оболочка для терминальных оболочек, запросов SFTP и exec (включая передачи SCP)
    • Direct-tcpip для перенаправленных соединений клиент-сервер
    • forwarded-tcpip для перенаправленных соединений от сервера к клиенту
  • Запись SSHFP DNS (RFC 4255) предоставляет отпечатки ключей открытого хоста, чтобы помочь в проверке подлинности хоста.

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

Несмотря на распространенное заблуждение, SSH не является реализацией Telnet с криптографией, обеспечиваемой Secure Sockets Layer (SSL).

Алгоритмы
Уязвимости

СШ-1

В 1998 году в SSH 1.5 была описана уязвимость, которая позволяла несанкционированно вставлять контент в зашифрованный поток SSH из-за недостаточной защиты целостности данных от CRC-32, используемого в этой версии протокола. Исправление, известное как SSH Compensation Attack Detector, было введено в большинство реализаций. Многие из этих обновленных реализаций содержали новую уязвимость целочисленного переполнения, которая позволяла злоумышленникам выполнять произвольный код с привилегиями демона SSH, обычно с правами root.

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

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

Восстановление открытого текста CBC

В ноябре 2008 года была обнаружена теоретическая уязвимость для всех версий SSH, которая позволяла восстанавливать до 32 бит открытого текста из блока зашифрованного текста, который был зашифрован с использованием стандартного режима шифрования по умолчанию, CBC. Наиболее простое решение - использовать CTR, режим счетчика, вместо режима CBC, поскольку это делает SSH устойчивым к атаке.

Возможные уязвимости

28 декабря 2014 года Der Spiegel опубликовал секретную информацию, просочившуюся разоблачителем Эдвардом Сноуденом, из которой следует, что Агентство национальной безопасности может расшифровать некоторый трафик SSH. Технические детали, связанные с таким процессом, не разглашаются. Проведенный в 2017 году анализ хакерских инструментов ЦРУ BothanSpy и Gyrfalcon показал, что сам протокол SSH не был взломан.

Документация по стандартам

В следующих публикациях RFC рабочей группы IETF "secsh" SSH-2 задокументирован как предлагаемый стандарт Интернета.

  • RFC   4250 - Номера, присвоенные протоколу Secure Shell (SSH)
  • RFC   4251 - Архитектура протокола Secure Shell (SSH)
  • RFC   4252 - Протокол аутентификации Secure Shell (SSH)
  • RFC   4253 - Протокол транспортного уровня Secure Shell (SSH)
  • RFC   4254 - протокол подключения Secure Shell (SSH)
  • RFC   4255 - Использование DNS для безопасной публикации отпечатков ключей Secure Shell (SSH)
  • RFC   4256 - Общая аутентификация обмена сообщениями для протокола Secure Shell (SSH)
  • RFC   4335 - Расширение разрыва канала сеанса Secure Shell (SSH)
  • RFC   4344 - Режимы шифрования транспортного уровня Secure Shell (SSH)
  • RFC   4345 - Улучшенные режимы Arcfour для протокола транспортного уровня Secure Shell (SSH)

Позже он был изменен и расширен следующими публикациями.

  • RFC   4419 - Групповой обмен Диффи-Хеллмана для протокола транспортного уровня Secure Shell (SSH) (март 2006 г.)
  • RFC   4432 - Обмен ключами RSA для протокола транспортного уровня Secure Shell (SSH) (март 2006 г.)
  • RFC   4462 - Generic Security Service Application Program Interface (GSS-API) Аутентификация и обмен ключами для протокола Secure Shell (SSH) (май 2006 г.)
  • RFC   4716 - Формат файла открытого ключа Secure Shell (SSH) (ноябрь 2006 г.)
  • RFC   4819 - Подсистема открытых ключей Secure Shell (март 2007 г.)
  • RFC   5647 - режим счетчика Галуа AES для протокола транспортного уровня Secure Shell (август 2009 г.)
  • RFC   5656 - Интеграция алгоритма эллиптической кривой на транспортном уровне Secure Shell (декабрь 2009 г.)
  • RFC   6187 - Сертификаты X.509v3 для аутентификации Secure Shell (март 2011 г.)
  • RFC   6239 - криптографические наборы Suite B для Secure Shell (SSH) (май 2011 г.)
  • RFC   6594 - Использование алгоритма SHA-256 с RSA, алгоритмом цифровой подписи (DSA) и DSA эллиптической кривой (ECDSA) в записях ресурсов SSHFP (апрель 2012 г.)
  • RFC   6668 - Проверка целостности данных SHA-2 для протокола транспортного уровня Secure Shell (SSH) (июль 2012 г.)
  • RFC   7479 - Ed25519 Записи ресурсов SSHFP (март 2015 г.)
  • RFC   5592 - Транспортная модель безопасной оболочки для простого протокола управления сетью (SNMP) (июнь 2009 г.)
  • RFC   6242 - Использование протокола NETCONF через Secure Shell (SSH) (июнь 2011 г.)
  • draft-gerhards-syslog-transport-ssh-00 - отображение транспорта SSH для SYSLOG (июль 2006 г.)
  • draft-ietf-secsh-filexfer-13 - протокол передачи файлов SSH (июль 2006 г.)

Кроме того, проект OpenSSH включает в себя несколько спецификаций / расширений протоколов поставщиков:

Смотрите также
использованная литература
дальнейшее чтение
внешние ссылки
Последняя правка сделана 2023-04-05 04:21:55
Содержание доступно по лицензии CC BY-SA 3.0 (если не указано иное).
Обратная связь: support@alphapedia.ru
Соглашение
О проекте