SSH


По ссылке http://www.adagio-studio.ru/mural-wallpaper/dorogie/ купить дорогие элитные обои в Москве.

Одна из самых сильных сторон UNIX — простота удаленного администрирования. Неважно, где находится сервер — перед вами или в подвале запертой лаборатории посреди совершенно секретного военного оборудования, охраняемого свирепыми собаками и бешеными горностаями. Если к нему есть доступ по сети, то им можно управлять, как если бы он находился прямо перед вами.

Многие годы стандартным средством для доступа к удаленному серверу был telnet(1). telnet хорош. С его помощью можно соединиться с произвольным TCP-портом системы и непосредственно «разговаривать» с сервером по сети. (Далее в этой главе такая возможность будет применена для тестирования различных сервисов.) Однако telnet, как протоколу удаленного администрирования, сопутствует одна серьезнейшая проблема: в большинстве его реализаций все данные, посылаемые по этому протоколу, передаются в нешифрованном виде. Любой владелец анализатора пакетов (packet sniffer), прослушивающий ваше соединение, может заполучить ваши имя пользователя, пароль и любую другую информацию, которая передается в рамках сеанса связи. При использовании telnet даже самая лучшая схема выбора паролей в мире не сможет защитить ваши имя пользователя и пароль. Злоумышленники размещают анализаторы пакетов повсюду; я встречал их в небольших локальных сетях, в юридических фирмах, где работают с документами государственной важности, в домашних персональных компьютерах и в магистралях Интернета. Единственная защита от анализаторов пакетов — управлять соединениями так, чтобы злоумышленники не смогли извлечь секретную информацию. Именно здесь на помощь приходит SSH, или secure shell.

В значительной степени SSH работает так же, как и telnet: он предоставляет отлично конфигурируемое терминальное окно на удаленном хосте. Однако, в отличие от telnet, все данные, посылаемые по этому протоколу, шифруются. SSH обеспечивает не только защиту паролей от анализатора, но и шифрование набираемых команд и их вывода. Хотя у telnet есть несколько преимуществ над SSH (он требует меньше процессорного времени и проще в настройке), его преимущества нивелируются преимуществами SSH в обеспечении безопасности. Кроме того, SSH обладает целым рядом таких особенностей, как возможность создавать шифруемые туннели для любого протокола. Как и telnet, SSH может работать на всех современных версиях UNIX и даже в Microsoft Windows.

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

Чтобы использовать SSH на машине, работающей под управлением FreeBSD, должен быть запущен сервер SSH, а на рабочей станции — клиент SSH.

Сервер SSH: sshd(8)

Демон sshd(8) принимает запросы SSH, поступающие из сети, на порт TCP с номером 22. Чтобы разрешить запуск sshd во время загрузки, добавьте в файл /etc/rc.conf следующую строку:

sshd_enable="YES"

Выполнив эту настройку, можно использовать сценарий /etc/rc.d/sshd для запуска и останова SSH. Останов демона SSH не вызывает прекращение сеансов связи SSH, которые к этому моменту уже запущены; эта команда только лишь воспрепятствует установлению новых соединений.

В отличие от других протоколов, рассматриваемых в этой книге, SSH трудно тестировать вручную. Можно лишь убедиться, что демон sshd запущен. Для этого надо с помощью telnet подключиться к ТСР-порту, на котором предположительно работает SSH.

Telnet сначала предпринимает попытку подключиться с использованием адреса IPv6 локального компьютера (1), затем с использованием адреса IPv4 (2) и преуспевает в этом. Попытка подключения увенчалась успехом, и мы видим, что демон, прослушивающий этот порт, сам себя называет как SSH версии 2, реализует OpenSSH 4.4p1 в системе FreeBSD, версии 20060930 (3). (Протокол SSH имеет две версии, 1 и 2. Всегда используйте версию 2.) Всю эту информацию можно получить с помощью простой команды telnet, но это все, что sshd предлагает без ограничений. Если вы не в состоянии шифровать пакеты вручную, «на лету», то дальше вам не удастся продвинуться ни на шаг. Нажмите комбинацию клавиш Ctrl-], чтобы закрыть соединение, а затем Ctrl-C, чтобы прервать работу telnet и вернуться в командную строку.

Ключи SSH и их цифровые отпечатки

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

SSH версии 1 использует файлы ключей /etc/ssh/ssh_host_key, /etc/ssh/ssh_host_key.pub, /etc/ssh/ssh_host_rsa_key и /etc/ssh/ssh_host_rsa_key.pub. SSH версии 1 не гарантирует полную безопасность, но он намного безопаснее, чем telnet. SSH версии 2 наряду с ключами RSA использует ключи DSA /etc/ssh/ssh_host_dsa_key и /etc/ssh/ssh_host_dsa_key.pub.

Файлы с расширением .pub содержат открытые ключи (public keys). Это те самые ключи, которые sshd передает клиентам, пытающимся установить соединение. Это дает клиентам возможность убедиться, что сервер, к которому они пытаются подключиться, действительно является тем сервером, за который он себя выдает. (В прошлом злоумышленникам удавалось обманывать пользователей, подставляя им поддельные машины, чтобы перехватить имена их учетных записей и пароли.) Загляните в один из файлов с открытыми ключами; он довольно велик. Если пользователю предложить убедиться в том, что сервер предлагает правильный ключ, то его длина помешает проверить все символы до единого даже самым одержимым пользователям.

К счастью, SSH позволяет сгенерировать цифровой отпечаток ключа, который намного короче соответствующего ему ключа. Обладая цифровым отпечатком, вы не сможете шифровать трафик или договориться о параметрах подключения, но вероятность того, что два независимых ключа будут иметь одинаковый отпечаток, крайне низка. Чтобы сгенерировать отпечаток открытого ключа, следует выполнить команду ssh-keygen -lf файл_ключа.pub.

# ssh-keygen -lf /etc/ssh/ssh_host_dsa_key.pub
1024 31:28:4b:6e:aa:23:63:2e:9a:6b:44:00:9f:fd:28:21
/etc/ssh/ssh_host_dsa_key.pub

Первое число, 1024, показывает число битов в ключе. Число 1024 было стандартным в 2007 году, однако я полагаю, что в ближайшие несколько лет с ростом мощности компьютеров оно увеличится до 2048. Шестнадцатеричная строка, начинающаяся с 31 и заканчивающаяся на 21, — это цифровой отпечаток открытого ключа. Строка достаточно длинная, тем не менее она намного короче самого ключа. Скопируйте этот отпечаток с оригинального сервера и поместите его куда-нибудь, где он будет доступен клиентам, — на веб-страницу или на лист бумаги. Используйте этот ключ, чтобы убедиться в подлинности сервера при первом подключении к нему.

Конфигурирование демона SSH

Даже при том, что sshd распространяется со вполне приемлемой конфигурацией, по мере изучения всех особенностей sshd(8) у вас может возникнуть желание подрегулировать некоторые настройки. Конфигурационный файл /etc/ssh/sshd_config содержит все параметры настройки со значениями по умолчанию, закомментированные с помощью символа решетки (#). Если вам потребуется изменить значение выбранного параметра, раскомментируйте строку и измените значение.

Мы не будем рассматривать все имеющиеся параметры настройки sshd; для этого потребовалось бы написать отдельную книгу. Более того, OpenSSH продолжает развиваться настолько быстро, что такая книга устаревала бы, еще не достигнув книжной полки. Поэтому мы сконцентрируемся на изменениях, выполняемых администраторами наиболее часто.

После изменения конфигурации демона SSH его следует перезапустить командой /etc/rc.d/sshd restart.

VersionAddendum FreeBSD-20061110

Значение параметра VersionAddendum появляется в имени сервера при попытке подключиться к порту TCP демона sshd. Некоторые администраторы рекомендуют изменить это значение, чтобы скрыть версию операционной системы. Однако операционную систему легко идентифицировать с помощью определенных приемов, выполняя обмен пакетами с хостом, поэтому изменение данного параметра не стоит потраченного на это времени. (С другой стороны, стоит сменить имя параметра VersionAddendum на DrunkenBadgerSoftware, хотя бы ради смеха.)

Port 22

По умолчанию sshd(8) прослушивает порт TCP с номером 22. При желании вы можете указать другой, нестандартный порт. Если нужно, чтобы sshd прослушивал несколько портов (например, в дополнение к порту 22 еще и порт 443, чтобы обойти ошибки в настройке брандмауэра), можно добавить дополнительные определения параметра Port в отдельных строках:

Port 22
Port 443

Protocol 2

Любая современная версия SSH по умолчанию поддерживает только версию 2 протокола SSH. Протокол SSH версии 1 не обеспечивает должный уровень безопасности, а клиенты с поддержкой протокола SSH версии 2 теперь входят в состав наиболее распространенных систем. Однако демон sshd(8) до сих пор обладает поддержкой протокола версии 1, и при необходимости можно разрешить эту поддержку, хотя она и не обеспечивает достаточно высокий уровень безопасности. Перечислите в порядке предпочтений поддерживаемые версии протоколов, разделяя их запятыми.

ListenAddress 0.0.0.0

По умолчанию sshd(8) ожидает входящие запросы на всех IP-адресах, присвоенных сетевым интерфейсам машины. Если необходимо ограничить диапазон прослушиваемых адресов (например, на сервере клеток), сделать это можно так:

ListenAddress 192.168.33.8

Если требуется, чтобы sshd прослушивал несколько IP-адресов, определите несколько параметров ListenAddress в отдельных строках.

SyslogFacility AUTH и LogLevel INFO

Эти два параметра управляют способом протоколирования информации о соединениях. Подробнее о протоколировании рассказывается в главе 19.

LoginGraceTime 2m

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

PermitRootLogin no

He разрешайте пользователям регистрироваться на сервере с учетной записью root. Они должны выполнять вход через SSH как обычные пользователи, а затем получать привилегии root с помощью su(1). Разрешив прямой вход в систему с учетной записью root, позднее вы не сможете определить, чьи действия стали источником проблем, кроме того, злоумышленникам будет проще замести следы.

MaxAuthTries 6

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

AllowTcpForwarding yes

SSH дает пользователям возможность перенаправлять любой трафик на произвольные порты TCP/IP удаленной системы. Значение no запретит такую возможность. Однако если у пользователя есть доступ к командному интерпретатору, он сможет установить собственный механизм перенаправления данных (TCP port forwarder) и обойти это ограничение.

X11Forwarding yes

В UNIX-подобных системах для отображения графического интерфейса программ используется протокол X11 (или X). В X дисплей отделен от физической машины. Вы можете, например, запустить веб-броузер на одной машине, а результаты отображать на другой.

История безопасности X уходит корнями в далекое прошлое, поэтому многие администраторы отключают этот параметр без дополнительных размышлений. Однако запрет на перенаправление X через SSH не означает запрет на перенаправление вообще. Большинство пользователей в случае запрета перенаправления X через SSH просто перенаправляют X через нешифруемое соединение TCP/IP с помощью встроенных сетевых механизмов X или программных продуктов сторонних производителей, что в большинстве случаев гораздо хуже, чем разрешить перенаправление X через SSH. Если на вашем сервере установлены библиотеки X и клиентские программы, пользователь сможет перенаправлять трафик X любым из способов; поэтому лучше разрешить перенаправление через SSH. Если программное обеспечение X не установлено, то этот параметр ни на что не влияет.

MaxStartups 10

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

Banner /some/path

Баннер (banner) — это сообщение, которое выводится перед тем, как пользователю будет предоставлена возможность аутентифицироваться. Чаще всего этот параметр используется для вывода предупреждений о законности. По умолчанию баннер не используется.

Subsystem sftp /usr/libexec/sftp-server

SSH позволяет безопасно копировать файлы из одной системы в другую с помощью scp(1). Программа scp прекрасно справляется с возложенными на нее обязанностями, но не особо дружелюбна к пользователям. Сервер sftp обеспечивает FTP-подобный интерфейс для передачи файлов, что сокращает время обучения пользователя и при этом гарантирует высокий уровень безопасности.

Управление доступом пользователей через SSH

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

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

Например, параметр AllowGroups позволит ограничить круг пользователей, обладающих правом входа в систему через SSH, указанными группами, которые определены в файле /etc/group (глава 7). Если этот параметр определен, а пользователь не принадлежит ни к одной из допустимых групп, он не сможет войти в систему. Группы в списке должны отделяться пробелами:

AllowGroups wheel webmaster dnsadmin

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

Параметр DenyGroups противоположен параметру AllowGroups. Пользователи из перечисленных здесь системных групп не смогут войти в систему. Указанные группы должны быть их главными группами, то есть должны быть представлены в /etc/master.passwd, а не просто в /etc/group. Это ограничение делает параметр DenyGroups менее полезным, чем может показаться на первый взгляд; для достижения желаемого эффекта будет недостаточно определить универсальную группу nossh и просто добавить в нее пользователей, эта группа должна быть главной для них. Явное перечисление допустимых групп обеспечивает более полезную политику безопасности.

Наконец, параметр DenyUsers содержит перечень пользователей, которым должно быть отказано в доступе. Данный параметр можно использовать, чтобы явно ограничить доступ пользователям из той группы, которой разрешен вход в систему.

Как эти параметры влияют на права доступа пользователя, входящего в несколько групп? Например, пользователь входит в группу, присутствующую в списке AllowGroups, и в группу из списка DenyGroups. Что произойдет в этом случае? Демон SSH проверяет значения этих параметров в следующем порядке: DenyUsers, AllowUsers, DenyGroups и AllowGroups. Учитывается первое совпадение. Предположим, что я член группы wheel, и в файле sshd_config присутствует следующий фрагмент:

DenyUsers: mwlucas
AllowGroups: wheel

Я не смогу войти в эту систему через SSH, потому что значение параметра DenyUsers проверяется до значения параметра AllowGroups.

Комментарии запрещены.