Защита с помощью SSH ключей

00:00 / 22 февраля, 2005

Это первая из серии статей, рассказывающих об особенностях использования SSH. Мы начнем с рассмотрения стандартных SSH ключей, изучив процесс верификации, чтобы гарантировать, что вы не стали объектом атаки. Обратите внимание, что эта статья применима к широко используемому приложению OpenSSH, которое присутствует в большинстве Unix-подобных операционных систем, а не к коммерческой версии SSH.

Брайен Хатч, перевод Владимир Куксенок

SSH ключи как защита от атак "человек посередине"

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

Одна из проблем, связанная с этими старыми протоколами, кроме того, что они передают всю вашу информацию открытым текстом, состоит в том, что данные протоколы уязвимы к атаке "человек посередине". Атакующий, имеющий доступ к промежуточной сети, может перехватить ваши пакеты, сохранить их, а затем отослать непосредственному адресату. Еще хуже, он может перезаписать ваши пакеты, например, заменив ls -la mydir на rm -r mydir или отправить вам протрояненный файл вместо оригинала через ваш перехваченный FTP сеанс. Так как в этих протоколах отсутствует возможность наверняка знать, с кем осуществляется связь, возможно большое количество различных уловок.

SSH предоставляет важную возможность подтверждения подлинности хоста, с которым вы соединяетесь. Если вы правильно верифицировали хост, не существует способов чтения или манипуляции вашими пакетами промежуточным устройством [сноска 1]. Успешная верификация хоста показывает, что соединение зашифровано от начала до конца - ваш SSH клиент установил безопасное соединение непосредственно с SSH сервером, и никакие промежуточные машины не имеют доступа к этому соединению.

Проверка подлинности хоста это не уникальность SSH. В любом приличном защищенном протоколе есть набор способов верификации. Например, давайте рассмотрим HTTPS, зашифрованную SSL/TLS версию HTTP. Он также предоставляет возможность верификации хоста почти таким же способом, как и SSH. Проверка подлинности хоста средствами HTTP представляет собой следующее. Я возьму на себя смелость, говоря SSL подразумевать SSH, чтобы была ясность в сравнении ниже. [сноска 2]

Клиент (веб браузер) соединяется с сервером (HTTPS веб сервер на 443 порту)
Сервер предоставляет свой открытый ключ (Сертификат X509)
Сервер предоставляет некое математическое число, доказывающее, что у сервера есть доступ к закрытому ключу, связанному с открытым ключом.
Браузер проверяет, подписан ли открытый ключ доверенным Certificate Authority (такими как Verisign, Thawte или другими).
Браузер проверяет, соответствует ли значение CN (X509 Common Name) сертификата сервера имени хоста, которое вы использовали для соединения с сервером. Т.е. если соединились с https://www.example.com, значение CN сертификата должно быть www.example.com.

Все эти шаги присутствуют и в SSH, за исключением одного: нет никакого Certificate Authority. [сноска 3] Вместо этого, 'authority' это ваши личные и глобальные файлы конфигурации, которые мы рассмотрим позже.

SSH ключи в действии

Давайте посмотрим, как SSH осуществляет эти шаги, создав SSH соединение с компьютером, к которому мы никогда не подключались прежде:

  $ <b>ssh ssh-server.example.com</b>
  The authenticity of host 'ssh-server.example.com (12.18.429.21)' 
can't be established.
  RSA key fingerprint is 98:2e:d7:e0:de:9f:ac:67:28:c2:42:2d:37:16:58:4d.
  Are you sure you want to continue connecting (yes/no)?

Ответим "да", и подключение продолжится:

  $ <b>ssh ssh-server.example.com</b>
  Are you sure you want to continue connecting (yes/no)? yes
  
  Warning: Permanently added 'ssh-server.example.com,12.18.429.21' 
(RSA) to the list of known hosts.
  
  Password: <b>(введите пароль)</b>

  
  ssh-server.example.com $

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

Так как мы подключаемся к этой машине впервые, и SSH не работает по принципу третьего доверенного лица, такого как Certificate Authorities в мире SSL/TLS, вся работа, связанная с управлением ключами, лежит на вас. Ваш клиент показывает отпечаток ключа (key fingerprint), простую для чтения строку чисел, которую вы можете использовать для проверки ключа вручную, что мы и сделаем позже. Если вы отвечаете "Да, отпечаток правильный", ваш SSH клиент продолжит аутентификацию, дав вам возможность ввести ваш пароль и приступить к работе.

Когда вы выше ответили "да", ваш SSH клиент сохранил ключ сервера в файле $HOME/.ssh/known_hosts. Это файл фактически является вашим личным Certificate Authority - списком ключей всех SSH серверов, с которыми вы работаете. Давайте посмотрим на последнею строку этого файла, которая была только что добавлена вами:

  $ <b>tail -1 $HOME/.ssh/known_hosts</b>
  ssh-server.example.com,12.18.429.21 ssh-rsa AAAAB3NzaC1yc2EAAAABIwAAAIEA0
    6jFqviLMMJ/GaJNhGx/P6Z7+4aJIfUqcVjTGQasS1daDYejcfOAWK0juoD+zS3BsGKKYKPA
    5Gc5M8v+3NHLbPn1yTpDBgl6UzA0iiMPCbwnOLx61MrBTk+/qJI9kyDaJf4LEY6Chx4IJP0
    ZN5NmAlCtXQsca3jwFAF72mqPbF8=

(Я взял на себя смелость перенести и выровнять эту строку для удобства просмотра)

Каждая запись в known_hosts является большой строкой с тремя или больше пробелами, отделяющими поля следующим образом:

Одно или несколько имен серверов или IP адресов, разделенных запятыми.
Тип ключа (описан ниже).
Непосредственно открытый ключ (закодированный в пределах диапазона символов ASCII).
Любые дополнительные комментарии (не показаны в выводе выше)

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

  $ <b>ssh ssh-server.example.com</b>

  Password: <b>(введите пароль)</b>

Заметьте, в этот раз он вообще не просил вас проверить отпечаток ключа. Причина в том, что ключ находится в вашем файле $HOME/.ssh/known_hosts. Фактически SSH клиент проверяет на наличие ключа несколько мест:

Глобальный файл, обычно /etc/ssh/ssh_known_hosts. Этот путь может быть изменен редактированием параметра GlobalKnownHostsFile в конфигурационном файле ssh (обычно это /etc/ssh/ssh_config).
Файл пользователя, обычно $HOME/.ssh/known_hosts. Этот путь может быть изменен редактированием параметра UserKnownHostsFile в конфигурационном файле ssh.

Как вы должны были заметить, когда мы впервые соединились с хостом и получили его открытый ключ, было сохранено имя хоста (ssh-server.example.com) и IP адрес (12.18.429.21), поэтому теперь мы можем использовать любое из этих значений для соединения, и в обоих случаях будет возможно извлечение и подтверждение подлинности ключа из вашего файла known_hosts.

Подтверждение подлинности ключа

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

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

Если вышеописанный способ вам не доступен, проверить ключ системы, в которую вы вошли, можно следующим образом. Открытый ключ обычно доступен в директории /etc/ssh/, так что после входа в систему вы можете проверить отпечаток ключа (используя ssh-keygen), который вы приняли во время входа в систему. (ssh-keygen также используется для создания SSH ключей и Identities/PubKeys, которые мы обсудим позже.)

Вернемся к первому соединению, которое мы создали, и посмотрим, как мы можем проверить отпечаток ключа:

  $ <b>ssh ssh-server.example.com</b>

  The authenticity of host 'ssh-server.example.com (12.18.429.21)' 
  can't be established.
  RSA key fingerprint is 98:2e:d7:e0:de:9f:ac:67:28:c2:42:2d:37:16:58:4d.
  Are you sure you want to continue connecting (yes/no)? yes

  Warning: Permanently added 'ssh-server.example.com,12.18.429.21' 
(RSA) to the list of known hosts.
  
  Password: <b>(enter password)</b>
  
  ssh-server.example.com $ cd /etc/ssh
  ssh-server.example.com $ ls *.pub
  ssh_host_dsa_key.pub  ssh_host_rsa_key.pub ssh_host_key.pub
  
  ssh-server.example.com $ ssh-keygen -l -f /etc/ssh/ssh_host_rsa_key.pub
  1024 98:2e:d7:e0:de:9f:ac:67:28:c2:42:2d:37:16:58:4d ssh_host_rsa_key.pub

Выше мы видим, как пользователь принимает ключ, входит в систему, а затем проверяет ключ вручную с помощью ssh-keygen. Если отпечатки совпадают, вы можете с большой вероятностью быть уверены [сноска 4], что вы подключились к правильному серверу, даже при условии, что вы заранее не знали открытый ключ.

Проверка ключа

SSH имеет три способа реагирования на неопознанный или измененный ключ, основанных на значении переменной StrictHostKeyChecking:

StrictHostKeyChecking=no

Это самое небезопасное значение, разрешающее соединение с сервером вслепую. Если ключ сервера не присутствуют на локальном компьютере или ключ был изменен, он добавляется автоматически без каких-либо вопросов, всего лишь выдав предупреждение [сноска 5].
Ставить этот режим не очень хорошая идея.

StrictHostKeyChecking=ask

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

$ <b>ssh -o stricthostkeychecking=ask ssh-server.example.com</b>
@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@
@    WARNING: REMOTE HOST IDENTIFICATION HAS CHANGED!     @
@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@
IT IS POSSIBLE THAT SOMEONE IS DOING SOMETHING NASTY!
Someone could be eavesdropping on you right now (man-in-the-middle attack)!
It is also possible that the RSA host key has just been changed.
The fingerprint for the RSA key sent by the remote host is
23:00:20:83:de:02:95:f1:e3:34:be:57:3f:cf:2c:e7.
Please contact your system administrator.
Add correct host key in /home/xahria/.ssh/known_hosts to get 
        rid of this message.
Offending key in /home/xahria/.ssh/known_hosts:8
RSA host key for localhost has changed and you have 
       requested strict checking.
Host key verification failed.

StrictHostKeyChecking=yes

Эта самая безопасная, возможно даже недружелюбная установка. Если у вас нет ключа сервера, вы вообще не сможете войти в систему:

  $ <b>ssh -o 'StrictHostKeyChecking=yes' ssh-server.example.com</b>
  No RSA host key is known for localhost and you have 
requested strict checking.
  Host key verification failed.

Если у вас есть ключ, но он не совпадает с ключом сервера, вы получите ошибку, такую же, как и при StrictHostKeyChecking=ask.

Почему ключ может измениться?

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

Было обновлено либо клиентское, либо серверное ПО, которое использует SSHV2, вместо прежнего SSHV1 [сноска 6].
Машина была переустановлена с тем же самым именем хоста, но исходные ключи не были восстановлены. После того как они будут созданы снова, они, конечно, не будут соответствовать вашему файлу known_hosts.
У компьютера, с которым вы хотите соединиться, было изменено DNS имя или IP адрес, или этот компьютер был заменен на новый.

Типы ключей

SSH поддерживает два основных протокола - SSHv2 и SSHv1 [сноска 7].

Старый протокол SSHv1 основан на алгоритме асимметричного шифрования RSA, тогда как более новый протокол SSHv2 поддерживает RSA и алгоритм aсимметричного шифрования DSA. SSH сервер может использовать один из трех типов ключей: SSHv1 RSA ключи, SSHv2 RSA ключи, или SSHv2 DSA ключи. Я буду называть их rsa1, rsa и dsa ключи соответственно, поскольку эта терминология используется в утилитах OpenSSH.

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

В файле sshd_config, обычно находящемся в директории /etc/ssh, перечислены ключи, загружающиеся во время старта системы.

  # Which protocol(s) should we support?
  Protocol 2,1
  
  # HostKey for protocol version 1  
  HostKey /etc/ssh/ssh_host_key
  
  # HostKeys for protocol version 2
  HostKey /etc/ssh/ssh_host_rsa_key
  HostKey /etc/ssh/ssh_host_dsa_key

Если вы собирали SSH из исходников, вы можете создать эти три ключа с помощью ssh-keygen:

  # <b>ssh-keygen -t rsa /etc/ssh/ssh_host_rsa_key</b>
  # <b>ssh-keygen -t dsa /etc/ssh/ssh_host_dsa_key</b>
  # <b>ssh-keygen -t rsa1 /etc/ssh/ssh_host_key</b>

Программа ssh-keygen создает по два файла для каждого ключа. Первый содержит и закрытый и открытый ключ, а второй только открытый ключ. Таким образом, впервые запустив ssh-keygen, вы создадите файлы /etc/ssh/ssh_host_rsa_key и /etc/ssh/ssh_host_rsa_key.pub. Нет никаких причин скрывать открытый ключ, но закрытый ключ должен быть надежно скрыт, так как он не защищен никаким паролем (passphrase) [сноска 9]. К счастью, ssh-keygen устанавливает параноидальные разрешения на доступ к файлу.

Если вы сомневаетесь, что первый файл, не оканчивающийся на .pub, содержит закрытый ключ, или по каким-то причинам вы потеряли открытий ключ, вы всегда можете восстановить его с помощью той же самой команды ssh-keygen:

  $ <b>ls -1 /etc/ssh/ssh_host_rsa_key*</b>

  /etc/ssh/ssh_host_rsa_key
  /etc/ssh/ssh_host_rsa_key.pub
  
  $ <b>cat /etc/ssh/ssh_host_rsa_key.pub</b>
  ssh-rsa AAAAB3NzaC1yc2EAAAABIwAAAIEApCyGZbDdzrRdszzQUZI+siu3
    /mUI57nmjzKwHS7M27AoMZNJ6yIDTn5J3/MVCDJAeyB53LvIFFD9Kzp6P9
    fhNhPm8+b0joJ5Wrn+YfUnt2moI3lkAzQUZI+siu3/mUI57nmjzKwH
  
  $ <b>ssh-keygen -y -f  /etc/ssh/ssh_host_rsa_key</b>
  ssh-rsa AAAAB3NzaC1yc2EAAAABIwAAAIEApCyGZbDdzrRdszzQUZI+siu3
    /mUI57nmjzKwHS7M27AoMZNJ6yIDTn5J3/MVCDJAeyB53LvIFFD9Kzp6P9
    fhNhPm8+b0joJ5Wrn+YfUnt2moI3lkAzQUZI+siu3/mUI57nmjzKwH

Есть ли какие-либо причины использования одного типа ключа, а не другого? Нет. Ключ rsa обычно бывает несколько быстрее с математической точки зрения, но для больших возможностей взаимодействия лучше включать оба. Оба алгоритма не запатентованы [сноска 10], поэтому насчет этого вы можете не беспокоиться. Если вам нужна поддержка SSHv1, у вас должен быть ключ rsa1.

Советы

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

Используйте глобальный файл известных хостов (/etc/ssh/ssh_known_hosts), содержащий все машины, с которыми соединяются ваши пользователи. Если вы выделите время для проверки этих ключей, вам не нужно будет полагаться на пользователей. Удостоверьтесь, что вы получаете все три типа ключа, rsa, dsa, и rsa1. Также, когда вам нужно будет изменить ключ (например, машина была переустановлена, и вы забыли сохранить старые ключи), у вас будет только один файл, который нужно обновить.

Используйте для хостов псевдонимы (aliases), которыми могут попытаться воспользоваться ваши пользователи. Например, вы должны включить и mail и mail.my_co.com, если к этому хосту можно получить доступ, используя оба этих имени.

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

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


   #!/bin/sh
   #
   # add-known-hosts
   # Add all possible SSH keys for the specified hosts to the file
   # specified.  It's your responsibility to be sure that the keys
   # found are, in fact, valid.
   #
   # Copyright 2003, Brian Hatch <bri [@] ifokr.org>
   #  Released under the GPL
   
   KNOWN_HOSTS=./ssh_known_hosts
   SSH_ARGS="-o StrictHostKeyChecking=no -o UserKnownHostsFile=$KNOWN_HOSTS"
   
   if [ $# -lt 1 ] ; then
           echo "Usage: $0 hostname [hostname ...]" >&2
           exit 1;
   fi
   
   for host in "$@"
   do
           ssh $host $SSH_ARGS -1 echo ''           ssh $host $SSH_ARGS -
o'HostKeyAlgorithms=ssh-rsa' echo ''
           ssh $host $SSH_ARGS -o'HostKeyAlgorithms=ssh-dss' echo ''
   done

Опции настройки

Есть несколько различных опций настройки, которые могут быть вам полезны, в зависимости от того, как вы используете SSH. Они могут быть описаны в глобальном конфигурационном файле SSH, обычно это /etc/ssh/ssh_config, или в пользовательской конфигурации, обычно находящейся в $HOME/.ssh/config. Смотрите страницу документации (manpage) ssh_config для большей информации.

StrictHostKeyChecking: Определяет, нужно ли при игнорировании ошибки во время соединения, связанной с ключом хоста, завершить работу сразу или спросить пользователя, хочет ли он продолжить работу.
CheckHostIP: Определяет, нужно ли проверять IP адрес сервера в файле known_hosts.
NoHostAuthenticationForLocalhost: Выключает проверку ключа для локальной машины. Может быть полезно, если вы настраиваете переадресацию трафика с порта SSH на удаленные машины, например ssh -p 9999 localhost, но вам нужно работать на локальной машине. Для этого лучше использовать HostKeyAliases.
HostKeyAlias: Эта опция позволяет указать псевдоним, который будет использоваться в командной строке вместо реального имени хоста, при поиске соответствия в файле known_hosts. Особенно это полезно для команд, использующих ProxyCommands для соединения, или при использовании различных портов на компьютере, которые переадресуют трафик на различные SSH сервера, находящиеся, например, за межсетевым экраном.
HostKeyAlgorithms: Алгоритм, который вы предпочитаете, RSA или DSA для второй версии протокола. По умолчанию это RSA, и если вы хотите, можете также следовать этой установке.

Сноски

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

[сноска 2] Имейте ввиду, что это описание правильно для любого SSL/TLS совместимого сервиса с включенной авторизацией - это не должен быть HTTPS, а, например, может быть MySQL или LDAP через SSL.

[сноска 3] Существуют патчи к OpenSSH, позволяющие производить аутентификацию по стандарту X509, поэтому вы можете использовать эту модель, если хотите.

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

[сноска 5] Это действительно так, однако, отключая проверку пароля, вы по крайнее мерее должны использовать SSH Identities/PubKeys, Challenge/Response или какие-нибудь другие формы аутентификации, которые не могут быть повторно использованы атакующим.

[сноска 6] Обратное возможно, но маловероятно.

[сноска 7] SSHv1 считается менее безопасным, чем SSHv2. Если вам не нужно использовать клиентское ПО, поддерживающее только старый протокол SSHv1, в целях безопасности лучше всего будет включить поддержку только SSHv2 на вашем сервере. Строчка Protocol в файле /etc/ssh/sshd_config должны выглядеть следующим образом:

   # Protocol 2,1 would allow either SSHv1 or SSHv2.
   # Let's be paranoid and only support the later.
   Protocol 2

[сноска 8] ssh-keygen используется и для создания SSH Identities/PubKeys. Действительно нет никакой разницы между ключом пользователя и хоста.

[сноска 9] Закрытый ключ не должен быть защищен паролем, чтобы sshd мог запуститься без вмешательства администратора после перезагрузки.

[сноска 10] Срок патента на алгоритм RSA истек в 2000 году.

Ищем темную материю и подписчиков!

Одно найти легче, чем другое. Спойлер: это не темная материя

Станьте частью научной Вселенной — подпишитесь