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

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

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

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

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

разработан для UNIX-подобных замены для Telnet и необеспеченных удаленного Unix Shell таких как удаленная оболочка Berkele систем SSH был протоколов , в качестве операционных Полем

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

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

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

Определение

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

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

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

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

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

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

Частный ключ также можно найти в стандартных местах, и его полный путь может быть указан как настройка командной строки (опция -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 теперь доступен официальный порт Win32 Openssh.

Файл-менеджеры для Unix-подобных систем (например, Konqueror ) могут использовать протокол Fish , чтобы обеспечить графический интерфейс с разделенным панелью с перетаскиванием. Программа с открытым исходным кодом Windows WinScp Предоставляет аналогичные возможности управления файлами (синхронизация, копия, удаленное удаление), используя замазку в качестве бэк-энда. Оба WinScp и замазка доступны упакованы для работы непосредственно с USB -диска, не требуя установки на клиентской машине. Crostini на Chromeos поставляется с OpenSsh по умолчанию. Настройка сервера SSH в Windows обычно включает в себя включение функции в приложении «Настройки».

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

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

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

Версия 1

В 1995 году Tatu Ylönen , исследователь Хельсинкского технологического университета в Финляндии разработал первую версию протокола (ныне называется SSH-1 ), вызванная атакой по облеганию пароля в его университетской сети . Цель SSH состояла в том, чтобы заменить более ранний Rlogin , Telnet , FTP и RSH -протоколы, которые не обеспечивали сильной аутентификации и не гарантировали конфиденциальность. Он выбрал порт № 22, потому что он между telnet (Порт 23) и ftp (порт 21).

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

В декабре 1995 года Ylönen основал SSH Communications Security на рынок и разработку SSH. В оригинальной версии программного обеспечения SSH использовались различные фрагменты свободного программного обеспечения , такие как GNU LIBGMP , но более поздние версии, выпущенные SSH Communications Security, превратились в все более проприетарное программное обеспечение .

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

Версия 2

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

Версия 1.99

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

Openssh и Ossh

В 1999 году разработчики, желающие доступности бесплатной версии программного обеспечения, перезапущенная разработка программного обеспечения из выпуска 1.2.12 оригинальной программы SSH, которая была последней выпущенной по лицензии с открытым исходным кодом . Это послужило кодовой базой для программного обеспечения Björn Grönvall OSSH. Вскоре после этого OpenBSD разработчики разделили код Grönvall и создали OpenSsh , который поставлялся с выпуском 2.6 OpenBSD. Из этой версии была сформирована филиал «портативность» в порт Openssh для других операционных систем.

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

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

Пример туннелирования приложения x11 над SSH: пользователь «Джош» имеет «SSHED» от локальной машины «Foofither» до удаленной машины «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 Server и Client поддерживают эту функцию.
• Для пересылки X от удаленного хоста (возможно через несколько промежуточных хостов)
• Для просмотра Интернета через зашифрованное прокси -соединение с клиентами SSH, которые поддерживают протокол носков .
• Для надежного монтажа каталога на удаленном сервере в качестве файловой системы на локальном компьютере с помощью SSHFS .
• Для автоматического удаленного мониторинга и управления серверами через один или несколько механизмов, обсуждаемых выше.
• Для разработки на мобильном или встроенном устройстве, которое поддерживает SSH.
• Для обеспечения протоколов передачи файлов.

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

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

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

Архитектура

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

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

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

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

Алгоритмы

• Eddsa , ECDSA , RSA и DSA для криптографии открытого ключа .
• ECDH и Diffie -Hellman для обмена ключевыми .
• HMAC , AEAD и UMAC для Mac .
• AES (и устаревший RC4 , 3DES , DES ) для симметричного шифрования .
• AES-GCM и Chacha20-Poly1305 для шифрования AEAD .
• SHA (и устаревший MD5 ) для ключа отпечатка пальца .

Уязвимости

SSH-1

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

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

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

CBC Plaintext Recovery

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

Подозреваемое дешифрование с АНБ

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

Террапин атака

Основная статья: атака террапина

Новая атака «Человек-в среднем» на большинство современных реализаций SSH была обнаружена в 2023 году. Она была названа Therapin Attack его обнаружениями. Тем не менее, риск смягчается требованием перехватить подлинный сеанс 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 - Протокол транспортного уровня безопасной (SSH)
• RFC   4254 - Протокол соединения Secure Shell (SSH)
• RFC   4255 - Использование DNS для надежной публикации ключей Secure Shell (SSH).
• RFC   4256 - Общая аутентификация обмена сообщениями для протокола Secure Shell (SSH)
• RFC   4335 - расширение сеанса Secure Shell (SSH).
• RFC   4344 - режимы шифрования транспортного слоя безопасной (SSH)
• RFC   4345 - Улучшенные режимы Arcfour для протокола транспортного слоя безопасной оболочки (SSH)

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

• RFC   4419 - Групповая биржа Diffie-Hellman для протокола транспортного слоя Secure Shell (SSH) (март 2006 г.)
• RFC   4432 - Обмен ключами RSA для протокола транспортного уровня Secure Shell (SSH) (март 2006 г.)
• RFC   4462 - Аутентификация прикладной программы Service Generic Security (GSS-API) и обмен ключами для протокола Secure Shell (SSH) (май 2006 г.)
• RFC   4716 - Формат открытого ключа Secure Shell (SSH) (ноябрь 2006 г.)
• RFC   4819 - Secure Shell Public Key подсистема (март 2007 г.)
• RFC   5647 - режим счетчика AES Galois для протокола транспортного уровня безопасного оболочки (август 2009 г.)
• RFC   5656 - Интеграция алгоритма эллиптической кривой в безопасном транспортном уровне раковины (декабрь 2009 г.)
• RFC   6187 - Сертификаты X.509V3 для обеспечения аутентификации Secult Shell (март 2011 г.)
• RFC   6239 - Криптографические люксы Suite B для безопасной оболочки (SSH) (май 2011 г.)
• RFC   6594 - Использование алгоритма SHA-256 с RSA, цифровым алгоритмом подписи (DSA) и Elliptic Curve DSA (ECDSA) в записях ресурсов SSHFP (апрель 2012 г.)
• RFC   6668 - Проверка целостности данных SHA-2 для протокола транспортного уровня Secure Shell (SSH) (июль 2012 г.)
• RFC   7479 - ED25519 SSHFP Resource Records (март 2015 г.)
• RFC   5592 - безопасная модель транспорта Shell для простого протокола управления сетью (SNMP) (июнь 2009 г.)
• RFC   6242 - Использование протокола NetConf над Secure Shell (SSH) (июнь 2011 г.)
• RFC   8332 - Использование клавиш RSA с SHA-256 и SHA-512 в протоколе Secure Shell (SSH) (март 2018 г.)
• Драфт-Жерхардс-Сислог-Транспорт-SSH-00- SSH Transport Mapping для Syslog (июль 2006 г.)
• Draft-IETF-SECSH-FILEXFER-13- Протокол передачи файлов SSH (июль 2006 г.)

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

• Обзор протокола Openssh
• OpenSSH Сертификат/Обзор ключа
• Draft-Miller-SSH-AGENT-04 -Протокол агента SSH (декабрь 2019 г.)

Смотрите также

• Брутная атака
• Сравнение клиентов SSH
• Сравнение серверов SSH
• Штопор
• Идентификатор
• OpenSsh
• Безопасное туннелирование раковины
• Веб-сайт SSH

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

• Барретт, Даниэль Дж .; Сильверман, Ричард Э.; Бирнс, Роберт Дж. (2005). SSH: безопасная оболочка (окончательное руководство) (2 -е изд.). О'Рейли. ISBN  0-596-00895-3 .
• Stahnke, Michael (2005). Pro Openssh . Апресс. ISBN  1-59059-476-2 .
• Tatu Ylönen (12 июля 1995 г.). «Объявление: программа удаленного входа в систему SSH (Secure Shell)» . Comp.security.unix. Оригинальное объявление SSH
• Dwivedi, Himanshu (2003). Реализация SSH . Уайли. ISBN  978-0-471-45880-7 .

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

• SSH -протоколы
• М. Джозеф; J. Susoy (ноябрь 2013 г.). P6R Secure Shell Public Key подсистема . doi : 10.17487/rfc7076 . RFC 7076 .
• Оригинальный SSH Source Tarball