Проверка SSH-сервера с помощью Monkeysphere на Ubuntu VPS

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

Кроме того, иногда при изменении сервера пользователи могут получать предупреждения, связанные с тем, что установить подлинность сервера невозможно. Большинство пользователей не проверяют отпечаток ключа перед подключением, а это потенциально  дает возможность посторонним подделать сервер и выполнить атаку  через посредника («man-in-the-middle»).

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

Данный мануал научит вас настраивать Monkeysphere для валидации серверов. Благодаря этому вашим пользователям больше не придется угадывать, является ли сервер, к которому они подключаются, именно тем, к которому нужно получить доступ. Обычно, когда вы подключаетесь к серверу в первый раз, вы видите что-то типа:

The authenticity of host '107.170.43.127 (107.170.43.127)' can't be established.
ECDSA key fingerprint is 10:14:75:d6:42:a3:c5:59:d1:83:6d:cf:52:61:4a:52.
Are you sure you want to continue connecting (yes/no)?

Этот мануал поможет вам устранить эти сообщения.

Читайте также: Аутентификация пользователей на SSH-сервере с помощью Monkeysphere в Ubuntu

Для настройки этой системы мы будем использовать экземпляры Ubuntu 12.04 VPS. Для работы вам нужен SSH-сервер, который вы сможете проверить. Вам также понадобятся две другие машины (локальные компьютеры или VPS): одна из них будет компьютером администратора, а вторая – клиентом, который мы будем использовать в качестве тестового компьютера для проверки подлинности сервера.

Общая стратегия

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

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

Итак, для настройки мы будем использовать три машины:

  • server.example.com: сервер SSH, подлинность которого нужно проверить.
  • admin.example.com: компьютер администратора, который будет использоваться для настройки доступа. Обычно для этого используется домашний компьютер, но в этом мануале мы используем облачный сервер.
  • client.example.com: это клиент, необходимый для валидации сервера SSH. Этот компьютер в результате сможет подключаться к серверу без получения предупреждения о неизвестном хосте.

У сервера SSH должно быть общедоступное доменное имя.

Сначала нужно сгенерировать ключи на компьютере администратора и на клиенте. Затем мы загрузим эти ключи на централизованный сервер ключей. После этого нужно скачать ключ администратора с сервера ключей, подписать его и сделать его доверенным, используя ключ клиента (это подтвердит, что клиент доверяет администратору).

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

Затем Monkeysphere может использовать фреймворк GPG для загрузки информации, которая подтвердит, что доверенный администратор отвечает за сервер, к которому вы пытаетесь подключиться.

1: Настройка GPG-ключей и аутентификации

GPG установлен в Ubuntu по умолчанию.

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

Генерирование ключей GPG

Создать ключ GPG нужно и на клиентской машине, и на машине администратора. Выполните следующее действие на обоих этих компьютерах:

gpg --gen-key

Эта команда задаст вам ряд вопросов, чтобы собрать информацию, необходимую для создания пары ключей. Сначала она спросит, какой тип ключей вы хотите создать. Выберите «1», чтобы создать два ключа RSA. Примите значение по умолчанию в следующем вопросе, чтобы получить 2048-битный ключ. Выберите «0», чтобы ключ оставался действительным всегда, а затем введите «Y», чтобы подтвердить, что информация верна.

Затем вам будет предложено предоставить информацию о каждом из ваших пользователей. Мы будем использовать имя admin и адрес электронной почты admin@fakedomain.com для ключей администратора. Для клиента мы используем имя client и адрес электронной почты client@fakedomain.com. Вы можете добавить дополнительный комментарий, а затем ввести «O», чтобы подтвердить информацию.

Введите и подтвердите парольную фразу для ваших ключей.

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

Когда ключ будет сгенерирован, он будет сохранен в вашем наборе ключей GPG. Вы можете увидеть его с помощью команды:

gpg --list-keys
/root/.gnupg/pubring.gpg
------------------------
pub   2048R/08D014B3 2014-03-14
uid                  client <client@fakedomain.com>
sub   2048R/4C73683E 2014-03-14

Часть строки, выделенная красным, является сокращенным идентификатором ключа. Вы можете использовать этот хэш для ссылки на этот ключ.

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

Чтобы загрузить ключи на серверы ключей, на клиентской и административной машине нужно ввести такую команду (указав свой идентификатор ключа):

gpg --send-key key_id

В нашем случае команда выглядит так:

gpg --send-key 08D014B3

Подпись ключей

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

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

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

На вашем клиентском сервере найдите отпечаток ключа GPG, введя эту команду (здесь client – это имя или адрес электронной почты, который вы выбрали при создании ключа):

gpg --with-colons --fingerprint client
tru::1:1394819815:0:3:1:5
pub:u:2048:1:4B3F73E208D014B3:2014-03-14:::u:client <client@fakedomain.com>::scESC:
fpr:::::::::85ECDB498FB0CAB5F02989E64B3F73E208D014B3:
sub:u:2048:1:254105194C73683E:2014-03-14::::::e:

Часть вывода, которая выделена выше, является необходимым отпечатком ключа.

Теперь, когда у вас на компьютере администратора есть отпечаток, вы можете найти ключ GPG с этим отпечатком и загрузить его на локальный компьютер:

gpg --recv-keys 85ECDB498FB0CAB5F02989E64B3F73E208D014B3

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

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

gpg --sign-key 85ECDB498FB0CAB5F02989E64B3F73E208D014B3

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

Чтобы вернуть и обновить ключ, введите:

gpg --send-key 85ECDB498FB0CAB5F02989E64B3F73E208D014B3

Сервер ключей теперь содержит ключ администратора и клиентский ключ, как и раньше. Разница в том, что теперь сервер ключей также имеет на клиентском ключе подпись от ключа администратора.

Затем нужно проделать ту же операцию для ключа администратора, подписав его ключом клиента. Для этого на компьютере администратора найдите отпечаток его ключа:

gpg --with-colons --fingerprint admin

Теперь на клиентском компьютере используйте отпечаток, чтобы загрузить, подписать, а затем вернуть ключ администратора на сервер ключей, как вы делали раньше:

gpg --recv-keys 7C873BB244245CB13BFEFC31F7C66E2FF945A061
gpg --sign-key 7C873BB244245CB13BFEFC31F7C66E2FF945A061
gpg --send-key 7C873BB244245CB13BFEFC31F7C66E2FF945A061

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

gpg --refresh-keys

Вам необходимо убедиться, что обновление было обработано. Вывод должен содержать строку new signatures: 1. Если этой строки нет, повторите попытку, пока она не появится.

Теперь каждый из ваших компьютеров имеет оба подписанных ключа.

Настройка администратора

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

Это означает, что когда администратор говорит, что сервер SSH подлинный, клиент может доверять подписям, которые делает администратор.

Сначала можно увидеть текущие настройки клиента, набрав:

gpg --check-trustdb
gpg: 3 marginal(s) needed, 1 complete(s) needed, PGP trust model
gpg: depth: 0  valid:   1  signed:   1  trust: 0-, 0q, 0n, 0m, 0f, 1u
gpg: depth: 1  valid:   1  signed:   0  trust: 1-, 0q, 0n, 0m, 0f, 0u

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

Вторая строка сообщает об уровне доверия “depth 0”. В основном это информация о нашем собственном ключе. Он считается действительным и подписанным. Часть trust говорит, что ключ находится в категории «u», что означает предельное доверие (ultimately trusted).

Третья строка говорит о ключах на уровне «depth 1». Это ключи, которые вы лично подписали. Как видите, на данный момент действительным считается один ключ (вы подписали ключ администратора, чтобы сделать его действительным), и что ключ администратора не подписал никаких дополнительных ключей, которые нам нужны.

В разделе доверия этой строки у нас есть поле «1-». Это означает, что один ключ на этом уровне (ключ администратора) не был настроен как доверенный. Мы не знаем, какой уровень доверия нужно установить для этого ключа.

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

gpg --update-trustdb

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

gpg: 3 marginal(s) needed, 1 complete(s) needed, PGP trust model
gpg: depth: 0  valid:   1  signed:   1  trust: 0-, 0q, 0n, 0m, 0f, 1u
No trust value assigned to:
2048R/49E95F19 2014-03-14
"admin <admin@fakedomain.com>"
Primary key fingerprint: A612 56B8 5307 B7ED 9AD8  D93E 9E06 881E 49E9 5F19
Please decide how far you trust this user to correctly verify other users' keys
(by looking at passports, checking fingerprints from different sources, etc.)
1 = I don't know or won't say
2 = I do NOT trust
3 = I trust marginally
4 = I trust fully
s = skip this key
q = quit
Your decision?

Мы хотим полностью доверять этому ключу, поэтому введите «4».

Итак, поскольку мы доверяем суждению администратора, мы можем быть уверены, что ключи, которые подписывает администратор, на самом деле связаны с рассматриваемым пользователем или сервисом (обычно вместо условных имен типа client и administrator используются реальные имена).

2: Установка Monkeysphere и настройка сервера SSH

Теперь ключи GPG для клиента и администратора настроены, и мы можем приступить к установке и настройке Monkeysphere.

В репозиториях Ubuntu по умолчанию есть пакет monkeysphere. Он содержит серверные и клиентские утилиты, необходимые SSH для поддержки проверки по GPG. То есть этот пакет нужно установить на каждом из наших компьютеров.

На всех компьютерах в этой среде (администратор, клиент, сервер SSH) установите monkeysphere с помощью команды:

sudo apt-get update
sudo apt-get install monkeysphere

Теперь у вас есть компоненты, необходимые для объединения этих серверов. На SSH-сервере мы сгенерируем специальный ключ GPG, используя специальную утилиту-оболочку, включенную в monkeysphere. Сгенерированный ключ будет основан на ssh_host_rsa_key, который используется для идентификации сервера для клиентов.

На сервере SSH введите:

monkeysphere-host import-key /etc/ssh/ssh_host_rsa_key ssh://server.example.com

Второй компонент должен указывать домен сервера SSH. Это поможет клиентам найти правильный ключ сервера при попытке проверить соединение.

Теперь мы можем снова загрузить только что созданный ключ на публичный сервер ключей. На этот раз мы снова будем использовать программу-оболочку, включенную в пакет monkeysphere:

monkeysphere-host publish-key

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

3: Проверка ключа сервера администратором

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

Метод, по которому работает GPG, заключается в создании так называемой «сети доверия» – проще говоря, это подразумевает создание сети людей, которых вы знаете и чью подлинность вы можете проверить с высокой степенью достоверности. Затем GPG использует эти доверительные отношения, чтобы позволить вам переложить ответственность за подлинность информации на людей, которым вы доверяете.

В данном случае мы (сейчас – как клиент) снимаем с себя ответственность за знание того, является ли сервер подлинным, и перекладываем ее на администратора, которому мы доверяем. Администратор сервера должен иметь четкое представление о том, проверяются ли учетные данные сервера.

Теперь нужно подписать ключ GPG SSH-сервера администратором. Это позволит клиентскому пользователю проверять подлинность сервера, доверяя администратору.

На сервере SSH найдите отпечаток GPG:

monkeysphere-host show-key
pub   2048R/0D281337 2014-03-14
uid                  ssh://fakedomain.com
OpenPGP fingerprint: E06A426459E584F272DB708AD2D462790D281337
ssh fingerprint: 2048 61:1e:a7:66:1d:04:64:80:3f:27:81:34:31:78:8d:df (RSA)

Отпечаток OpenPGP – это и есть нужный вам отпечаток GPG. Его нужно использовать, чтобы загрузить ключ на компьютер администратора и подписать его.

На компьютере администратора введите эту команду, чтобы получить ключ SSH-сервера. Опять же, вам, возможно, придется подождать несколько минут.

gpg --recv-key E06A426459E584F272DB708AD2D462790D281337

Так же, как и ранее, подпишите ключ сервера на машине администратора:

gpg --sign-key E06A426459E584F272DB708AD2D462790D281337

Теперь осталось вернуть подписанный ключ на сервер ключей.

gpg --send-key E06A426459E584F272DB708AD2D462790D281337

4: Проверка подлинности SSH-сервера с клиента

Теперь все готово, и ваш клиент сможет проверить подлинность сервера, к которому подключается.

Для этого нужно обернуть команды SSH в утилиту monkeysphere. Тогда клиент сможет использовать monkeysphere для проверки GPG-ключа сервера, к которому он подключается. Затем он увидит, может ли он доверять кому-либо, кто подтвердил подлинность сервера.

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

На клиенте введите команду вручную:

ssh -oProxyCommand='monkeysphere ssh-proxycommand %h %p' server.example.com
-------------------- Monkeysphere warning -------------------

Monkeysphere found OpenPGP keys for this hostname, but none had full validity.


An OpenPGP key matching the ssh key offered by the host was found:


pub   2048R/0D281337 2014-03-14


uid       [ unknown] ssh://server.example.com


sig!3        0D281337 2014-03-14  ssh://fakedomain.com


RSA key fingerprint is 61:1e:a7:66:1d:04:64:80:3f:27:81:34:31:78:8d:df.


-------------------- ssh continues below --------------------


The authenticity of host 'server.example.com (<no hostip for proxy command>)' can't be established.


ECDSA key fingerprint is 78:50:80:60:2a:a3:51:51:37:9d:25:8b:d4:0c:d1:15.


Are you sure you want to continue connecting (yes/no)?

Введите no.

Как видите, команда вернула обычное сообщение о том, что подлинность хоста, к которому мы пытаемся подключиться, не может быть установлена. Поскольку проблема еще не устранена, а мы не проверили подлинность сервера, сейчас нужно набрать «no», чтобы защитить себя от подключения к неправильному хосту.

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

Если мы посмотрим на ключи в цепочке ключей клиентского компьютера, то заметим, что теперь у нас есть ключ сервера SSH:

gpg --list-keys
/root/.gnupg/pubring.gpg
------------------------
pub   2048R/87791BD0 2014-03-14
uid                  client &lt;client@fakedomain.com&gt;
sub   2048R/3294D31D 2014-03-14
pub   2048R/54AD641F 2014-03-14
uid                  admin &lt;admin@fakedomain.com&gt;
sub   2048R/A87CADCB 2014-03-14
pub   2048R/0D281337 2014-03-14
uid                  ssh://fakedomain.com

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

gpg --refresh-keys

Вы должны снова увидеть строку new signatures: 1. Чтобы найти ее, нужно проверить подписи ключа SSH-сервера:

gpg --list-sigs ssh://server.example.com
pub   2048R/0D281337 2014-03-14
uid                  ssh://server.example.com
sig 3        0D281337 2014-03-14  ssh://server.example.com
sig          54AD641F 2014-03-14  admin <admin@fakedomain.com>

Как видите, теперь есть строка «sig», в которой указан ключ администратора. Поскольку клиент доверяет администратору, теперь мы можем по доверенности подтвердить подлинность SSH-сервера.

Давайте попробуем запустить команду снова:

ssh -oProxyCommand='monkeysphere ssh-proxycommand %h %p' server.example.com
root@server.example.com's password:

Как видите, теперь вы получили запрос пароля без запроса проверки подлинности сервера SSH. Это потому, что его подлинность была проверена через GPG.

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

nano ~/.ssh/config
Host *
ProxyCommand monkeysphere ssh-proxycommand %h %p

Это позволит вам как обычно подключаться по SSH, а monkeysphere будет проверять серверы в фоновом режиме.

ssh server.example.com

Чтобы убедиться, что все работает, удалите текущий файл known_hosts:

rm ~/.ssh/known_hosts

Теперь снова запустите команду ssh:

ssh server.example.com

Вы войдете в систему или будете вводить пароль, но при этом не будет сообщений о подлинности хоста. Вы также можете увидеть, что файл known_hosts был воссоздан автоматически и этот хост был добавлен в него:

cat ~/.ssh/known_hosts
server.example.com ssh-rsa AAAB3NzaC1yc2EAAAADAQABAAABAQC9aTHZmHZSgwNtwichF0AqDI74bCMtI29kqPDZaNn2r86NGIElRUlQiRImmZXs5oEjF0o8VaW6s1cIj0hC5ziDPShJ3VzZTWz9RmJ9xfPPcAPw2JbV1c1Q1bplstQqCZmFcRZyofztnP55HqOiJ4htLMxH+a9lM4AydDZtGHhzU+usxUjHniVbxCUVntpunlwtMk+Mtk9eysVdnJCJyV02/W89HExiO9QRpv+EugKN1eCQYrGvNbKWQKq4gSJ0RDwOSKNgkY/Ii0MsGJ2HuioO9np6IEdeZdgSGHPA23+zZe8asrN62iLUBADDkyIR6FAonCvfh99hbFxpNz2N8Mdb MonkeySphere2014-03-21T21:30:44

Заключение

Если ваша организация начнет использовать monkeysphere для SSH, пользователям SSH никогда не придется сомневаться в подлинности хостов. Когда ваши пользователи доверяют администраторам и проверяют SSH по monkeysphere, а администраторы тщательно следят за подписью новых хостов, ваших пользователей никогда не попросят подтвердить личность хоста.

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

Эта настройка может показаться сложной и трудоемкой, но сеть доверия значительно упростит вам работу в дальнейшем и позволит избежать атак типа «man-in-the-middle».

Читайте также: Аутентификация пользователей на SSH-сервере с помощью Monkeysphere в Ubuntu

Tags: , ,

Добавить комментарий