18.2 Шифрование удалённого доступа с помощью OpenSSH (Using OpenSSH for Encrypted Remote Access)

На заре UNIX/Linux мы использовали разнообразные инструменты для установления сетевых соединений между системами. Для доступа к командной строке удалённой системы можно было применять Telnet, rlogin или rshell. Для копирования файлов между системами — rcp или FTP. Однако у этих утилит имелся один очевидный недостаток: сетевые службы Telnet, rlogin, rcp, rshell и FTP передают данные в виде открытого текста (clear text). Любой, кто запустит сниффер, без труда перехватит имена пользователей, пароли, а также содержимое передаваемых данных.

Предположим, я удалённо подключился к своей системе Linux через Telnet. После аутентификации на удалённой системе я решил перейти к учётной записи root с помощью команды su, чтобы выполнить ряд задач. Если бы в этот момент кто-то прослушивал сеть, он легко перехватил бы следующие данные:

• моё имя пользователя и пароль;
• пароль суперпользователя root.

Это недопустимо! Злоумышленник получил бы всё необходимое для неограниченного доступа к моей системе Linux.

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

• как работает OpenSSH;
• настройка OpenSSH;
• туннелирование трафика через SSH;
• настройка SSH для аутентификации с открытым ключом.

Начнём с обсуждения принципа работы OpenSSH.

Как работает OpenSSH (How OpenSSH Works)

OpenSSH предоставляет функциональность Telnet, rlogin, rsh, rcp и FTP, но делает это с использованием шифрования. Для этого OpenSSH включает следующие компоненты с поддержкой шифрования:

• sshd — демон SSH, обеспечивающий удалённый доступ к командной строке.
• ssh — клиент SSH для подключения к демону sshd на другой системе.
• scp — утилита для защищённого копирования файлов между системами.
• sftp — утилита для защищённой передачи файлов между системами по протоколу FTP.
• slogin — утилита для удалённого доступа к командной строке (альтернатива ssh).

Для установления защищённого соединения OpenSSH использует одновременно шифрование с закрытым/открытым ключом и шифрование с секретным ключом. Сначала клиент SSH устанавливает соединение с системой, на которой работает сервер SSH, через IP-порт 22. Затем сервер SSH отправляет клиенту свои открытые ключи. Для хранения закрытого и открытого ключей, идентифицирующих хост с сервером SSH, используется пара хостовых ключей. Ключи хранятся в следующих файлах:

• Закрытый ключ: /etc/ssh/ssh_host_key
• Открытый ключ: /etc/ssh/ssh_host_key.pub

Клиентская система получает открытый ключ сервера SSH и проверяет, есть ли у неё уже копия этого ключа. Клиент SSH хранит ключи от других систем в следующих файлах:

• /etc/ssh/ssh_known_hosts
• ~/.ssh/known_hosts

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

Примечание

В SSH версии 2 ряд вещей работает иначе. Прежде всего, используются другие файлы хостовых ключей на сервере: вместо /etc/ssh/ssh_host_key применяются файлы /etc/ssh/ssh_host_rsa_key и /etc/ssh/ssh_host_dsa_key (вместе с соответствующими открытыми ключами). Выбор пары ключей зависит от того, какой механизм шифрования (RSA или DSA) настроен на клиенте и сервере. Кроме того, секретный ключ в SSH версии 2 фактически не передаётся от клиента к серверу. Вместо этого применяется протокол согласования ключей Диффи–Хеллмана (Diffie-Hellman key agreement) для выработки общего секретного ключа без его передачи по сети.

После установления защищённого канала и аутентификации пользователя на сервере SSH данные могут безопасно передаваться между обеими системами.

Теперь, когда вы понимаете, как устанавливаются SSH-соединения, необходимо научиться настраивать OpenSSH.

Настройка OpenSSH (Configuring OpenSSH)

Для использования ssh необходимо сначала установить пакет openssh из дистрибутивного носителя. Этот пакет включает демон sshd и клиент ssh. OpenSSH обычно устанавливается по умолчанию в большинстве дистрибутивов Linux. Для проверки установки воспользуйтесь инструментом управления пакетами на ваш выбор.

Процесс настройки OpenSSH предполагает конфигурирование как сервера SSH, так и клиента SSH. Демон sshd настраивается с помощью файла /etc/ssh/sshd_config. Клиент ssh, в свою очередь, настраивается с помощью файла /etc/ssh/ssh_config или ~/.ssh/ssh_config.

Рассмотрим сначала настройку сервера SSH (sshd). Файл /etc/ssh/sshd_config содержит множество директив. Хорошая новость состоит в том, что параметры по умолчанию, установленные после установки пакета openssh, прекрасно работают в большинстве ситуаций. Для запуска sshd изменений в файл sshd_config потребуется немного. Наиболее полезные параметры этого файла приведены в табл. 18-1.

Параметр	Описание
AllowUsers	Ограничивает вход на сервер SSH только перечисленными пользователями. Задаётся список пользователей через пробел.
DenyUsers	Запрещает вход через сервер SSH перечисленным пользователям. Задаётся список пользователей через пробел.
HostKey	Задаёт файл закрытого хостового ключа для SSH. Для SSH версии 1 по умолчанию используется /etc/ssh/ssh_host_key, для SSH версии 2 — /etc/ssh/ssh_host_rsa_key и /etc/ssh/ssh_host_dsa_key. Можно настроить sshd на использование нескольких файлов хостовых ключей. Если для файла ключа установлены права на чтение или запись для группы или прочих пользователей, sshd откажется его использовать.
ListenAddress	Если хост с sshd имеет несколько IP-адресов, этот параметр позволяет ограничить прослушивание только указанными адресами. Синтаксис: ListenAddress IP-адрес:порт.
PermitRootLogin	Задаёт, разрешена ли аутентификация на сервере SSH от имени root.
Port	Задаёт порт, на котором демон sshd ожидает входящие SSH-запросы.
Protocol	Задаёт версию SSH. Допустимые значения: 1 — SSH версии 1; 2 — SSH версии 2; 2,1 — поддержка обеих версий с предпочтением версии 2.

Табл. 18-1. Параметры файла sshd_config.

Клиент ssh в системе Linux настраивается с помощью файла /etc/ssh/ssh_config. Этот файл задаёт параметры по умолчанию для всех пользователей, запускающих ssh в системе. Пользователь может переопределить эти параметры с помощью файла ~/.ssh/ssh_config в своём домашнем каталоге. Приоритет параметров конфигурации клиента ssh следующий:

1. Параметры командной строки, указанные при вызове команды ssh.
2. Параметры в файле ~/.ssh/ssh_config.
3. Параметры в файле /etc/ssh/ssh_config.

Как и в случае с демоном sshd, параметры по умолчанию в файле ssh_config обычно работают без обширной настройки. Тем не менее наиболее полезные параметры для настройки поведения клиента ssh перечислены в табл. 18-2.

Параметр	Описание
Port	Задаёт номер порта для подключения к серверу SSH при инициировании SSH-запроса.
Protocol	Задаёт версию SSH. Допустимые значения: 1 — SSH версии 1; 2 — SSH версии 2; 2,1 — поддержка обеих версий с предпочтением версии 2.
StrictHostKeyChecking	При установке SSH-соединения сервер SSH отправляет клиенту свой открытый ключ. По умолчанию при первом подключении к данному серверу пользователю предлагается принять открытый ключ сервера. Это поведение можно изменить с помощью параметра StrictHostKeyChecking в файле ssh_config. При значении yes клиент устанавливает соединения только с серверами SSH, открытый ключ которых уже добавлен в файл ~/.ssh/known_hosts или /etc/ssh/ssh_known_hosts. В этом случае для подключения к новому серверу SSH необходимо вручную добавить его ключ в один из указанных файлов.
User	Задаёт имя пользователя для входа на сервер SSH.

Табл. 18-2. Параметры файла ssh_config.

Разумеется, прежде чем подключаться к серверу SSH, необходимо открыть порт 22 в межсетевом экране на уровне хоста системы, на которой работает sshd. Например, на рис. 18-4 показан модуль YaST Firewall, загруженный в системе SUSE Linux Enterprise Server 10 и настроенный на пропуск SSH-трафика.

Рис. 18-4. Настройка брандмауэра для пропуска SSH-трафика.

После настройки брандмауэра можно загрузить клиент ssh на локальном компьютере и подключиться к демону sshd на удалённой системе Linux командой ssh –l имя_пользователя IP-адрес.

Совет

Не забывайте параметр –l. Если его опустить, клиент SSH попытается аутентифицироваться на удалённой системе с теми же учётными данными, что и на локальной. Если учётные данные на клиенте и сервере совпадают — аутентификация пройдёт. Если нет — войти не удастся.

Например, чтобы подключиться к удалённой системе Linux с именем fedora (IP-адрес 10.0.0.85) от имени пользователя student с локального компьютера, следует ввести в командной строке ssh –l student fedora. Это показано на рис. 18-5.

Рис. 18-5. Подключение к удалённой системе через SSH.

Обратите внимание на рис. 18-5: при первом подключении к данному серверу SSH клиент предложил принять открытый ключ хоста fedora. После принятия ключа была выполнена аутентификация на удалённой системе от имени пользователя student (заметьте изменение приглашения командной строки). Теперь я имею полный доступ к командной строке на fedora и могу выполнять любые задачи, как если бы находился непосредственно за консолью удалённой системы. Для закрытия соединения достаточно ввести exit в командной строке.

Совет

На рабочих станциях Windows клиент ssh не предусмотрен. Для подключения к серверу SSH Linux с рабочей станции Windows можно загрузить из интернета клиент SSH PuTTY.exe.

Попрактикуемся в работе с SSH в следующем упражнении.

Упражнение 18-1. Работа с SSH

В этом упражнении вы настроите демон sshd в своей системе Linux, а затем подключитесь к нему с помощью клиента SSH на другой системе Linux.

Примечание

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

Выполните следующие шаги:

1. Настройте систему с сервером SSH: a. Загрузите систему Linux, которая будет выполнять роль сервера SSH, и войдите в систему как обычный пользователь. b. Откройте терминальный сеанс. c. Переключитесь на учётную запись root командой su – и введите пароль root. d. В командной строке с помощью менеджера пакетов убедитесь, что пакет openssh установлен. e. В командной строке введите vi /etc/ssh/sshd_config. f. Найдите параметр PermitRootLogin. Если он закомментирован, удалите символ # в начале строки. g. Нажмите ins, затем установите PermitRootLogin в значение no. h. Нажмите esc, затем введите :exit для сохранения изменений и выхода из редактора. i. В командной строке введите service sshd restart для перезапуска службы SSH и применения изменений. j. При необходимости откройте порт 22 в брандмауэре хоста системы с сервером SSH. Шаги зависят от конкретного дистрибутива.
2. Установите SSH-соединение с клиентской системы: a. Загрузите вторую систему, которая будет выполнять роль клиента SSH, и войдите в систему как обычный пользователь. b. Откройте терминальный сеанс. c. Откройте SSH-сеанс с первой системой Linux командой ssh –l имя_пользователя IP-адрес_сервера_SSH в командной строке. Например, для подключения к системе с IP-адресом 192.168.1.125 от имени пользователя student введите: ssh –l student 192.168.1.125. d. При появлении запроса введите yes для принятия открытого ключа сервера SSH. e. Введите пароль пользователя, указанного на сервере SSH. f. Введите exit в командной строке для выхода из удалённой системы.
3. Попрактикуйтесь в использовании утилит SSH с клиентской системы: a. Выполните команду ifconfig на удалённой системе через SSH командой ssh –l имя_пользователя IP-адрес_сервера_SSH /sbin/ifconfig. b. Введите пароль удалённого пользователя при появлении запроса. Должна отобразиться конфигурация сетевых интерфейсов удалённой системы. Заметьте, что соединение автоматически закрылось после завершения команды. c. Скопируйте файл через защищённое SSH-соединение: i. Создайте новый файл в домашнем каталоге пользователя: echo "This is my new file." > ~/mytestfile.txt. ii. Скопируйте файл в домашний каталог удалённого пользователя командой scp ~/mytestfile.txt имя_пользователя@IP-адрес_сервера_SSH:. iii. Введите пароль удалённого пользователя при появлении запроса. Файл должен быть скопирован. iv. Снова установите SSH-соединение с сервером SSH с тем же именем пользователя. v. Убедитесь, что файл присутствует в домашнем каталоге удалённого пользователя. vi. Введите exit для закрытия соединения. d. Скопируйте файл mytestfile.txt с сервера SSH в локальный каталог /tmp с помощью команды sftp: i. В командной строке рабочей станции введите sftp имя_пользователя@IP-адрес_сервера_SSH. ii. Введите пароль удалённого пользователя при появлении запроса. iii. В приглашении sftp> введите get mytestfile.txt /tmp/. iv. В приглашении sftp> введите exit. v. В командной строке введите ls /tmp. Должен отобразиться файл mytestfile.txt, скопированный с сервера SSH.

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

Туннелирование трафика через SSH (Tunneling Traffic Through SSH)

Одной из ключевых проблем безопасности, с которой приходится сталкиваться системному администратору, является то, что многие широко используемые сетевые протоколы передают информацию в открытом тексте. Хорошими примерами служат демоны POP3 и IMAP, обсуждавшиеся в предыдущей главе. Чтобы агент передачи почты (MTA) мог доставлять сообщения клиентским системам, необходимо включить демон POP3 или IMAP через xinetd. После этого пользователи могут применять почтовый клиент для подключения к MTA и загрузки почты по соответствующему протоколу. Проблема, однако, заключается в том, что оба демона по умолчанию передают данные в открытом тексте. Это означает, что имена пользователей и пароли, которые клиенты передают для аутентификации в MTA, отправляются открытым текстом вместе со всем содержимым электронных писем. Любой со сниффером может перехватить пакеты и просмотреть содержимое передач.

Хорошая новость: SSH позволяет шифровать незашифрованный трафик, туннелируя (tunneling) его через SSH-соединение. Когда клиентское программное обеспечение туннелируемого протокола (например, почтовый клиент, использующий POP3) устанавливает соединение с локальным клиентом SSH, трафик шифруется средствами SSH и передаётся через туннель к серверу SSH. На стороне сервера SSH трафик расшифровывается и перенаправляется к соответствующей целевой службе (в данном случае — демону POP3). Это очень удобно, поскольку информация шифруется перед передачей, даже несмотря на то что исходный протокол (в данном случае POP3) не поддерживает шифрование.

Рассмотрим пример использования SSH для туннелирования трафика POP3:

1. Убедитесь, что клиент ssh установлен на локальной системе, где будет работать почтовый клиент.
2. Убедитесь, что демон sshd установлен и запущен на сервере POP3.
3. Убедитесь, что IP-порт 22 открыт на сервере с sshd.
4. На системе с sshd переключитесь на root и отредактируйте файл /etc/ssh/sshd_config.
5. Найдите параметр AllowTcpForwarding, при необходимости раскомментируйте его и установите значение yes:

   AllowTcpForwarding yes
   

6. Сохраните изменения в файле и выйдите из редактора.
7. Перезапустите демон sshd командой systemctl restart sshd в командной строке (от имени root).
8. Перейдите на клиентскую систему.
9. Создайте локальный SSH-туннель с локального высокого IP-порта (в данном примере — порта 2345) до порта 110 сервера POP3 с помощью следующей команды (введите пароль удалённого пользователя при появлении запроса):

   ssh -f -N -L 2345:адрес_pop3_хоста:110 имя_пользователя@адрес_pop3_хоста
   

Параметры этой команды означают следующее:

• –N и –f — запретить выполнение команды на удалённом сервере и перевести ssh в фоновый режим после запроса пароля удалённого пользователя;

• –L — задаёт три значения:

  • локальный порт для клиентского конца туннеля (в данном случае 2345);
  • имя хоста или IP-адрес удалённого сервера POP3;
  • порт удалённого сервера для серверного конца туннеля (в данном случае 110).

  Порт 2345 использовать не обязательно — при желании можно использовать один и тот же порт на обоих концах. Однако для использования порта с номером менее 1024 на клиентской стороне туннеля потребуются права суперпользователя root. Такие порты называются привилегированными (privileged ports).

• После установления туннеля настройте локальный почтовый клиент на получение почты с локальной системы через порт, который вы настроили для клиентского конца SSH-туннеля. В данном примере почтовый клиент настраивается на получение почты с локальной системы через порт 2345. Пример настройки почтового клиента Evolution показан на рис. 18-6. Заметьте, что в поле «Сервер» указано имя локального хоста, а не сервера POP3, а в конце имени хоста добавлен номер порта на стороне рабочей станции туннеля.

Рис. 18-6. Настройка Evolution для работы через SSH-туннель.

В этот момент, когда клиент использует протокол POP3 для загрузки новых сообщений, клиент SSH на локальной системе шифрует запрос и направляет его на сервер SSH через установленный туннель. Сервер SSH принимает запрос, расшифровывает его и передаёт данные на локальный порт 110, где слушает демон POP3. Прелесть этого процесса в том, что он полностью прозрачен для почтового клиента. С его точки зрения, он просто получает почту с локального сервера POP3.

Проверить созданный туннель можно с помощью команды telnet с клиентского конца туннеля. Синтаксис: telnet localhost порт_клиентского_конца_туннеля. Например:

telnet localhost 2345

При этом должно установиться соединение с удалённой системой, на которой работает демон POP3. Пример показан на рис. 18-7.

Рис. 18-7. Проверка SSH-туннеля с помощью telnet.

Через SSH-соединение можно также туннелировать трафик X-сервера к удалённым X-клиентам. Это важно, поскольку незашифрованный трафик X даёт злоумышленнику огромное количество информации для компрометации систем.

Для настройки удалённого X-клиента без шифрования используется следующая процедура:

1. На удалённом X-клиенте введите xhost +имя_X-сервера. Это разрешает клиенту принимать соединения от X-сервера.
2. На X-сервере введите DISPLAY=имя_X-клиента:0.0, затем export DISPLAY. Это указывает X-серверу отображать вывод на удалённом X-клиенте.
3. С X-клиента используйте ssh для доступа к командной строке X-сервера, а затем запустите нужное графическое приложение. Например, введите gedit для удалённого отображения текстового редактора gedit или office — для удалённого отображения пакета OpenOffice.org.

Эта процедура работает, но весь X-трафик передаётся в незашифрованном виде — что недопустимо. Следует использовать SSH для туннелирования трафика X-сервера между X-сервером и X-клиентом. Это можно сделать одним из следующих способов:

• использовать параметр –X с командой ssh;
• установить параметр ForwardX11 в значение yes в файле /etc/ssh/ssh_config на системе X-клиента.

После этого необходимо установить параметр X11Forwarding в значение yes в файле /etc/ssh/sshd_config на системе X-сервера.

Попрактикуемся в SSH-туннелировании в следующем упражнении.

Упражнение 18-2. Туннелирование X-трафика через SSH

В этом упражнении вы настроите демон sshd и клиент ssh для туннелирования X-трафика от сервера к клиенту.

Примечание

Для этого упражнения потребуется не менее двух систем Linux. Можно использовать две физические системы, две виртуальные машины или их сочетание.

Выполните следующие шаги:

1. Настройте клиентскую систему: a. Войдите в клиентскую систему как обычный пользователь. b. Откройте терминальный сеанс. c. В командной строке введите xhost +IP-адрес_X-сервера. Это разрешает клиенту принимать соединения от X-сервера (где работает sshd).
2. Настройте серверную систему: a. Войдите в серверную систему как обычный пользователь. b. Откройте терминальный сеанс и переключитесь на root командой su –. c. В командной строке введите DISPLAY=IP-адрес_X-клиента:0.0, затем export DISPLAY. Это указывает X-серверу отображать вывод на удалённом X-клиенте. d. Отредактируйте файл /etc/ssh/sshd_config и установите параметр X11Forwarding в значение yes. Сохраните изменения и выйдите из редактора.
3. Вернитесь на клиентскую систему.
4. В командной строке клиентской системы введите ssh –X –l имя_пользователя IP-адрес_сервера_SSH.
5. Введите пароль удалённого пользователя при появлении запроса. Теперь вы вошли в серверную систему.
6. В командной строке введите gedit для запуска текстового редактора gedit. Заметьте, что несмотря на то что вы вошли в удалённую серверную систему, X-приложение отображается на локальном рабочем столе (рис. 18-8). Поскольку использовался параметр –X, весь X-трафик шифруется при передаче между системами.

Рис. 18-8. Шифрование X-трафика с помощью SSH.

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

Настройка SSH для аутентификации с открытым ключом (Configuring SSH to Use Public Key Authentication)

Помимо аутентификации на сервере SSH с помощью имени пользователя и пароля, можно настроить демон sshd для аутентификации с использованием открытого ключа RSA или DSA. Для этого открытый ключ пользователя на клиентской системе должен быть сохранён в файле ~/.ssh/authorized_keys в домашнем каталоге того пользователя на серверной системе, от имени которого будет выполняться аутентификация. Для этого необходимо безопасно скопировать открытый ключ с клиентской системы на серверную. Закрытый ключ, разумеется, остаётся на клиентской системе.

При настройке сервера SSH для аутентификации с открытым ключом клиент SSH сообщает серверу, какой открытый ключ следует использовать для аутентификации при начальном установлении SSH-сеанса. Сервер SSH проверяет наличие открытого ключа этого клиента: если ключ найден, сервер генерирует случайное число, шифрует его этим открытым ключом и отправляет зашифрованное число клиенту. Клиент расшифровывает его с помощью закрытого ключа, соответствующего открытому. Затем клиент вычисляет MD5-контрольную сумму полученного числа и отправляет её обратно на сервер. Сервер SSH вычисляет собственную MD5-контрольную сумму исходно отправленного числа. Если контрольные суммы совпадают, пользователь автоматически входит в систему.

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

1. В командной строке клиентской системы введите ssh-keygen –t rsa или ssh-keygen –t dsa в зависимости от того, какой метод шифрования поддерживает сервер SSH. Для надёжности можно выполнить обе команды, создав две пары ключей — одну для RSA, другую для DSA.
2. При запросе файла для сохранения закрытого ключа нажмите Enter для использования имени по умолчанию: ~/.ssh/id_rsa или ~/.ssh/id_dsa. Соответствующий открытый ключ будет сохранён как ~/.ssh/id_rsa.pub или ~/.ssh/id_dsa.pub.
3. При запросе введите парольную фразу для ключа. Использование парольной фразы обязательно. Без неё любой, кто получит копию ваших файлов ключей, сможет аутентифицироваться на сервере SSH без ввода парольной фразы. Назначение парольной фразы делает ключ бесполезным для того, кто её не знает.

Пример создания пары ключей RSA:

rtracy@ws1:~> ssh-keygen -t rsa
Generating public/private rsa key pair.
Enter file in which to save the key (/home/rtracy/.ssh/id_rsa):
Enter passphrase (empty for no passphrase):
Enter same passphrase again:
Your identification has been saved in /home/rtracy/.ssh/id_rsa.
Your public key has been saved in /home/rtracy/.ssh/id_rsa.pub.
The key fingerprint is:
ba:14:48:14:de:fd:42:40:f2:4b:c8:8b:03:a4:6d:fc rtracy@ws1
The key's randomart image is:
+--[ RSA 2048]----+
| . +oo           |
|oo + = o         |
|o + = + o        |
| o + + o .       |
| o E o S .       |
|   .    o .      |
|      o          |
|     . .         |
|      .          |
+-----------------+
rtracy@ws1:~>

Далее необходимо скопировать только что созданный открытый ключ на сервер SSH. Удобный и безопасный способ — воспользоваться командой scp. Синтаксис:

scp ~/.ssh/имя_ключа.pub имя_пользователя@адрес_сервера_SSH:имя_файла

В следующем примере открытый ключ RSA локального пользователя rtracy на WS1 копируется в домашний каталог пользователя rtracy на WS3 и сохраняется в файл с именем keyfile:

rtracy@ws1:~> scp ~/.ssh/id_rsa.pub ws3:keyfile
Password:
id_rsa.pub                                                   100%    392       0.4KB/s       00:00
rtracy@ws1:~>

Теперь содержимое скопированного файла ключа необходимо добавить в конец файла ~/.ssh/authorized_keys в домашнем каталоге пользователя, от имени которого вы будете подключаться к серверу SSH. Простой способ — подключиться к серверу SSH через стандартный SSH-сеанс (с аутентификацией по паролю) и использовать команду cat для добавления содержимого файла ключа в конец ~/.ssh/authorized_keys. Пример:

rtracy@ws1:~> ssh -l rtracy ws3
Password:
Last login: Thu Jun 2 15:05:34 2011 from 192.168.1.84
rtracy@WS3:~> mkdir ~/.ssh
rtracy@WS3:~> cat keyfile >> ~/.ssh/authorized_keys
rtracy@WS3:~>

В этом примере я вошёл в систему WS3 через SSH-соединение от имени удалённого пользователя rtracy и создал скрытый каталог .ssh в домашнем каталоге этого пользователя (каталог отсутствовал, поэтому его пришлось создать). Если каталог .ssh уже существует, этот шаг можно пропустить и сразу добавить содержимое файла ключа в конец authorized_keys. Обратите внимание: для добавления содержимого файла keyfile в конец authorized_keys я использовал команду cat с символами перенаправления >>.

В данном примере файл authorized_keys ещё не существовал, поэтому операция перенаправления создала его автоматически. По этой причине можно было использовать и одиночный символ >. Однако если файл authorized_keys уже существует, крайне важно использовать именно >>, а не >. Напомним: >> добавляет вывод команды в конец указанного файла, тогда как > полностью перезаписывает файл. Это было бы недопустимо, если в authorized_keys уже хранятся нужные ключи.

Теперь можно проверить конфигурацию. Если вы всё ещё находитесь в SSH-сеансе с сервером SSH — выйдите из него. Затем установите новый SSH-сеанс с сервером. Вместо запроса имени пользователя и пароля должен появиться запрос парольной фразы файла ключа (рис. 18-9).

Рис. 18-9. Ввод парольной фразы файла ключа.

После ввода парольной фразы аутентификация на сервере SSH будет выполнена. Обратите внимание на следующий пример: пароль для установления SSH-сеанса не запрашивается:

rtracy@ws1:~> ssh -l rtracy ws3
Last login: Thu Jun 2 16:13:39 2011 from 192.168.1.84
rtracy@WS3:~>

При желании можно воспользоваться командой ssh-agent, чтобы исключить необходимость вводить парольную фразу при каждом установлении SSH-соединения. Выполните следующие шаги:

1. В командной строке клиентской системы введите ssh-agent bash.
2. В командной строке введите ssh-add ~/.ssh/id_rsa или ssh-add ~/.ssh/id_dsa в зависимости от того, какой файл ключа был создан.
3. При запросе введите парольную фразу файла ключа. После этого должно появиться подтверждение добавления идентификатора:

   rtracy@ws1:~> ssh-agent bash
   rtracy@ws1:~> ssh-add ~/.ssh/id_rsa
   Enter passphrase for /home/rtracy/.ssh/id_rsa:
   Identity added: /home/rtracy/.ssh/id_rsa (/home/rtracy/.ssh/id_rsa)
   rtracy@ws1:~>
   

После этого процесс ssh-agent сохранит парольную фразу в памяти. Он будет прослушивать SSH-запросы и автоматически предоставлять парольную фразу ключа при необходимости.

Попрактикуемся в настройке SSH для аутентификации с открытым ключом в следующем упражнении.

Упражнение 18-3. Настройка аутентификации с открытым ключом

В этом упражнении вы создадите пару ключей RSA на клиентской системе и скопируете открытый ключ на сервер SSH для включения аутентификации с открытым ключом.

Примечание

Для этого упражнения потребуется не менее двух систем Linux. Можно использовать две физические системы, две виртуальные машины или их сочетание.

Выполните следующие шаги:

1. Создайте пару ключей RSA на клиентской системе: a. Войдите в клиентскую систему как обычный пользователь. b. Откройте терминальный сеанс. c. В командной строке введите ssh-keygen –t rsa. d. При запросе файла для сохранения закрытого ключа нажмите Enter для использования имени по умолчанию ~/.ssh/id_rsa. e. При запросе введите парольную фразу для ключа.
2. Настройте серверную систему для аутентификации с открытым ключом: a. Скопируйте только что созданный открытый ключ на сервер SSH командой scp ~/.ssh/id_rsa.pub имя_пользователя@адрес_сервера_SSH:mykeyfile. b. Введите пароль удалённого пользователя при появлении запроса. c. Установите SSH-сеанс с удалённой системой от имени пользователя, для которого настраивается аутентификация с открытым ключом: ssh –l имя_пользователя адрес_сервера_SSH. d. Введите пароль удалённого пользователя при появлении запроса. e. В командной строке удалённой системы проверьте наличие скрытого каталога .ssh командой ls –la. Если каталог .ssh отсутствует, создайте его командой mkdir ~/.ssh. f. В командной строке удалённой системы введите cat mykeyfile >> ~/.ssh/authorized_keys. g. Введите exit для закрытия SSH-сеанса.
3. Проверьте новую конфигурацию: a. В командной строке клиентской системы введите ssh –l имя_пользователя адрес_сервера_SSH. b. При появлении запроса введите парольную фразу, назначенную закрытому ключу RSA. Должна выполниться автоматическая аутентификация на сервере SSH. c. Закройте сеанс командой exit.
4. Настройте ssh-agent для запоминания парольной фразы закрытого ключа: a. В командной строке клиентской системы введите ssh-agent bash. b. В командной строке введите ssh-add ~/.ssh/id_rsa. c. При запросе введите парольную фразу файла ключа. Должно появиться подтверждение добавления идентификатора. d. В командной строке клиентской системы введите ssh –l имя_пользователя адрес_сервера_SSH. Должна выполниться автоматическая аутентификация на сервере SSH без запроса парольной фразы закрытого ключа.

Отлично! Теперь вы — настоящий профессионал в работе с SSH! Прежде чем завершить эту главу, необходимо рассмотреть ещё одну тему, связанную с шифрованием: шифрование файлов. Этим мы займёмся далее.