Эта статья является переводом текста Dru Lavigne (см.
http://www.onlamp.com/pub/a/bsd/2002/11/14/FreeBSD_Basics.html).
В предыдущей части (см. http://softerra.ru/freeos/23045), вы
узнали, что криптосистемы в компьютерных сетях используются для
обеспечения приватности, целостности и аутентичности передаваемых
данных. Сегодня мы посмотрим как предоставляет эти функции
криптосистема SSH.
Если вы используете FreeBSD 4.0 или выше, то ваша система уже содержит
пакет OpenSSH, готовый к использованию. Как нетрудно догадаться из
названия, OpenSSH это реализация криптосистемы SSH на базе открытых
исходных текстов. Подробнее о нем вы можете узнать на официальном
сайте OpenSSH (см. http://www.openssh.org).
В одной из предыдущих статей (см. статью <<IP packet revealed>>
http://www.onlamp.com/pub/a/bsd/2001/03/26/FreeBSD_Basics.html) я
продемонстрировал использование утилиты telnet для удаленного доступа
к компьютерам. После регистрации на удаленной системе, пользователь
может делать все тоже самое, как если бы он сидел прямо за консолью
удаленного компьютера. Таким образом, любая строка символов набранная
с клавиатуры вашего компьютера посылается на удаленный компьютера и
интерпретируется там как будто она была набрана на его клавиатуре
(несмотря на то, что на самом деле набранные символы перед этим
путешествовали по сети). Кроме того, в той же статье мы выяснили, что
и клавиатурный ввод и ответные сообщения пересылаются открытым текстом
и, следовательно, легко перехватываются снифферами (анализаторами
сетевого трафика).
Любая реализация криптосистемы SSH позволяет пользователю
зарегистрировавшись на удаленной машине, работать так же, как если бы
он сидел за ее консолью. Однако перед тем как пользователь увидит
приглашение для ввода имени и пароля, SSH сгенерирует ключ, при помощи
которого будут зашифрованы все данные, которыми будут обмениваться
компьютеры во время SSH-сессии. Таким образом за кулисами незаметно
проводится большая работа.
Поскольку SSH используется для удаленного доступа, на компьютере к
которому осуществляется доступ, должен присутствовать соответствующий
пользовательский аккаунт. Кроме того, на удаленном компьютере должен
быть запущен демон SSH, который делает из компьютера SSH-сервер.
SSH-демон обычно <<слушает>> 22 TCP-порт. Машина за которой сидите вы
и с которой будет осуществляться подключение к SSH-демону удаленного
компьютера называется <<SSH-клиент>>.
Ваша FreeBSD уже сконфигурирована для того что бы вы могли
использовать ее в качестве как SSH-клиента, так и SSH-сервера. Сначала
мы рассмотрим эту конфигурацию, а выясним, что можно сделать для
улучшения ее защищенности.
Я буду использовать два компьютера. На первом, с адресом 10.0.0.1,
будет запущен SSH-демон, к нему я буду удаленно подключаться, а
второй, с адресом 10.0.0.2, будет SSH-клиентом, непосредственно за ним
буду сидеть я. На обеих машинах я создал пользовательский аккаунт
<<genisis>>. Используемая реализация криптосистемы называется
<<OpenSSH>>. Она использует протокол, который обычно пишут заглавными
буквами: <<SSH>>, однако, команды, которые вам придется набирать на
клавиатуре традиционно пишутся строчными: <<ssh>> и <<sshd>>. Обратите
внимание, что параметром для команды ssh может быть как IP-адрес, так
и символическое имя хоста. В этой статье я намеренно буду использовать
для обращения IP-адреса. В следующей части я подробно расскажу о
проблемах встречающихся на пути совместного использования SSH и
символических имен.
Во-первых я должен удостовериться что на компьютере, который будет
выступать в роли сервера, созданы файлы ключей. Для этого на машине с
IP-адресом 10.0.0.1 я выполню следующую команду:
То необходимые ключи уже созданы, однако если я получу вывод подобный
следующему:
moduli ssh_config sshd_config
То сразу становится ясно, что ключей нет и перед тем как запустить
SSH-демона, мне придется заняться их созданием. Если я проявлю
нетерпение и попробую запустить демона перед тем как будут созданы
ключи, я получу отказ сопровождающийся следующим сообщением об ошибке:
sshd
Could not load host key: /etc/ssh/ssh_host_key
Could not load host key: /etc/ssh/ssh_host_dsa_key
Disabling protocol version 1. Could not load host key
Disabling protocol version 2. Could not load host key
sshd: no hostkeys available -- exiting.
Существуют разные способы генерации необходимых ключей. Если вы
продвинутый пользователь и не испытываете проблем при чтении
загрузочных сценариев, то поищите в файле /etc/rc.network строки
относящиеся к ssh. Там можно найти команды генерирующие файлы ключей.
Я продемонстрирую лишь результат работы этого сценария. Самым простым
способом сгенерировать ключи при их отсутствии, будет добавление
следующей строки в файл /etc/rc.conf:
sshd_enable="YES"
Кроме того, наличие этой строки обеспечит запуск демона sshd при
каждой перезагрузке. После сохранения внесенных изменений, я
напечатал:
shutdown now
После того как на экране опять появилось приглашение к вводу команд, я
напечатал слово <<exit>>. Поскольку при этом реинициализируются
загрузочные сценарии, среди прочего на экране я вижу следующие
сообщения:
Starting final network daemons: creating ssh1 RSA host key
Generating public/private rsa1 key pair.
Your identification has been saved in /etc/ssh/ssh_host_key.
Your public key has been saved in /etc/ ssh/ssh_host_key.pub.
The key fingerprint is:
12:d9:3d:f3:95:92:0e:e7:6b:54:09:80:77:a0:3e:cf root@hostname
creating ssh2 RSA host key
Generating public/private rsa key pair.
Your identification has been saved in /etc/ssh/ssh_host_rsa_key.
Your public key has been saved in /etc/ssh/ssh_host_rsa_key.pub.
The key fingerprint is:
4b:cf:7e:af:f1:a8:01:08:64:1b:c0:79:e3:a2:58:78 root@hostname
creating ssh2 DSA host key
Generating public/private dsa key pair.
Your identification has been saved in /etc/ssh/ssh_host_dsa_key.
Your public key has been saved in /etc/ssh/ssh_host_dsa_key.pub.
The key fingerprint is:
22:69:d7:05:23:c6:db:d9:55:2a:20:a3:34:bd:f4:ef root@hostname
Перевод:
(Запуск оставшихся сетевых демонов: создание хостового RSA-ключа ssh1
Генерирование открытого/секретного rsa1 ключа
Идентификационные данные будут сохранены в файле /etc/ssh/ssh_host_key
Ваш открытый ключ будет сохранен в файле /etc/ssh/ssh_host_key.pub
Отпечаток ключа:
12:d9:3d:f3:95:92:0e:e7:6b:54:09:80:77:a0:3e:cf root@hostname
создание хостового RSA-ключа ssh2
Генерирование открытого/секретного rsa ключа
Идентификационные данные будут сохранены в файле /etc/ssh/ssh_host_rsa_key
Ваш открытый ключ будет сохранен в файле /etc/ssh/ssh_host_rsa_key.pub
Отпечаток ключа:
4b:cf:7e:af:f1:a8:01:08:64:1b:c0:79:e3:a2:58:78 root@hostname
создание хостового DSA-ключа ssh2
Генерирование открытого/секретного rsa ключа
Идентификационные данные будут сохранены в файле /etc/ssh/ssh_host_dsa_key
Ваш открытый ключ будет сохранен в файле
/etc/ssh/ssh_host_dsa_key.pub
Отпечаток ключа:
22:69:d7:05:23:c6:db:d9:55:2a:20:a3:34:bd:f4:ef root@hostname)
Давайте посмотрим что тут написано. Видно, что созданы три пары
ключей: для rsa1, для rsa2 и для dsa. Если вы читали предыдущую часть
статьи, то вам уже знакомы аббревиатуры RSA и DSA. Но для чего так
много ключей? Дело в том, что существует две версии SSH и обе их
поддерживает OpenSSH. Неудивительно, что пара ключей rsa1 используется
для SSH версии 1. Из сообщений загрузочного сценария можно понять, что
ssh2 (SSH версии 2) поддерживает RSA и DSA.
Каждый ключ хранится в отдельном файле. Вы легко можете узнать где
находятся открытые ключи - расширение таких файлов <<.pub>>. Каждый
открытый ключ имеет свой уникальный отпечаток. Далее мы еще встретимся
с отпечатками ключей.
Кроме генерации ключей был запущен демон sshd. Проверим это при помощи
утилиты sockstat:
Отлично, теперь хост 10.0.0.1 <<слушает>> 22 порт, давайте посмотрим
что произойдет, если на машине 10.0.0.2 я запущу команду ssh от имени
пользователя genisis:
ssh 10.0.0.1
The authenticity of host '10.0.0.1 (10.0.0.1)' can't be established.
DSA key fingerprint is 22:69:d7:05:23:c6:db:d9:55:2a:20:a3:34:bd:f4:ef.
Are you sure you want to continue connecting (yes/no)? yes
Warning: Permanently added '10.0.0.1' (DSA) to the list of known hosts.
Password:
Перевод:
(аутентичность хоста 10.0.0.1 не может быть установлена.
Отпечаток ключа DSA: 22:69:d7:05:23:c6:db:d9:55:2a:20:a3:34:bd:f4:ef.
Вы уверены что хотите продолжить соединение? Да
Предупреждение: хост "10.0.0.1" (ключ DSA) внесен в список известных хостов.
Введите пароль:)
Сразу после того как я введу верный пароль пользователя genisis, я
получу приглашение командного интерпретатора. Для того что бы
завершить сессию, я наберу "exit":
exit
logout
Connection to 10.0.0.1 closed.
Теперь второй раз:
ssh 10.0.0.1
Password:
Давайте поглядим, что же произошло. В первый раз, когда я
воспользовался SSH, меня попросили сверить отпечаток DSA ключа нашего
сервера. Как только я, убедившись что прелагаемый отпечаток совпадает
с первоначальным, выданным при генерации, напечатал на клавиатуре
<<yes>>, копия открытого ключа нашего сервера была скопирована на
клиент с которого производилось обращение (хост 10.0.0.2):
Когда я в следующий раз обращаюсь к серверу по SSH, открытый ключ
севера сравнивается с копией находящейся на клиенте и поскольку они
одинаковы, клиент считает, что я обращаюсь к аутентичному серверу
(т.е. сервер не подменен злоумышленником - прим. переводчика) и не
предлагает мне проверить отпечаток ключа. Таким образом я просто
получаю запрос на ввод пароля.
Итак, давайте кратко подведем итог - что же происходит у нас за
кулисами:
1. ssh клиент подключается к ssh серверу используя 22 порт.
2. ssh сервер, для подтверждения своей подлинности, посылает ssh
клиенту свой открытый ключ.
3. ssh клиент сравнивает полученный ключ со своей копией. Если копии
ключа у клиента нет, то выдается отпечаток серверного ключа для
того что бы пользователь мог подтвердить его достоверность.
4. Как только подлинность сервера подтверждена, создается секретный
ключ, который используется для шифрования и дешифрования всех
данных которыми обмениваются клиент и сервер.
5. Теперь наступает очередь подтвердить <<достоверность>>
пользователя. По умолчанию выдается приглашение для ввода
пользовательского пароля, который будет передан в зашифрованном
виде.
6. Как только пользователь успешно доказал свою аутентичность, он
получает приглашение интерпретатора команд на удаленной системе.
Все данные передаваемые между клиентом и сервером во время этой
сессии будут зашифрованы.
OpenSSH поддерживает и другие методы аутентификации, однако мы описали
то, что произойдет при использовании стандартной конфигурации
присутствующей на вашей FreeBSD. Вы, вероятно, заметили, что сервер
послал открытый ключ DSA, что означает использование им SSH версии 2.
Это хорошее <<умолчание>>, поскольку вторая версия SSH куда безопаснее
чем первая.
Вы могли заметить, что по умолчанию, для аутентификации пользователю
не требуется пара ключей, ему необходимо только ввести корректный
пароль. Попробуем изменить такое поведение. Во-первых, при помощи
программы ssh-keygen, я сгенерирую пару ключей для пользователя
genisis на машине 10.0.0.2:
ssh-keygen -t rsa
Generating public/private rsa key pair.
Enter file in which to save the key (/home/genisis/.ssh/id_rsa):
Enter passphrase (empty for no passphrase):
Enter same passphrase again:
Your identification has been saved in /home/genisis/.ssh/id_rsa.
Your public key has been saved in /home/genisis/.ssh/id_rsa.pub.
The key fingerprint is:
fd:5a:cc:cf:a9:f0:ea:9c:93:ea:1a:04:48:b1:47:14 genisis@hostname
Перевод:
(Генерирование открытого/секретного rsa ключа.
Введите имя файла ключа (/home/genisis/.ssh/id_rsa):
Введите секретную фразу (нажмите Enter для выбора пустой фразы):
Введите секретную фразу еще раз:
Секретный ключ сохранен в файл /home/genisis/.ssh/id_rsa.
Открытый ключ сохранен в файл /home/genisis/.ssh/id_rsa.pub.
Отпечаток ключа:
fd:5a:cc:cf:a9:f0:ea:9c:93:ea:1a:04:48:b1:47:14 genisis@hostname)
При использовании утилиты ssh-keygen, при помощи ключа <<-t>>, укажите
необходимый способ генерации пары ключей. Я выбрал генерацию пары
ключей по алгоритму RSA для SSH версии 2, поскольку использование SSH
версии 2 более безопасно, чем использование первой версии и, кроме
того, алгоритм RSA более криптостоек, чем DSA. В процессе
генерирования пары ключей, мне пришлось ввести секретную фразу,
которая может быть использована для удостоверения в том, что я являюсь
владельцем сгенерированной пары ключей, или, что более важно,
секретного ключа. Секретная фраза функционально эквивалентна паролю,
однако она должна быть запоминающаяся и более длинная
(подразумевается, что пароли везде разные и поэтому ценность их ниже,
чем ценность пары ключей, которая <<одна на всех>> и удостоверяет вас,
в идеале, повсеместно - прим. переводчика). Как только мне потребуется
использование секретного ключа, мне обязательно предложат ввести
секретную фразу. Если я забуду секретную фразу, то мне придется
сгенерировать новую пару ключей.
Помните, что в паре ключей открытый ключ может быть открыт (например
опубликован у вас на веб-странице - прим. переводчика), а секретный -
должен быть строго засекречен.
Взгляните на права доступа присвоенные файлам ключей по умолчанию:
ls ~/genisis/.ssh
total 4
-rw------- 1 genisis genisis 951 Nov 9 15:00 id_rsa
-rw-r--r-- 1 genisis genisis 247 Nov 9 15:00 id_rsa.pub
Секретный ключ, id_rsa, доступен для чтения только пользователю
genisis, а файл открытого ключа, id_rsa.pub, может прочитать любой
желающий. Если для выяснения типа этих файлов я воспользуюсь утилитой
file, я обнаружу, что это просто текстовые ASCII-файлы, которые можно
поглядеть командой more:
file ~genisis/.ssh/*
id_rsa: ASCII text
id_rsa.pub: ASCII text
more id_rsa.pub
ssh-rsa AAAAB3NzaC1yc2EAAAABIwAAAIEA1gfc4NRnq9K17TLqhhKT3L6feKUttHTJvM054k+WhjI
vsdt4YoeNa3m6lplnOxwOh2w6o+xu+xuiHa/CQkvkAdxFU1ZGtnxtQWV06QJdodUEk55U/0y417TaDF
H1aYjsgPPSpjulKCLQv263C9KOSpjDrjZ74ZLOlQHtsJINY2c= genisis@hostname
Заметьте, что я показал вам только мой открытый ключ, оставив
секретный в тайне.
Простого создания пары ключей недостаточно. Я должен скопировать
открытый ключ в мой домашний каталог на SSH сервере. После того как в
распоряжении SSH сервера окажется мой открытый ключ, всякий раз, когда
я буду обращаться к SSH серверу, он будет запрашивать мой открытый
ключ для того что бы сравнить его с хранящейся копией. Если ключи
совпадут, я буду аутентифицирован и допущен к работе на удаленной
системе.
Для безопасной передачи открытого ключа на сервер, я воспользуюсь
утилитой scp. Эта утилита входит в комплект OpenSSH и позволяет вам
копировать файлы через защищенное соединение. Ее синтаксис очень похож
на синтаксис старой доброй команды cp, различие только в том, что
перед указанием целевого файла на удаленной машине, указывается ее
IP-адрес, а затем, через двоеточие, путь к файлу.
Итак, сидя за машиной 10.0.0.2, я воспользуюсь этой командой для
передачи моего открытого ключа на сервер:
Обратите внимание, что при копировании я проявил осмотрительность и
послал на сервер именно мой открытый ключ, а не секретный - для этого
я выбрал файл с расширением <<.pub>>. Кроме того я поменял название
целевого файла на ~/.ssh/authorized_keys. Перед тем, как началось
собственно копирование, мне пришлось ввести мой пароль на удаленной
системе.
Теперь, когда мой открытый ключ скопирован, я попробую опять
воспользоваться SSH:
ssh 10.0.0.1
В этот раз мне не пришлось водить пароль (все из-за того что при
генерации пары ключей использовалась пустая секретная фраза, иначе
пришлось бы вводить ее - прим. переводчика). Поскольку мой открытый
ключ корректен, я немедленно получил приглашение интерпретатора команд
на сервере. Вам может показаться, что это менее безопасное решение,
ведь пользователю ничего не приходится вводить, однако на самом деле
аутентификация на базе открытых ключей гораздо более защищенная
процедура, чем аутентификация на базе паролей (на самом деле одно дело
- подсмотреть пароль и другое - украсть файл с ключом - прим.
переводчика). Несмотря на это, никогда не следует забывать, что
безопасность системы в первую очередь всегда лежит на ваших плечах.
Точно так же как вы никому не даете свой пароль, никогда не давайте
другим пользователям свой секретный ключ или секретную фразу. Если вы
подозреваете, что ваш секретный ключ был скомпрометирован (т.е. его
узнали посторонние лица - прим. переводчика), используя другую
секретную фразу, немедленно сгенерируйте новую пару ключей, и
скопируйте новый открытый ключ на SSH сервер.
Используя ssh, вы можете <<зайти>> на удаленную машину от имени любого
пользователя. Например, если в данный момент я зарегистрирован в
системе как пользователь biko, но хочу подключиться к серверу под
именем genisis, то для этого я могу воспользоваться ключом <<-l>>:
ssh -l genisis 10.0.0.1
Я могу воспользоваться и другим, аналогичным по функциональности
синтаксисом:
ssh genisis@10.0.0.1
Поскольку в домашнем каталоге пользователя biko нет открытого ключа
пользователя genisis, мне придется ввести пароль. Я должен ввести
пароль пользователя genisis, а не biko. Несмотря на то, что запомнить
<<кто я>> на каждой системе может быть трудновато, зато мне не
обязательно создавать пользователя genisis на обеих машинах.
Давайте посмотрим, что произойдет, если я попробую воспользоваться SSH
под суперпользователем:
Доступ был закрыт, даже если я вводил правильный пароль
суперпользователя. Это очень правильный подход. Так же как вы не
должны локально регистрироваться под суперпользователем, вы тем более
не должны это делать на удаленных системах используя ssh. Если вам
требуются права суперпользователя на удаленной системе, зайдите туда
при помощи ssh под аккаунтом обычного пользователя, имеющего право
становиться суперпользователем (имеется в виду, что следует зайти на
удаленную машину под пользователем входящим в группу wheel, а затем,
воспользовавшись командой su, <<превратиться>> в суперпользователя -
прим. переводчика).
Для того что бы изменить поведение криптосистемы SSH, мы должны
разобраться с соответствующими конфигурационными файлами. Давайте
оставим это для следующего раза. Меж тем, в ознакомительных целях, вы
можете почитать страницы руководства man по темам ssh_config и
sshd_config. Кроме того, вас может заинтересовать список часто
задаваемых вопросов и ответов на них посвященный ssh (см.
http://www.employees.org/~satch/ssh/faq/ssh-faq.html).
Продолжение.
http://www.softerra.ru/freeos/26931/
Эта статья является переводом текста Dru Lavigne (см.
http://www.onlamp.com/pub/a/bsd/2002/11/28/FreeBSD_Basics.html).
Я получил много откликов на мою предыдущую статью, посвященную
использованию SSH. Я хочу поблагодарить всех тех людей, которые
прислали мне интересные ссылки на статьи и программы, посвященные
использованию и настройке SSH. Разумеется, такое огромное количество
информации о SSH не может уместиться в двух статьях, поэтому по ходу
повествования буду давать ссылки на утилиты, которыми вы можете
воспользоваться, а так же на материалы для дополнительного чтения.
В начале этой статьи я коснусь вопросов конфигурирования SSH, а в
конце дам ссылки на утилиты, при помощи которых можно устанавливать
SSH соединение между вашей FreeBSD и рядом других систем.
В прошлой статье мы отметили, что FreeBSD позволяет как устанавливать,
так и принимать SSH соединения в первоначальной конфигурации, т.е.
<<из коробки>>. Кроме того, мы выяснили, что имеется возможность
повысить защищенность системы аутентификации, если использовать
предварительно сгенерированную пару ключей, открытый ключ которой
должен быть скопирован на SSH сервер.
Пакет OpenSSH помимо прочего содержит утилиту ssh-agent. Это так
называемый агент SSH аутентификации (говоря русским языком, это демон
занимающийся кешированием ваших секретных ключей, для того что бы
секретную фразу при обращении к ключу можно было вводить пореже -
прим. переводчика). На сайте IBM DeveloperWorks (см.
http://www-106.ibm.com/developerworks/library/l-keyc.html) есть
отличная серия статей, в которой описывается использование этого
агента. Кроме того в этой серии статей, автор обстоятельно
рассказывает, как в паре работают открытый и секретный ключи, а так же
дает массу полезных ссылок для самостоятельного изучения.
Поскольку система SSH состоит из клиента и сервера, ее
конфигурирование осуществляется при помощи двух файлов. Неудивительно,
что один из них называется ssh_config, а другой - sshd_config. Лишняя
буква <<d>> в названии произошла от слова <<daemon>> (тут
подразумевается SSH демон или, другими словами, SSH сервер), о ней не
следует забывать. Однажды во время одной из моих самых первых попыток
изменения конфигурационных файлов системы SSH, я ошибочно добавил в
конфигурационный файл клиента строку, предназначавшуюся для файла
сервера, после чего долго чесал затылок в раздумьях, отчего же в моей
системе не произошло никаких изменений. Никогда не забывайте, что
<<клиент>> это машина, где вы сидите, а <<сервер>> - компьютер к
которому вы собираетесь обратиться.
Каждый из этих конфигурационных файлов имеет подробнейшую страницу
онлайнового man-руководства, в которой тщательно описана каждая
конфигурационная опция. Поскольку вас могут заинтересовать неописанные
в данной статье опции, обе страницы являются хорошими кандидатами для
прочтения. Давайте начнем с просмотра клиентского конфигурационного
файла, поставляемого с системой. (Некоторые строки разбиты на части
для того, что бы убраться в экран вашего браузера.)
# This is the ssh client system-wide configuration file. See
# ssh_config(5) for more information. This file provides defaults for
# users, and the values can be changed in per-user configuration files
# or on the command line.
# Это основной конфигурационный файл для ssh клиента.
# Для дополнительной информации смотрите man 5 ssh_config.
# В этом файле содержатся <<умолчальные>> настройки для пользователей
# их значения могут быть изменены в конфигурационных файлах конкретных
# пользователей или при помощи параметров командной строки.
# Configuration data is parsed as follows:
# 1. command line options
# 2. user-specific file
# 3. system-wide file
# Any configuration value is only changed the first time it is set.
# Thus, host-specific definitions should be at the beginning of the
# configuration file, and defaults at the end.
# Конфигурационные параметры используются в следующем порядке:
# 1. опции указываемые в командной строке
# 2. пользовательские файлы настройки
# 3. основной файл настройки
# Значение любого конфигурационного параметра присваивается
# однократно при первой его встрече
# Таким образом параметры относящиеся к конкретному хосту
# должны упоминаться в начале файла, остальные параметры могут
# располагаться в конце
# Site-wide defaults for various options
# Умолчальные значения для некоторых опций
# Host *
# ForwardAgent no
# ForwardX11 no
# RhostsAuthentication no
# RhostsRSAAuthentication no
# RSAAuthentication yes
# PasswordAuthentication yes
# BatchMode no
# CheckHostIP no
# StrictHostKeyChecking ask
# IdentityFile ~/.ssh/identity
# IdentityFile ~/.ssh/id_rsa
# IdentityFile ~/.ssh/id_dsa
# Port 22
# Protocol 2,1
# Cipher 3des
# Ciphers aes128-cbc,3des-cbc,blowfish-cbc,cast128-cbc,arcfour, aes192-cbc,aes256-cbc
# EscapeChar ~
# VersionAddendum FreeBSD-20020629
Вероятно вы уже заметили, что каждая строка в этом файле начинается на
символ решетки <<#>> (т.е. это сплошные комментарии). Это не означает,
что SSH клиент вообще не сконфигурирован. Наоборот, в этом файле
демонстрируются <<умолчальные>> параметры конфигурации SSH клиента.
Если вы хотите изменить некий параметр, уберите стоящую перед ним
<<решетку>>, и затем смените его значение на необходимое. Все
возможные значения параметров описаны man-руководстве по ssh_config.
Посмотрев страницу man-руководства, вы заметите, что некоторые
конфигурационные опции применимы только к определенным версиям SSH.
Пользуйтесь SSH версии 2, где это только возможно. Если вы используете
FreeBSD ssh клиент только для подключения к FreeBSD ssh серверу, то
установка по умолчанию гарантирует использование SSH версии 2. Однако,
если вы воспользуетесь своим FreeBSD ssh клиентом для подключения к
серверам, на которых используются системы отличные от FreeBSD, то
существует вероятность, что сервер вынудит вашего клиента использовать
SSH версии 1, поскольку это все на что он способен.
Каковы отличия между первой и второй версией протокола? Если вы
попробуете поискать ответ на этот вопрос в Интернете, то наиболее
частый ответ будет таким: версия <<два>> полностью переписана с учетом
проблем в безопасности, обнаруженных в версии <<один>>. Кроме того эти
две версии отличаются друг от друга списком поддерживаемых алгоритмов:
Версия Функция дайджеста
1 нет
2 HMAC-MD5, HMAC-SHA-1, HMAC-RIPEMD
Теперь вы видите, что вторая версия использует более мощные алгоритмы,
и кроме того обеспечивает обнаружение преднамеренного искажения
данных.
Вот строка из конфигурационного файла:
# Protocol 2,1
Она означает, что первым делом при соединении с сервером, клиент
пытается воспользоваться второй версией протокола, и, если сервер
поддерживает лишь первую версию, клиент переходит на первую версию
протокола.
Если вы поменяете содержимое этой строки на:
Protocol 2
то клиент не будет соединяться с серверами поддерживающими только
первую версию протокола. Помните, что если вы вносите изменения, то
для начала уберите перед строкой символ <<решетки>>, поскольку иначе
изменение будет проигнорировано.
Две строки связаны с шифрами или шифрующими алгоритмами.
Первая строка используется при соединении по SSH версии 1. На странице
man-руководства обращается внимание на то, что использовать алгоритм
DES стоит только в исключительных случаях, когда ничто другое
использовать нельзя. Обратите внимание, что по умолчанию для
шифрования выбран алгоритм 3DES (тройной DES), вместо гораздо более
мощного и эффективного алгоритма blowfish. Это сделано в целях
совместимости, поскольку многие системы не поддерживают blowfish. К
сожалению многие системы поддерживают SSH только первой версии и
только алгоритм DES. Если это ваш случай, то все попытки соединения
потерпят неудачу. Поменяйте в конфигурационном файле первую строку на:
Cipher DES
Если возможно, старайтесь избегать такой ситуации. Несмотря на то, что
это все же гораздо лучше, чем пользование telnet'ом и передача всех
данных открытым текстом, такая конфигурация существенно ослабляет
защищенность SSH соединения.
Вторая строка имеет дело с шифрами, применяемых при соединении по
второй версии SSH. Если вам интересно, что означает аббревиатура
<<cbc>>, то определение данное по адресу
http://searchsecurity.techtarget.com/sDefinition/0,,sid14_gci344945,00.html
может быть полезным для удовлетворения вашего любопытства.
(Конечно интересно. CBC - cipher block chaining - режим шифрования
<<со сцеплением блоков>>. Термин относится к так называемым блочным
шифрам (в которых данные шифруются блоками определенного размера).
Грубо говоря применение таких шифров дает более устойчивый к взлому
шифротекст, из-за того, что каждый блок шифротекста связан с
предыдущим блоком. Это, например, позволяет избегать порождения
одинакового шифротекста для совпадающих блоков открытого текста -
прим. переводчика.) Итак, эта строка содержит упорядоченный список
алгоритмов шифрования. Первый алгоритм из этого списка. который примет
SSH сервер, будет использоваться для шифрования всех данных SSH
сессии.
Имейте в виду, что файл /etc/ssh/ssh_config является глобальным
клиентским конфигурационным файлом. Это значит, что значения
определенные в этом файле, могут быть переопределены при помощи ключей
программы ssh. Кроме того, если вам лень постоянно набирать одни и те
же ключи, то вы можете написать индивидуальный конфигурационный файл в
вашем домашнем каталоге. Например, вместо того что бы пользоваться
ключом <<l>> для соединения под пользователем <<biko>>, я мог создать
файл ~/.ssh/config и написать там следующее:
HostName 10.0.0.1
User biko
Все параметры SSH являются регистрозависимыми, поэтому не забудьте
букву <<U>> в слове <<User>> сделать заглавной.
Теперь, всякий раз когда я пишу ssh 10.0.0.1, мне не надо помнить о
необходимости добавлять ключ <<l>>, я сразу получу запрос на ввод
пользовательского пароля biko.
Если в качестве параметра команды ssh, вместо IP адресов вы
используете имя хоста или FQDN (full qualified domain name - полное
имя хоста - прим. переводчика), то вероятно, можете заметить, что ваш
клиент <<замирает>> какое-то время, которое требуется ему для того что
бы выполнить разрешение имени в IP адрес. Вы можете заметить разницу в
скорости, если клиентской машине добавите сведения о SSH сервере в
файл /etc/hosts.
Теперь давайте слегка сменим направление нашего повествования и
перейдем к конфигурационному файлу SSH сервера /etc/ssh/sshd_config.
Этот файл напоминает файл конфигурации клиента тем, что все строки в
нем закомментированы символом <<#>> и тем, что все конфигурационные
параметры описаны в соответствующей странице man-руководства.
Давайте поговорим о SSH демоне более обстоятельно. Помимо прочего для
нормальной работы SSH сервера в вашей системе должен быть открыт 22
порт (т.е. в настройках брандмауэра (файрволла), если он у вас есть,
должно присутствовать соответствующее правило - прим. переводчика).
Если ваша машина имеет доступ в Интернет, то любой желающий может
обратиться на ваш компьютер по этому порту. Так что, если вы
используете аутентификацию по паролю и злоумышленник подберет
правильные имя пользователя и пароль, то он сможет получить доступ к
вашему компьютеру с правами этого пользователя. Теперь вам ясно,
почему пользователь root не может напрямую входить в систему через
SSH, а так же почему использование системы аутентификации на базе
открытого и секретного ключа совместно с секретной фразой гораздо
надежнее парольной защиты?
Важно пользоваться свежей версией SSH демона. Для того что бы
проверить, какая версия SSH установлена на вашей системе, следует, при
помощи утилиты telnet, подключиться к 22 порту сервера. Если вы сидите
за сервером, нижеприведенная команда должна сработать, иначе укажите
параметром telnet'а IP адрес сервера.
telnet localhost 22
Trying ::1...
Connected to localhost.
Escape character is '^]'.
SSH-1.99OpenSSH_3.4p1 FreeBSD-20020702
quit ^^^^^
Connection closed by foreign host.
Удостоверьтесь, что используемая вами версия OpenSSH не ниже 3.3 (на
самом деле следует удостовериться, что используемая версия самая
свежая, рисковать в таких делах не стоит - прим. переводчика). Любые
программы, включая программы предназначенные для обеспечения
безопасности, потенциально уязвимы, поэтому очень важно использовать
программное обеспечение, пропатченное на предмет исправления всех
известных на текущий момент уязвимостей. Это особенно важно для
программ типа OpenSSH, т.е. программ, которые используются для
удаленного доступа к компьютерам.
Если вы регулярно пользуетесь cvsup и portupgrade, то ваша FreeBSD
скорее всего пребывает во вполне свежем виде. Кроме того не будет
лишним, подписаться на лист рассылки
security-notifications@freebsd.org в котором сообщаются все последние
обнаруженные уязвимости в системе FreeBSD. На официальном сайте
проекта FreeBSD опубликованы инструкции как подписаться на этот лист,
а так же список последних обнаруженных уязвимостей (см.
http://www.freebsd.org/security).
Кроме того, вы можете установить самую новую версию OpenSSH, из
коллекции портов /usr/ports/security/openssh (я, например, так и
делаю, поскольку на мой взгляд обновить OpenSSH из порта несколько
проще, чем пересобирать всю систему из-за появления очередной
уязвимости - прим. переводчика). Эта статься подготовлена с
использованием FreeBSD 4.7-RELEASE с OpenSSH включенной в базовую
поставку системы.
Существует несколько путей контроля того, кто и откуда будет иметь
доступ к вашему демону SSH. Во-первых это брандмауэр. Если вам не
хочется что бы кто-нибудь забрался на ваш SSH сервер через Интернет,
поместите его за брандмауэр, в котором будут установлены правила
запрещающие доступ к 22 порту. Однако, если у вас есть пользователи,
которые пользуются SSH сервером через Интернет, вам напротив придется
добавить правило разрешающее доступ к 22 порту. Если клиенты имеют
статические IP адреса, то можно задать правила на доступ только с
указанных IP адресов.
Во-вторых можно откорректировать содержимое конфигурационного файла
/etc/ssh/sshd_config. Давайте для начала сделаем баннер (на мой взгляд
это глупая и вредная практика, поскольку, все эти предупреждения
только раззадорят потенциального <<хакера>> - прим. переводчика). Сам
по себе баннер не добавит вашей системе защищенности, однако с его
помощью можно предупредить пользователей о недопустимости
несанкционированных действий, кроме того его наличие может оказать
определенное влияние, если вам все же придется разбираться с
провайдером или органами власти по поводу незаконных действий
злоумышленников.
This is a private system!!! All connection attempts are
logged and monitored. All unauthorized connection
attempts will be investigated and
handed over to the proper authorities.
Это частная система! Все соединения записываются и отслеживаются.
Все несанкционированные попытки доступа будут расследованы и
переданы куда следует.
Теперь скажем демону что бы он показывал наш баннер, для этого
замените следующую строку в файле /etc/ssh/sshd_config с:
#Banner /some/path
на
Banner /etc/ssh/banner
Баннер будет показываться перед запросом пароля или секретной фразы.
Имейте в виду, что баннер показывается только клиентами использующими
протокол SSH версии 2, в версии 1 баннеры не поддерживаются.
Если ваши клиенты не имеют постоянных IP адресов или осуществляют
доступ с нескольких компьютеров, то указать в правилах брандмауэра IP
адреса, с которых будет можно обращаться к SSH серверу, будет не так
просто. К счастью, при помощи конфигурационного параметра AllowUsers,
вы можете ограничить круг пользователей, которые смогут авторизоваться
на вашем SSH сервере. Эта строка устанавливает разрешения для
пользователей biko и genisis:
AllowUsers genisis biko
При попытке соединения с SSH сервером, пользователи не включенные в
этот список, так же будут получать приглашение на ввод пароля, однако
несмотря на то что даже, если они введут правильные имя пользователя и
пароль, они все равно получат сообщение об ошибке авторизации.
Сообщение об ошибке авторизации будет выведено на консоль демона SSH,
скопировано в /var/log/messages и послано администратору в составе
ежедневного отчета о состоянии безопасности системы. Как вы убедились,
это очень полезная опция, для того что бы вставить ее в
конфигурационный файл. Точность никогда не бывает лишней, поэтому если
ваши пользователи всегда пользуются одной и той же машиной, то для
ужесточения ограничений, можно сделать так:
AllowUsers genisis@10.0.0.2 biko@10.0.0.2
Однако не увлекайтесь подобными вещами, если ваши пользователи сидят
за несколькими компьютерами или не имеют статических IP адресов.
Например, если пользователь genisis попробует подключиться с IP адреса
192.168.0.1, то он получит сообщение о запрете соединения.
В зависимости от ваших пожеланий, вы можете вставить в
конфигурационный файл следующие строки:
ClientAliveInterval 120
ClientAliveCountMax 2
Первая строка указывает на то, что если клиент не пошлет серверу
никаких данных на протяжении 120 секунд, то сервер пошлет ему запрос
на который клиент должен ответить для того что бы обозначить свое
присутствие. Во второй строке сказано, что если после 4 минут (120
секунд * 2) клиент не пошлет серверу ответ, то сервер закроет
соединение.
Кроме этого вы можете поменять параметр этой строки:
#Port 22
на какой-нибудь другой номер порта. Если вы поменяете номер порта, не
забудьте удостовериться, что ваши клиенты знают, какой порт они должны
использовать для того что бы подключиться к SSH серверу. Они могут
указать его или в командной строке ssh или в конфигурационном файле
ssh_config. Таким способом вы чуть-чуть увеличиваете безопасность
системы, предотвращая случайные или преднамеренные попытки подключения
и сканирования 22 порта, однако это не поможет если хитрый
злоумышленник подключится к вашему порту программой telnet - он сразу
увидит что на нем <<висит>> SSH демон.
Если вы не хотите что бы весь мир узнал, что ваш SSH сервер работает
на FreeBSD, поменяйте этот параметр:
# VersionAddendum FreeBSD-20020629
Вы наверное помните, что было выдано на экран, когда я,
воспользовавшись telnet'ом соединился с 22 портом моего SSH сервера.
Если я поменяю этот параметр на нечто подобное:
VersionAddendum For Authorized Users Only!!!!
то результатом обращения при помощи telnet'а будет следующая строка:
SSH-2.-OpenSSH_3.4p1 For Authorized Users Only!!!!
Обратите внимание, что несмотря на это версия SSH демона все равно
выводится на экран. Это еще один повод для того, что бы всегда
пользоваться только самой свежей и пропатченной версией сервера,
поскольку любой кто умеет пользоваться telnet'ом может узнать какие
эксплоиты можно применить к вашему серверу.
Если компьютер на котором установлен SSH сервер имеет несколько IP
адресов, то на всех них на 22 порту будут приниматься SSH соединения.
Если вам требуется что бы соединения принимались только на одном из
адресов, воспользуйтесь этим параметром:
#ListenAddress 0.0.0.0
Замените <<0.0.0.0>> на желаемый IP адрес.
Не забывайте о том, что если вы поменяли конфигурационный файл демона
SSH, то для того что бы изменения вступили в силу, необходимо послать
демону сигнал <<1>>:
killall -1 sshd
После информирования sshd о изменениях, всегда следует проверить их
при помощи клиентской программы ssh. Например, если я добавлю в
конфигурационный файл следующую строку:
Allowusers genisis biko
но несмотря на это обнаружу, что пользователь dlavigne все еще может
удаленно входить в систему, то самое время поискать синтаксическую
ошибку в добавленной строке. Довольно просто забыть, что
конфигурационные параметры регистрозависимы. В данном случае правильно
было бы написать <<AllowUsers>>, в то время как написание
<<Allowusers>> тихо игнорируется и приводит к неприятностям. Вы ведь
не хотите через полгодика случайно узнать, что любой желающий может
получить удаленный доступ к серверу, в то время как вы думаете, что
это могут делать всего два человека?
Наконец, несколько полезных ссылок:
* Десятка частозадаваемых вопросов от автора книги <<SSH The
Definitive Guide>> (см.
http://sysadmin.oreilly.com/news/sshtips_0101.html)
* Список бесплатных SSH клиентов и серверов для разнообразных
операционных систем (см. http://www.freessh.org/)
* Руководство о конфигурировании SSH сервера на аппаратуре Cisco
(см. http://www.cisco.com/en/US/products/sw/iosswrel/ps1835/products_configuration_guide_chapter09186a00800ca7d5.html)
Vova
