|
ru.unix.bsd
- RU.UNIX.BSD ------------------------------------------------------------------
From : Maxim Konovalov 2:5020/400 06 Oct 2006 13:13:58
To : All
Subject : openssh & sshfp pico howto
--------------------------------------------------------------------------------
Испытал непреодолимый приступ графомании. Результат ниже. Может кому
пригодится.
OpenSSH & SSHFP How-To.
-----------------------
$Id: sshfp.txt,v 1.3 2006/10/06 08:35:06 maxim Exp $
Когда вы впервые пытаетесь пройти по ssh на новый хост, никогда
не задавались вопросом, а на тот ли хост вы логинитесь? Ведь в наше
неспокойное время злоумышленники могут каким-либо образом прикинуться
тем самым сервером, на который вы собираетесь залогиниться, и перехватить
ваши ценные пароли. Да-да, мы неоднократно видели в кино как легко это
делается!
В идеальном мире наш системный администратор ведет глобальную базу
хостовых ключей в /etc/ssh/ssh_known_hosts, которая содержит ключи
всех хостов, на которым нам когда либо понадобится доступ. Эти ключи
получены из надежных источников и их достоверность не подлежит сомнению.
Стоп, кому нужен ssh в идеальном мире?
В реальности же при первом логине на хост вы не знаете, на самом деле
этот хост тот, за кого он себя выдает. Ssh(1) пытается помочь вам в
решении этой задачи и предлагает вам сравнить отпечаток хоста, подразумевая,
что вы знаете эталонный отпечаток. Hо спросите себя - как много хостовых
отпечатков вы знаете? Подозреваю, что ни одного. В подавляющем количестве
случаев на запрос ssh клиента о совпадении отпечатков пользователь просто
отвечает "да-да, все верно". При этом хостовый ключ записывается в вашу
локальную базу ключей, которая по умолчанию хранится в файле
~/.ssh/known_hosts. Кстати, этa база может стать дополнительным источником
информации о вас. Кстати #2 - опция HashKnownHosts испортит праздник излишне
любопытным.
RFC4255[1] предлагает новый способ хранения хостовых отпечатков при помощи DNS.
Фактически, вводится новый вид записи (resource record, RR) в зонном файле.
Формат этой записи подробно описан в [1] и выглядит следующим образом:
<name> IN SSHFP <public key algorithm> <fingerprint type> <fingerprint>
OpenSSH[2] имеет поддержку данного RFC, так почему бы ею не воспользоваться?
Решено, пробуем. Сначала сформируем записи в DNS. В этом нам поможет
утилита sshfp[3]. Во FreeBSD это ports/dns/sshfp/.
$ sshfp -ts ahost.example.com
no hostkey alg
ahost.example.com. IN SSHFP 2 1 c8f89de1164557de51e8207b29c8b4bd06acc634
Приведенную выше запись мы добавляем в зону example.com, инкрементируем
ее serial numbler и заставляем named перечитать зонный файл.
Проверяем, что наша запись появилась в DNS:
$ host -t sshfp ahost.example.com
ahost.example.com has SSHFP record 2 1 C8F89DE1164557DE51E8207B29C8B4BD06ACC634
Похоже на правду.
Теперь наша задача научить ssh проверять отпечаток в DNS. Для этого на хосте,
с которого вы будете запускать ssh, редактируем файл ~/.ssh/config (или
system wide config file /etc/ssh/ssh_config) и добавляем туда следующие строки:
Host ahost.example.com
VerifyHostKeyDNS yes
#StrictHostKeyChecking yes
#HashKnownHosts yes
Вместо ``ahost.example.com'' вы можете поставить ``*'', тогда конфигурационные
опции ниже будут относиться ко всем хостам.
Убеждаемся, что ssh начал сверять отпечаток с информацией в DNS:
$ ssh -vvv ahost.example.com 2>&1| grep -i dns
debug3: verify_host_key_dns
debug1: found 1 insecure fingerprints in DNS
debug1: matching host key fingerprint found in DNS
The authenticity of host 'ahost.example.com (10.0.0.1)' can't be established.
DSA key fingerprint is ab:35:6b:40:5d:74:08:91:71:dc:eb:93:8e:98:7e:4d.
Matching host key fingerprint found in DNS.
Are you sure you want to continue connecting (yes/no)?
Как видим, ssh нашел отпечаток и он совпал с отпечатком ключа
хоста ahost.example.com.
Как будет выглядеть этот же процесс, если на хосте ahost.example.com
по каким либо причинам изменится публичный ключ? Для приданию сюжету
остроты раскомментируем StrictHostKeyChecking в ~/.ssh/config. Тогда
картина будет выглядеть примерно так:
$ ssh ahost.example.com
@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@
@ 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 DSA host key has just been changed.
The fingerprint for the DSA key sent by the remote host is
ab:35:6b:40:5d:74:08:91:71:dc:eb:93:8e:98:7e:4d.
Please contact your system administrator.
Update the SSHFP RR in DNS with the new host key to get rid of this message.
No DSA host key is known for ahost.example.com and you have requested strict
checking.
Host key verification failed.
Собственно, этого мы и добивались: злоумышленник пытается провести
MiM атаку, но у него ничего не получается и посрамленный он возвращается
в свой темный угол.
- --
Все рассуждения велись для OpenSSH 4.4, bind 9.x.
Постоянный URL статьи: http://maxim.int.ru/tricks/sshfp.txt
Замечания, комментарии, ценные призы: Maxim Konovalov <maxim@macomnet.ru>
1. RFC4255, Using DNS to Securely Publish Secure Shell (SSH) Key Fingerprints.
http://www.ietf.org/rfc/rfc4255.txt
2. OpenSSH Project, http://openssh.org/
3. http://freshmeat.net/projects/sshfp/
--
Maxim Konovalov
--- ifmail v.2.15dev5.3
* Origin: MAcomnet Telco. (2:5020/400)
Вернуться к списку тем, сортированных по: возрастание даты уменьшение даты тема автор
|
