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

«SSH» перенаправляется сюда. Чтобы узнать о других значениях, см. SSH (значения) .

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

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

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

SSH был разработан для Unix-подобных операционных систем в качестве замены Telnet и незащищенных протоколов удаленной оболочки Unix , таких как Berkeley Remote Shell (rsh) и связанных с ним протоколов rlogin и rexec , которые используют небезопасные в виде открытого текста методы аутентификации , такие как пароли. .

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

SSH был впервые разработан в 1995 году финским учёным-компьютерщиком Тату Юлёненом (для замены сетевого протокола Telnet). Последующая разработка набора протоколов продолжалась в нескольких группах разработчиков, создав несколько вариантов реализации. В спецификации протокола различаются две основные версии, называемые SSH-1 и SSH-2. Наиболее часто реализуемым программным стеком является OpenSSH как программное обеспечение с открытым исходным кодом , выпущенный в 1999 году разработчиками OpenBSD . Реализации распространяются для всех типов общеупотребительных операционных систем, включая встроенные системы.

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

Определение

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

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

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

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

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

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

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

Использовать

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

SSH использует модель клиент-сервер . программа SSH Клиентская обычно используется для установления соединений с демоном SSH , например sshd, принимая удаленные соединения. Оба обычно присутствуют в большинстве современных операционных систем , включая macOS , большинстве дистрибутивов Linux , OpenBSD , FreeBSD , NetBSD , Solaris и OpenVMS . Примечательно, что версии Windows до Windows 10 версии 1709 по умолчанию не включают SSH, но проприетарные , бесплатные и открытые версии различных уровней сложности и полноты существовали и существуют (см. Сравнение SSH-клиентов ). В 2018 году Microsoft начала портировать исходный код OpenSSH на Windows. а в Windows 10 версии 1709 теперь доступен официальный порт OpenSSH для Win32.

Файловые менеджеры для UNIX-подобных систем (например, Konqueror ) могут использовать протокол FISH для предоставления графического интерфейса с разделенной панелью и возможностью перетаскивания. Программа Windows с открытым исходным кодом WinSCP. предоставляет аналогичные возможности управления файлами (синхронизация, копирование, удаленное удаление) с использованием PuTTY в качестве серверной части. Оба WinSCP и PuTTY доступны в упаковке для запуска непосредственно с USB-накопителя, не требуя установки на клиентский компьютер. Расширение защищенной оболочки браузера Chrome также позволяет подключаться по SSH без установки программного обеспечения и даже позволяет использовать SSH с компьютера Chromebook . Настройка SSH-сервера в Windows обычно включает в себя включение функции в приложении «Настройки».

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

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

Историческое развитие

Версия 1

В 1995 году Тату Юленен , исследователь из Хельсинкского технологического университета в Финляндии, разработал первую версию протокола (теперь называемого SSH-1 ), вызванную атакой с перехватом пароля в его университетской сети . Целью SSH была замена более ранних rlogin , TELNET , FTP. и протоколы rsh , которые не обеспечивали надежную аутентификацию и не гарантировали конфиденциальность. Он выбрал порт номер 22, потому что он находится между telnet (порт 23) и ftp (порт 21).

Юленен выпустил свою реализацию как бесплатное ПО в июле 1995 года, и инструмент быстро завоевал популярность. К концу 1995 года база пользователей SSH выросла до 20 000 пользователей в пятидесяти странах.

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

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

Версия 2

В 2006 году, после обсуждения в рабочей группе «секш», пересмотренная версия протокола SSH, SSH-2, была принята в качестве стандарта. Эта версия предлагает улучшенную безопасность и новые функции, но несовместима с SSH-1. Например, он вводит новые механизмы обмена ключами, такие как обмен ключами Диффи-Хеллмана , улучшенную целостности данных проверку с помощью кодов аутентификации сообщений , таких как MD5 или SHA-1 , которые могут быть согласованы между клиентом и сервером. SSH-2 также добавляет более надежные методы шифрования, такие как AES , которые в конечном итоге заменили более слабые и скомпрометированные шифры из предыдущего стандарта, такие как 3-des . Новые функции SSH-2 включают возможность запуска любого количества сеансов оболочки через одно соединение SSH. Из-за превосходства и популярности SSH-2 над SSH-1 некоторые реализации, такие как libssh (v0.8.0+), Лш и Дропбер в конечном итоге поддерживал только протокол SSH-2.

Версия 1.99

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

ОпенСШ и ОСШ

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

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

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

Пример туннелирования приложения X11 через SSH: пользователь «josh» подключился по SSH с локального компьютера «foofighter» на удаленный компьютер «tengwar» для запуска xeyes .

Вход в OpenWrt через SSH с использованием PuTTY , работающего в Windows .

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

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

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

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

• Безопасное копирование (SCP), которое произошло от протокола RCP поверх SSH.
• rsync , который должен быть более эффективным, чем SCP. Обычно работает через SSH-соединение.
• Протокол передачи файлов SSH (SFTP), безопасная альтернатива FTP (не путать с FTP через SSH или FTPS ).
• Файлы, передаваемые по протоколу оболочки (FISH), выпущенному в 1998 году и развившемуся из команд оболочки Unix через SSH.
• Протокол Fast and Secure Protocol (FASP), он же Aspera , использует SSH для управления и порты UDP для передачи данных.

Архитектура

Схема двоичного пакета SSH-2.

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

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

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

Алгоритмы

• ЭдДСА , ECDSA , RSA и DSA для криптографии с открытым ключом .
• ECDH и Диффи-Хеллмана для обмена ключами .
• HMAC , AEAD и UMAC для MAC .
• AES (и устаревшие RC4 , 3DES , DES ) для симметричного шифрования .
• AES-GCM и ChaCha20-Poly1305 для шифрования AEAD .
• SHA (и устаревший MD5 ) для отпечатка ключа .

Уязвимости

СШ-1

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

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

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

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

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

Предполагаемая расшифровка со стороны АНБ

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

Атака черепахи

Основная статья: Атака черепах

В 2023 году была обнаружена новая атака «человек посередине» против большинства современных реализаций ssh. атакой Terrapin . Первооткрыватели назвали ее Однако риск снижается за счет требования перехвата подлинного сеанса ssh и того, что атака ограничена по объему, что случайно приводит в основном к неудачным соединениям. Разработчики ssh заявили, что основным результатом атаки является ухудшение время нажатия клавиш . функций ssh, запутывающих Уязвимость была исправлена ​​в OpenSSH 9.6, но для полной эффективности исправления требуется обновление как клиента, так и сервера.

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

Следующие 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 - Аутентификация и обмен ключами общего программного интерфейса службы безопасности (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 г.)
• RFC   8332 – Использование ключей RSA с SHA-256 и SHA-512 в протоколе Secure Shell (SSH) (март 2018 г.)
• Draft-gerhards-syslog-transport-ssh-00 — отображение транспорта SSH для SYSLOG (июль 2006 г.)
• Draft-ietf-secsh-filexfer-13 — протокол передачи файлов SSH (июль 2006 г.)

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

• Обзор ПРОТОКОЛА OpenSSH
• Обзор сертификата/ключа OpenSSH
• Draft-miller-ssh-agent-04 — Протокол агента SSH (декабрь 2019 г.)

См. также

• Атака грубой силой
• Сравнение SSH-клиентов
• Сравнение SSH-серверов
• Штопор
• Идентификатор
• OpenSSH
• Безопасное туннелирование Shell
• Интернет-SSH

Дальнейшее чтение

• Барретт, Дэниел Дж .; Сильверман, Ричард Э.; Бирнс, Роберт Г. (2005). SSH: Secure Shell (Полное руководство) (2-е изд.). О'Рейли. ISBN  0-596-00895-3 .
• Станке, Майкл (2005). Согласно OpenSSH . Апресс. ISBN  1-59059-476-2 .
• Тату Юленен (12 июля 1995 г.). «Объявление: программа удаленного входа в систему Ssh (Secure Shell)» . комп.security.unix. Оригинальный анонс Ssh
• Двиведи, Химаншу (2003). Реализация SSH . Уайли. ISBN  978-0-471-45880-7 .

Внешние ссылки

• SSH-протоколы
• М. Джозеф; Дж. Сусой (ноябрь 2013 г.). Подсистема открытых ключей Secure Shell P6R . дои : 10.17487/RFC7076 . РФК 7076 .
• Исходный архив исходного кода SSH