SSH

Стандартные команды Unix/Linux, такие как: rlogin, rsh, rcp или Client Telnet, которые также доступны в системах под управлением Microsoft Windows, обеспечивают удаленный доступ или копирование файлов (rcp). В то время разрабатывались сами протоколы и инструменты, и самые большие мечтатели не могли представить, что Интернет станет таким большим, как сегодня. Борьба, которая существует сегодня, чтобы защитить каждый открытый порт, или активированную услугу, или разработанное приложение от людей, которые получают удовольствие от взлома компьютерных систем и уничтожения чужой работы, даже не предполагалась. В результате сессии указанных инструментов было легко взломать, поскольку данные передавались по совершенно незащищенным сетям. Часто единственным методом аутентификации была аутентификация по паролю, и злоумышленник мог перехватить пароль при передаче, подключившись через rsh и выполнив, например, команду rm -rf /home, действуя от имени пользователя с правами root. Telnet считался достаточно безопасным протоколом для работы с удаленными терминалами (в мире Unix «терминал» означает любой компьютер, за которым вы сидите), выдавая команды по запросу, как если бы машина была локальной. Неудивительно, что для защиты входа в систему и удаленного выполнения команд была разработана замена telnet. Нетрудно догадаться, что SSH, Secure Shell, — это утилита, пришедшая на смену telnet. SSH обеспечивает зашифрованный терминальный сеанс, надежно защищенный алгоритмами симметричного шифрования. Шифрование поддерживается механизмами шифрования с открытым ключом для защиты сеансового ключа, используемого алгоритмом симметричного шифрования. Другие функции и возможности SSH включают в себя:

• 
  

  различные методы аутентификации пользователей,

  
  
• 
  

  туннелирование произвольных TCP-соединений через безопасный сеанс SSH;

  
  
• 
  

  Туннелирование сеансов X Windows,

  
  
• 
  

  поддержка внешних методов аутентификации, включая Kerberos, SecurID, Smart Card

  
  
• 
  

  безопасная передача файлов с использованием механизмов SCP.

Эти возможности позволяют пользователю защититься от таких атак, как:

• 
  

  IP-спуфинг,

  
  
• 
  

  IP-маршрутизация источника,

  
  
• 
  

  спуфинг DNS,

  
  
• 
  

  перехват паролей в открытом виде,

  
  
• 
  

  Прослушивание данных аутентификации X-Windows и поддельных соединений.

В настоящее время доступны две версии SSH: SSH Secure Shell Version 1 и Secure Shell Version 2. SSH1 не так безопасен, как SSH2, и постепенно выводится из использования.

Что защищает SSH1?

Одна из ключевых концепций SSH1 заключается в том, что каждый хост в сети или, по крайней мере, каждый хост, который принимает входы SSH, имеет уникальный криптографический ключ RSA для целей идентификации. Длина ключа хоста по умолчанию составляет 1024 бита. Кроме того, при активации сервера SSH1 автоматически генерируется второй ключ RSA. Это называется собственным ключом RSA сервера и по умолчанию имеет длину 768 бит. В целях повышения безопасности этот ключ регенерируется после определенного тайм-аута (по умолчанию 1 час), если за это время сервер использовал ключ. Этот ключ никогда не сохраняется ни в одном файле сервера. Всякий раз, когда клиент подключается к серверу, в ответ сервер отправляет набор как открытых ключей, так и ключей хоста. Клиент сравнивает открытый ключ хоста с мастер-ключом. Эта процедура предназначена для проверки того, совпадает ли подключенный хост с хостом в первом запросе. В связи с этим ключ RSA хоста считается неизменным. Стоит отметить, что ключ сервера нельзя использовать для аутентификации хоста, так как этот ключ часто модифицируется. После успешного выполнения аутентификации хоста клиент случайным образом генерирует 256-битный ключ сеанса и шифрует его с помощью ключа сервера и ключа хоста сервера вместе. Этот тип подготовленной информации затем отправляется на сервер, который имеет набор закрытых ключей и может расшифровать значение, отправленное клиентом. Этот шифр теперь используется в качестве ключа для симметричных криптографических алгоритмов для шифрования сеанса. Для этого используются алгоритмы шифрования Blowfish или 3DES, причем 3DES обычно используется по умолчанию. Клиент выбирает используемый алгоритм шифрования из предложенных сервером. После успешного завершения этапа согласования между сервером и клиентом остальная часть трафика в сеансе SSH1 шифруется с помощью существующего алгоритма с использованием сеансового ключа. После этого пользователь может быть надежно аутентифицирован на сервере. Пароль никогда не передается по сети в виде открытого текста, а поскольку SSH не ограничивается аутентификацией по паролю, можно использовать более сложные методы, например криптографические алгоритмы с открытым ключом. SSH также поддерживает менее безопасные методы, такие как аутентификация Rhost. Сама процедура аутентификации во время сеанса SSH1 выглядит следующим образом:

• 
  

  если машина, с которой входит пользователь, указана в /etc/hosts.equiv или /etc/shosts.equiv на удаленной машине, а имена пользователей одинаковы на обеих сторонах, пользователю сразу же разрешается войти в систему.

  
  
• 
  

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

Поскольку эти два метода аутентификации не являются безопасными, они обычно не принимаются правильно настроенными серверами. Другими методами аутентификации являются методы Rhost в сочетании с аутентификацией хоста на основе RSA. Используя этот метод, сервер может ужесточить безопасность доступа, дополнительно проверив ключ хоста клиента. Ключи хоста SSH помещаются в /etc/ssh/ssh_known_hosts или $HOME/.ssh/known_hosts указанных пользователей. Такие модифицированные Стандартная аутентификация Rhost является частичным средством устранения слабых мест в системе безопасности из-за спуфинга IP, спуфинга DNS и спуфинга маршрутизации. Однако аутентификация Rhost не очень безопасна, поэтому ее использование требует особого внимания, и, как правило, лучше всего не использовать ее.

В качестве третьего метода аутентификации SSH использует схему, основанную на системе криптографии с открытым ключом, где используется интегрированная пара ключей — один открытый ключ и один закрытый ключ. РСА является одним из примеров. Идея состоит в том, что для успешной аутентификации пользователя требуется, чтобы сервер знал открытый ключ пользователя и только пользователь знал закрытый ключ. В файле $HOME/.ssh/authorized_keys перечислены открытые ключи, разрешенные для входа в систему. Когда клиент входит в систему, он сообщает серверу, какой ключ он хотел бы использовать для аутентификации. Сервер проверяет, разрешен ли этот ключ, и если да, отправляет ssh-клиенту случайное число, называемое вызовом, зашифрованное открытым ключом пользователя. Этот вызов может быть зашифрован только с использованием закрытого ключа владельца ключа, т. е. только той стороной, которая владеет парой ключей. Затем клиент пользователя расшифровывает запрос, используя закрытый ключ, и, если запрос такой же, как и в предыдущем ответе сервера, это является доказательством того, что пользователь знает закрытый ключ, соответствующий открытому ключу. Таким образом, можно гарантировать, что закрытый ключ никогда не будет раскрыт серверу. Пользователь создает свою пару ключей RSA, запустив ssh-keygen. При этом закрытый ключ хранится в $HOME/.ssh/identity, а открытый ключ — в $HOME/.ssh/identity.pub. Чтобы использовать аутентификацию RSA, пользователь должен скопировать открытый ключ в $HOME/.ssh/authorized_keys в своем домашнем каталоге на удаленном сервере. Аутентификация RSA намного безопаснее, чем ранее описанная аутентификация Rhosts.

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

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

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

SSH2

SSH1 и SSH2 — это разные версии одной и той же программы. У каждого хоста есть свой уникальный ключ аутентификации RSA или DSA, а не просто ключ RSA, как у SSH1. Первое обнаруженное отличие — во время запуска SSH-сервера. – нет ключа сервера. Сеансовый ключ, созданный Диффи-Хеллманом, используется для шифрования реального сеансового ключа. После того, как сеансовый ключ установлен, трафик шифруется с использованием одного из следующих симметричных алгоритмов:

• 
  

  128-битный AES

  
  
• 
  

  иглобрюх

  
  
• 
  

  3DES

  
  
• 
  

  CAST128

  
  
• 
  

  Аркчетыре

  
  
• 
  

  192-битный AES

  
  
• 
  

  256-битный AES

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

И SSH1, и SSH2 используют некоторые методы аутентификации. По умолчанию клиент пытается аутентифицировать себя, используя набор следующих методов:

• 
  

  Аутентификация Rhosts

  
  
• 
  

  аутентификация по открытому ключу

  
  
• 
  

  клавиатурно-интерактивная аутентификация

  
  
• 
  

  аутентификация по паролю

Аутентификация с открытым ключом аналогична аутентификации SSH1, за исключением того, что вместо этого используется алгоритм RSA или DSA, а ключи перечислены в $HOME/.ssh/id_dsa и $HOME/.ssh/id_dsa.pub для DSA и $HOME/.ssh/id_rsa$HOME/.ssh/id_rsa.pub для RSA соответственно. В отличие от SSH1, когда клиент хочет аутентифицировать свое использование пар открытого/закрытого ключей, он входит в систему с закрытым ключом клиента, где идентификатор сеанса получен из общего значения Диффи-Хеллмана, а затем сервер проверяет, соответствует ли открытый ключ указан в файле author_keys. Если проверка подлинности с открытым ключом не удалась, то для подтверждения личности пользователя предпринимается попытка использовать другой метод проверки подлинности. Порядок методов аутентификации устанавливается с помощью PreferredAuthentications в файле конфигурации. По умолчанию настроен следующий порядок: на основе хоста, с открытым ключом, с интерактивной клавиатурой, с паролем.

Обратите внимание, что SSH2 позволяет использовать другие методы аутентификации, например, Kerberos, сертификаты X.509, электронные кредитные карты и другие средства.

И SSH1, и SSH2 поддерживают механизмы агента аутентификации. С помощью программы ssh-agent (стандартной) пользователь может добавлять идентификаторы к агенту аутентификации. Одним из примеров может быть Агент, у которого изначально нет закрытых ключей. Ключи добавляются с помощью ssh-add, что в типичном случае приводит к добавлению файлов $HOME/.ssh/id_rsa, $HOME/.ssh/id_dsa и $HOME/.ssh/identity. Если эти файлы зашифрованы парольной фразой, ssh-add запрашивает у пользователя парольную фразу. Несколько идентификаторов (ключей) могут храниться в одном агенте. ssh-add -l отображает идентификаторы, которые в настоящее время принадлежат агенту.

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

Удаленное исполнение

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

Переадресация X11 и TCP

Если параметр конфигурации ForwardX11 активен и пользователь использует X11 (установлена переменная среды DISPLAY), весь трафик X11 автоматически перенаправляется по защищенному каналу SSH, а подключение к реальному X-серверу осуществляется с локального компьютера.

На серверах Windows вместо переадресации X11 используется переадресация произвольных соединений TCP/IP по защищенному каналу.

Аутентификация сервера

Клиенты SSH автоматически поддерживают и проверяют базу данных, содержащую идентификацию всех хостов, когда-либо участвовавших во взаимодействии. База данных для каждого пользователя хранится в $HOME/.ssh/known_hosts и дополнительно на уровне сервера в /etc/ssh/ssh_known_hosts. Любые новые хосты автоматически добавляются в базу данных. Если идентификация хоста когда-либо меняется, клиент предупреждает об этом пользователя, чтобы запретить отправку пароля пользователя на неавторизованный сервер, а также для предотвращения атаки троянского коня. Другой целью этого механизма является предотвращение атак типа «человек посередине». Параметр StrictHostKeyChecking можно использовать для повышения безопасности. Пока он активен, он предотвратит вход на сервер, если их идентификация изменилась. Эта опция может быть установлена и применена к пользователям системным администратором.

Резюме

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

Легенда

Prawdziwy klucz = Аутентифицированный ключ

Prawdziwy server SSH = аутентифицированный SSH-сервер

Подключенный сервер…. = Поддельный сервер, работающий как настоящий сервер. Предоставленный ключ не соответствует подлинности

Faszywy server SSH = Поддельный SSH-сервер

Poczenie z klienta… = Подключение клиента и проверка ключа

Сервер WWW = сервер WWW

SSH-сервер = SSH-сервер

Клиент SSH = клиент SSH

Przyjecie poczenia = Прием соединения через порт # 2300 с последующей переадресацией на WWW-сервер через порт # 80

Poczenie z serverem,,,, = Соединение между сервером SSH и портом # 2300