Установка Mercurial Server и использование авторизации по SSH

Несколько дней назад передо мной поставили задание — поднять mercurial-репозиторий на одной из локальных машин, и поставили одно условие — обязательная авторизация по SSH. Установка будет производится с использованием Mercurial Server на 64-битной серверной Убунте.

Установка Mercurial Server


Первым, что пришло в голову — была установка из репозиториев. Обновив пакеты и выполнив команду:
apt-get install -y mercurial-server

я обнаружил, что установилась версия 1.0.1-1, которая не является последней.
На официальном сайте был обнаружен deb-пакет с версией 1.2-1, который и был установлен командой
dpkg -i mercurial-server_1.2-1_all.deb


Настройка SSH для авторизации по ключам


Т.к. я хотел, чтобы все ключи пользователей, которые имеют доступ к серверу по ssh, хранились в одном месте, то в файл /etc/ssh/sshd_config была добавлена следующая строчка:
AuthorizedKeysFile /etc/ssh/keys/%u.pub
Она означает, что файлы ключей должны храниться в папке /etc/ssh/keys/ и иметь вид имя_пользователя.pub

Настройка Mercurial Server


Домашняя директория с конфигами Mercurial Server находится в /var/lib/mercurial-server. Нас интересует файл .mercurial-server, именно в нем хранится основной конфиг сервера. Там можно изменить пути к репозиториям, директории с публичными ключами и др. Т.к. репозитории у меня вынесены на другой диск, то и переменную repos я изменил соответствующим образом.
Пользователи делятся на две группы: root(имеют полные права на все репозитории, в том числе и на создание) и users(имеют право на pull и push).
Ключи пользователей, которые должны иметь доступ к серверу необходимо поместить в папку /etc/mercurial-server/keys/users, а ключи администраторов — /etc/mercurial-server/keys/root.

Специальный репозиторий hgadmin

После установки сервера автоматически создается служебный репозиторий hgadmin, в котором можно хранить ключи пользователей и администраторов. Это очень удобно, т.к. нет необходимости загружать в ручную ключи пользователей.
Структура точно такая же, как и в системе, т.е. ключи хранятся в /hgadmin/keys/users и /hgadmin/keys/root для пользователей и администраторов соответственно.
Там же можно хранить файл access.conf который отвечает за права доступа пользователей.

Окончательная настройка


Так как по умолчанию ключи для доступа к пользователю hg хранятся в ~/.ssh/authorized_keys нам нужно создать символическую ссылку в каталоге /etc/ssh/keys/. Для этого выполняем команду:
 ln -s /var/lib/mercurial-server/.ssh/authorized_keys /etc/ssh/keys/hg.pub


После того, как мы поместили ключ в /etc/mercurial-server/keys необходимо обновить права доступа, для этого необходимо выполнить следующую команду:
sudo -u hg /usr/share/mercurial-server/refresh-auth

Если ключи были добавлены с помощью hgadmin, то изменения вступают в силу автоматически.

Доступ к репозиторию с помощью TortoiseHg


Первым делом необходимо скачать Pageant, он будет передавать TortoiseHg приватный ключ в случае необходимости. Для удобства мною был написан bat'ник, который запускается при старте системы. Его смысл в том, чтобы добавить приватный ключ в Pageant.
start pageant.exe node.ppk

После запуска pageant'а всё, что остается — это склонировать репозиторий.
Клонируем специальный репозиторий hgadmin командой:
hg clone ssh://hg@server/hgadmin

Создать новый репозиторий можно командой:
hg init ssh://hg@server/myrep

Полезные ссылки

Share post

Similar posts

Comments 20

    –5
    А можно такое же, но под винду и iis
      +12
      К счастью, таким заниматься не приходилось.
        –1
        Можешь попробовать мой сервер. Правда я apache вместо iis использую. И это http сервер, а не ssh, но можно подключить https протокол и настроить права на каждый репозиторий.
          0
          hg serve и разбирайтесь сами, как его подключить бэкендом к iis
          –1
          А какой смысл устанавливать свежайшую версию пакета вместо стабильной?
            0
            Версия 1.2 в релизе
            Changelog можно глянуть тут.
              –1
              Видимо, разработчики вашего дистрибутива так не считают, раз не включили в свой репозиторий.

              Я к тому, что выбирать Убунту значит выбирать версии софта, утверждённые специально обученными канониклавцами. В мире Убунту софт обновляется сам, когда приходит время, а устанавливать что-то не из репозитория приходится только в крайнем случае. А вы пишете так, будто это само собой разумеющееся.
                0
                Mercurial 1.2 — это ооооочень старое…
                  0
                  Судя по всему, это сентябрь 2011 года. Не так уж и старо.
                    +2
                    2009 — mercurial.selenic.com/wiki/WhatsNew/Archive#Version_1.2_-_2009-03-04
                    Её уже на странице What's new нету — она в архив перенесена. С тех пор было добавлено очень много важных фич. (Важных в том числе для сравнения с Git)
                      +3
                      Насколько я понял, мы говорим о разных вещах.
                      Вы вообще про Mercurial, как систему, говорите, а я — за пакет mercurial-server.
            0
            Советую всем кому необходим сервер с git, mercurial или subversion посмотреть в сторону bitbucket.org/sdorra/scm-manager/wiki/Home
            Очень простая установка и работает на Linux и Windows, поскольку java.
              0
              Не подскажите, как там дела с ssh и/или шифрованием?
                0
                Я сам не настраивал. Но там (https://bitbucket.org/sdorra/scm-manager/wiki/scm-server-ssl) пишут, что какой-то ssl можно настроить.
              0
              переменную repos я изменил соответствующим образом.
              я предпочёл симлинк. при апгрейде не понадобится сливать конфиги. Элементарные, да, но тем не менее.
                0
                Остаётся один неудобный момент — при такой авторизации доступен shell. А его далеко не всегда хочется вот так просто давать всем подряд.
                Если я пользуюсь просто репом — это не проблема. Но ведь никто не мешает написать и ssh name@host…
                Опять же, когда я знаю, для чего это — это не проблема.
                Но, предположим, у меня угнали рабочий ноутбук, в котором без пароля лежит закрытый ключ.

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

                ssh-rsa AAAAB3NzaC1…

                дописать в начале ограничения, чтобы получилось:

                no-port-forwarding,no-X11-forwarding,no-agent-forwarding,no-pty,command="/usr/bin/hg-ssh /home/hg/repo1 /home/hg/repo2" ssh-rsa AAAAB3NzaC1…

                В этом случае зайти просто через ssh и сделать какую-нибудь гадость уже не получится. А функционал сервера hg ничуть не пострадает.
                  0
                  а вы для начала посмотрите, какой именно шелл у юзера hg
                    0
                    Вы правы, ключ выглядит примерно так:
                    no-pty,no-port-forwarding,no-X11-forwarding,no-agent-forwarding,command="/usr/share/mercurial-server/hg-ssh root/aivus" ssh-rsa .....
                  0
                  Признаться, после знакомства с mercurial-server в 2009 меня тоже посещала мысль, как бы об этой прелести написать здесь, но так, чтобы топик не был пересказом элементарной документации. Так и не написал, в общем :)
                    0
                    Спасибо за туториал, мне он очень помог.
                    В дополнение к этой статье, могу лишь ещё добавить ещё одну: kurtgrandis.com/blog/2010/03/20/gitosis-for-mercurial/ Мало ли кому пригодится.

                    Only users with full accounts can post comments. Log in, please.