Анна Сергеева. Система контроля версий Mercurial. Работа без ввода пароля // Системный администратор. 2016. № 9. С. 80-83.
Mercurial позволяет использовать беспарольный вход при обращении к центральному репозиторию. Разберем, как это настроить с сохранением безопасности доступа
Опубликовано в разделе "Разработка / Тестирование"
Эта же статья на сайте журнала
Над разработкой современных сложных программных приложений трудится большое число специалистов, которые ежедневно модифицируют большие объемы исходного программного кода. Для синхронизации их действий внедряются системы контроля версий, такие как Mercurial, общий обзор которой был в предыдущей статье [1].
Каждый разработчик модифицирует код в отдельной копии на локальной машине, а затем объединяет результаты своей работы с общим кодом, хранящимся в центральном репозитории на сервере. Для идентификации пользователей иобеспечения безопасности при каждом обращении к центральному репозиторию система запрашивает пароль. Следует сказать, что происходит это достаточно часто: при создании новых репозиториев, копировании файлов из центрального репозитория в локальный, при фиксировании всех изменений, при передаче изменений на сервер, синхронизации, объединении ветвей кода и т.д. Это неудобно и постоянно отвлекает.
В статье приводится методика по настройке системы, позволяющая избежать повторяющейся процедуры ввода пароля, но в то же время с сохранением безопасности.
Необходимые инструменты для работы
На локальной машине должен быть установлен полный пакет клиента удаленного доступа PuTTY, включая утилиты puttygen.exe и plink.exe. Рекомендуется брать A .ZIP file или A Windows installer на странице [2].
Также для работы срепозиториями Mercurial потребуется графический пакет TortoiseHg [3] либо отдельный пакет Mercurial [4].
Здесь и далее в тексте статьи в качестве имени пользователя используется asergeeva. Просто замените его на свой логин на сервере хранения центрального репозитория.
Шаг 1. Создание пары публичный + приватный ключ
На данном шаге в каталоге установки PuTTY требуется запустить утилиту puttygen.exe. При этом обязательно нужно убедиться, что в нижней части экрана установлен параметр SSH-2 RSA, длина ключа 1024.
В статье рассмотрим сохранение приватного ключа без защиты парольной фразой (passphrase). Это позволяет значительно упростить подключение к SSH-серверу с помощью пары ключей, хоть и несколько снижает безопасность, поскольку требуется дополнительно обеспечить надежное хранение приватного ключа, чтобы он был недоступен для злоумышленника.
Таким образом, для создания ключей в диалоге PuTTY нужно нажать кнопку Generate и далее двигать мышкой, пока прогресс-бар не заполнится целиком. После генерирования ключей сохраняем их.
Рис. 1. Генерирование ключей с помощью утилиты puttygen.exe.
В диалоге сохранения (рис. 2) ничего указывать не нужно, поля "Key passphrase" и "Confirm passphrase" остаются пустыми.
Рис. 2. Сохранение готовых ключей с помощью утилиты puttygen.exe.
По кнопке "Save public key" сохраняется публичный ключ, для которого нужно указать имя вида asergeeva_public.pub.
По кнопке "Save private key" сохраняется приватный ключ, для которого, согласившись с сохранением ключа без парольной фразы, нужно указать имя вида asergeeva_private.ppk.
На этом работа с утилитой puttygen.exe может быть завершена.
Шаг 2. Подготовка публичного ключа для внедрения на сервер
Для подготовки полученного публичного ключа для его совместимости с Open-SSH сервером, необходимо модифицировать ключ в текстовом редакторе.
Создается копия публичного ключа (*.pub) - файл с новым именем authorized_keys. Рекомендуется всю дальнейшую работу выполнять именно с этим файлом, оставляя оригинальный файл *.pub в качестве резервной копии.
Изначально ключ выглядит примерно так:
---- BEGIN SSH2 PUBLIC KEY ----
Comment: "rsa-key-20160823"
AAAAB3NzaC1yc2EAAAABJQAAAIEAh31XYrh8YoGA+oWa6vuvKvu+dtcnco6r3N8OAVHuu6GT+Cl1gPoCHDu5UaJ3wGf2SHSoHj9MuzYp8HVSuOsNPm5mVqX26Znj4Y6W24aWFdYVmopwqLNwfqgRdkcffRaUrg/dpVeaWqDVdwTKWnKro436Aw3oJCNSmSuKRyFOopE=
---- END SSH2 PUBLIC KEY ----
Первые две и одна последняя строки удаляются. Оставшиеся строки соединяются в одну, без пробелов.
В начало получившейся одной строки нужно дописать "ssh-rsa " (обязательно нужно добавить один пробел в конце) и сохранить изменения.
В итоге, в файле с именем authorized_keys должна получиться одна длинная строка примерно такого вида:
ssh-rsa AAAAB3NzaC1yc2EAAAABJQAAA___одна_очень_длинная_строка___=
Шаг 3. Внедрение публичного ключа на сервер
В данном примере, передача файлов на сервер производится по протоколу FTP, хотя это можно сделать и другими способами. Для этого можно воспользоваться FTP-клиентами, встроенными в разные файловые менеджеры, например в FAR.
Если в домашнем каталоге пользователя на сервере отсутствует подкаталог .ssh (начинается с точки), то его нужно создать. (Напомним, что каталоги, начинающиеся с точки, считаются служебными, и возможно, некоторые FTP клиенты могут их не показывать по умолчанию).
Если каталог уже существует, то нужно проконтролировать наличие в нем файла authorized_keys. Если такого файла нет, то передать по FTP в подкаталог .ssh файл с именем authorized_keys, который был подготовлен на предыдущем шаге. Если такой файл уже есть, то пользователь, который его создал, сам знает, как объединить старый и новый файлы.
В итоге, созданный файл с публичным ключом должен оказаться здесь: /home/asergeeva/.ssh/authorized_keys.
Здесь и далее в тексте статьи строка 'asergeeva' используется в качестве имени пользователя. Каждое ее упоминание следует заменять на свой логин на сервере хранения центрального репозитория.
Задание атрибутов доступа
Также стоит упомянуть и некоторые опциональные действия. Желательно установить на файл authorized_keys и на каталог .ssh правильные атрибуты. Это нужно и для безопасности ключа, и чтобы SSH-сервер не считал ключ скомпрометированным. Это можно сделать одним из следующих способов.
Способ 1. Зайти на центральный сервер server по протоколу SSH и использовать управление с помощью команд в shell:
- внутри каталога .ssh, для файла authorized_keys выполнить команду
chmod 600 authorized_keys
- снаружи каталога .ssh, для самого каталога выполнить команду
chmod 700 .ssh
Способ 2. Менять атрибуты файлов позволяют многие FTP клиенты. Например, в FTP клиенте, встроенном в файловый менеджер FAR, можно нажать сочетание клавиш Ctrl+A и установить для каталога .ssh такое сочетание атрибутов:
R W X R W X R W X
[x][x][x] [ ][ ][ ] [ ][ ][ ]
а для файла authorized_keys - вот такое:
R W X R W X R W X
[x][x][ ] [ ][ ][ ] [ ][ ][ ]
Теперь хост сервера знает публичный ключ пользователя, и способен авторизовать SSH-соединение без ввода пароля, если при этом будет передан правильный приватный ключ.
Шаг 4. Сохранение приватного ключа локально. Проверка пары ключей
Приватный ключ нужно положить в безопасное место на своей машине.
В качестве временной меры, предлагается положить его в каталог %USERPROFILE% и возможно, защитить его пермишенами от чтения другими пользователями.
Ниже по тексту предполагается, что ключ будет положен сюда: %USERPROFILE%\asergeeva_private.ppk
Теперь имеет смысл проверить созданные ключи простой проверкой. Если она не пройдет, то нужно искать, в чем была ошибка, прежде чем двигаться дальше.
В каталоге Putty запускается на выполнение команда:
PLINK.EXE -i "%USERPROFILE%\asergeeva_private.ppk" asergeeva@server pwd
где
%USERPROFILE%\asergeeva_private.ppk - файл с приватным ключом,
asergeeva - логин пользователя на сервере server,
pwd - команда, которую хотим выполнить на сервере.
Данная команда должна вернуть результат выполнения команды pwd на сервере server, вот так:
/home/asergeeva
Если это получилось, причем без запроса пароля, значит, пара приватный/публичный ключи изготовлена и внедрена правильно (рис. 3).
Рис. 3. Положительный результат проверки созданных ключей.
Если получена ошибка "Server refused our key", или был запрошен пароль, или запрошен passphrase, значит, пара ключей создана неправильно, либо ключ на сервер внедрен неверно.
Шаг 5. Внедрение в конфигурацию Mercurial метода доступа по SSH с приватным ключом
Чтобы SSH-соединение смогло быть совершено без указания пароля, нужно вызывающему SSH-клиенту указать путь к приватному ключу.
Для улучшения восприятия, здесь стоит добавить несколько слов о теории.
В рамках данной статьи в качестве SSH-клиента рассматривается утилита plink.exe из комплекта PuTTY, поскольку именно ее используют разные клиенты Mercurial. Хотя точно так же можно настроить и сам клиент Putty, если это потребуется для других целей.
Как было показано ранее, приватный ключ передается утилите plink с помощью параметра командной строки -i, следующим образом:
PLINK.EXE -i "%USERPROFILE%\asergeeva_private.ppk" asergeeva@server <команда для выполнения на сервере>
При этом, если существует необходимость работать с командной строкой , утилита командной строки hg.exe из отдельного пакета Mercurial вызывает утилиту plink для обращения к серверу Mercurial по протоколу SSH. Точно так же обращается к серверу и графический пакет TortoiseHg, если требуется (или считается более удобным) работать через диалоговые окна (хотя, напомним, в пакет TortoiseHg также включена и утилита командной строки HG).
Единственная разница этих двух вариантов: пакет Mercurial предполагает, что утилита plink установлена отдельно, а в комплекте TortoiseHg утилита plink уже включена под именем TortoisePlink.exe (но это всего лишь вопрос настройки в конфигурационном файле).
В обоих случаях, каким образом вызывать утилиту plink и какие параметры ей передавать - указано в конфигурационных файлах этих пакетов. И для запуска plink нужно внимательно отнестись к указанию правильных параметров.
Ниже дана информация о конфигурационных файлах обоих пакетов, но только лишь с целью дать возможность узнать формат написания параметров, чтобы потом их задать в своем конфигурационном файле.
Если используется отдельный пакет Mercurial, то основной конфигурационный файл пакета находится здесь: "C:\Program Files\Mercurial\Mercurial.ini". Однако, редактировать этот файл не рекомендуется, поскольку он перезаписывается на дефолтный в результате каждого апгрейда пакета.
Если же используется графический пакет TortoiseHg. То основной конфигурационный файл пакета находится здесь: "C:\Program Files\TortoiseHg\hgrc.d\Mercurial.rc". Точно так же, редактировать этот файл не рекомендуется, поскольку он перезаписывается на дефолтный в результате каждого апгрейда пакета.
В обоих вышеперечисленных случаях, существует специальный единый пользовательский файл конфигурации Mercurial, имеющий бОльший приоритет: %USERPROFILE%\Mercurial.ini. Любые параметры в нем перекрывают параметры из основного файла в каждом случае.
Теперь можно перейти к описанию внесения самих настроек.
Для этого следует перейти в каталог %USERPROFILE%. В нем должен быть пользовательский файл Mercurial.ini (если такого файла нет, его нужно создать).
В Mercurial.ini нужно добавить секцию вида:
[ui]
ssh = "C:\Program Files\PuTTY\plink.exe" -ssh -2 -i "%USERPROFILE%\asergeeva_private.ppk" -l asergeeva
где
"C:\Program Files\PuTTY\plink.exe" — путь к утилите plink,
-i "%USERPROFILE%\asergeeva_private.ppk" — путь к приватному ключу,
-l asergeeva — логин пользователя на сервере server.
Здесь следует обратить внимание, что путь к утилите plink.exe может быть любой, однако, если у Вас установлен пакет TortoiseHg, то обязательно нужно использовать тот plink, что идет вместе с пакетом:
"C:\Program Files\TortoiseHg2\TortoisePlink.exe".
Для проверки созданной конфигурации следует запустить команду в командной строке:
hg clone --verbose ssh://asergeeva@server//home/hg/ProjectsDocs C:\Repo
В результате выполнения, система клонирование содержимого репозитория ProjectsDocs в пустой каталог C:\Repo без запроса пароля на сервере (рис. 4).
Рис. 4. Клонирование копии из центрального репозитория без запроса пароля.
Аналогичную проверку можно выполнить и из оболочки TortoiseHg. В этом случае, нужно выбрать пункт меню File -> Clone Repository.
В диалоге настройки параметров (рис. 5) заполнить поля каталога источника (то есть, название необходимого корневого репозитория) и назначения (здесь, во избежание блокировки, обязательно следует указывать пустой каталог):
source: ssh://asergeeva@server//home/hg/ProjectsDocs
destination: C:\Repo
Далее нажать кнопку Clone.
Рис. 5. Клонирование копии из центрального репозитория через графический интерфейс TortoiseHg.
Как и в предыдущем случае, по команде система выполнит клонирование содержимого репозитория ProjectsDocs в каталог C:\Repo без запроса пароля на сервере.
Положительный исход такой проверки говорит о том, что в дальнейшем разработчик будет избавлен от необходимости постоянно помнить и вводить вручную свой пароль при каждом обращении к центральному репозиторию, будь то чтение из него или добавление нового кода.
Заключение
Внедрение системы контроля версий исходного кода Mercurial позволяет удобно и своевременно синхронизировать действия всех разработчиков, параллельно оперирующих с программным кодом совместно создаваемых приложений.
В то же время, при организации работы, руководителям и оптимизаторам проектов следует обращать должное внимание на все имеющиеся возможности для избавления высококвалифицированных специалистов от рутинной ручной работы, что помогает сосредоточиться на решении сложных рабочих задач, экономить время и получать в результате продукт надлежащего качества в более сжатые сроки.
Литература
[1] Анна Сергеева. Система контроля версий Mercurial. Общий обзор и начало работы // Системный администратор. 2016. № 7-8.
[2] Страница загрузки клиента PuTTY - http://www.chiark.greenend.org.uk/~sgtatham/putty/download.html
[3] Официальный сайт разработчиков графического пакета TortoiseHg - http://tortoisehg.org
[4] Официальный сайт разработчиков проекта Mercurial - https://www.mercurial-scm.org
Ключевые слова
Система хранения версий, Mercurial, TortoiseHg, SSH, PuTTY, plink, puttygen, публичный ключ, приватный ключ, репозиторий.