Привет, Хабр! Я Алексей Шаманов, старший системный архитектор в ГК “Цифра”, занимаюсь проектированием решений на базе платформы ZIIoT. Сегодня предлагаю поговорить об использовании SSH для подписи коммитов в git.
Давным-давно, когда солнце было желтее, трава зеленее, а git действительно «децентрализованным», для определения/верификации авторства вносимых изменений использовался PGP.
То есть, совсем давно вообще ничего подобного не использовалось. И задачи-то в нашей хипстерской «И таааак сойдёт!» коммуне не было — прислали патч по почте, совпал email в коммите с адресом отправителя — замечательно, не совпал — разберёмся (Но это не точно!). Впрочем, во времена столь отдалённые, когда динозавры ещё ходили по земле, мы погружаться не будем и вернемся к PGP.
С одной стороны, задачу определения принадлежности набора изменений метод решал. И неотказуемость обеспечивал. И даже — чьорт побьери! — позволял более-менее подтвердить личность участника в децентрализованной среде без единого root-of-trust. Оборотной стороной являлась некоторая, гм, «хтоничность» настройки какой из вариантов (openpgp, gnupg) ни возьми, да и о каком-либо удобстве использования речь, в общем-то, не идёт.
В общем, сам собой сформировался некоторый консенсус. Штука хорошая, штука важная, штука нужная, но использовать её мы, конечно же, не будем. Ну только если нас прям не заставят. И ведь таки-да, заставляли. В крупных opensource-проектах двухфакторная аутентификация в SCM и commit signing стала, de facto, стандартом. В корпоративном окружении криптографическая подпись вносимых изменений — давно уже составная часть compliance policy безопасной разработки, но сколько-нибудь удобной подобная работа (Особенно в динамической среде с необходимостью работать из разных окружений) всё же не являлась.
С другой стороны, в наши дни git, de facto, — централизованная система с единым root-of-trust и задачу обеспечения доверия можно уже и не решать. Вот что у человека в свойствах профиля на github/gitlab написано, тому и верим. Это открыло возможность использовать для подписи SSH-ключи, которые в наше время есть примерно у всех.
Настройка подписи под Linux
Инструкций по настройке примерно миллион:
shaman@test.lc@haproxy:~$ ssh-keygen -t ed25519 -C "user@test.lc"
Generating public/private ed25519 key pair.
Enter file in which to save the key (/home/shaman@test.lc/.ssh/id_ed25519):
Enter passphrase (empty for no passphrase):
Enter same passphrase again:
Your identification has been saved in /home/shaman@test.lc/.ssh/id_ed25519
Your public key has been saved in /home/shaman@test.lc/.ssh/id_ed25519.pub
The key fingerprint is:
SHA256:jfjSeEI4+SQMQMt24+q1mXJ72rb2xy5lxClcHein+rI user@test.lc
The keys randomart image is:
+--[ED25519 256]--+
|o. o.. |
|... o . |
| +.o . + . |
|. oo.o + B . |
| .* + S + |
| . + + |
| . . = O |
|....=+ B o |
| .o*ooEBo |
+----[SHA256]-----+
#Добавим ключ в ssh-agent
shaman@test.lc@haproxy:~$ eval $(ssh-agent -s)
Agent pid 1502
shaman@test.lc@haproxy:~/testrepo$ ssh-add ~/.ssh/id_ed25519
Enter passphrase for /home/shaman@test.lc/.ssh/id_ed25519:
Identity added: /home/shaman@test.lc/.ssh/id_ed25519 (user@test.lc)
echo "user@test.lc $(cat ~/.ssh/id_ed25519.pub)" >> ~/.ssh/allowed_signers
# Создадим репозиторий
shaman@test.lc@haproxy:~$ mkdir testrepo
shaman@test.lc@haproxy:~$ cd testrepo/
shaman@test.lc@haproxy:~/testrepo$ git init
hint: Using 'master' as the name for the initial branch. This default branch name
hint: is subject to change. To configure the initial branch name to use in all
hint: of your new repositories, which will suppress this warning, call:
hint:
hint: git config --global init.defaultBranch <name>
hint:
hint: Names commonly chosen instead of 'master' are 'main', 'trunk' and
hint: 'development'. The just-created branch can be renamed via this command:
hint:
hint: git branch -m <name>
Initialized empty Git repository in /home/shaman@test.lc/testrepo/.git/
# Сконфигурируем git для подписи коммитов
shaman@test.lc@haproxy:~/testrepo$ git config --global gpg.format ssh
shaman@test.lc@haproxy:~/testrepo$ git config --global user.signingkey ~/.ssh/id_ed25519.pub
shaman@test.lc@haproxy:~/testrepo$ git config --global user.name "Aleksey T. Shamanov"
shaman@test.lc@haproxy:~/testrepo$ git config --global user.email user@test.lc
shaman@test.lc@haproxy:~/testrepo$ git config --global gpg.ssh.allowedSignersFile ~/.ssh/allowed_signers
shaman@test.lc@haproxy:~/testrepo$ git config --global commit.gpgsign true
# Проверим подпись
shaman@test.lc@haproxy:~/testrepo$ echo "Test signing" > ./testfile
shaman@test.lc@haproxy:~/testrepo$ git add testfile
shaman@test.lc@haproxy:~/testrepo$ git commit -m "Test signing"
[master (root-commit) 5a7c088] Test signing
1 file changed, 1 insertion(+)
create mode 100644 testfile
shaman@test.lc@haproxy:~/testrepo$ git log --show-signature
commit 5a7c08803c5b2486907d0e051b4c80cbd7acd71a (HEAD -> master)
Good "git" signature for user@test.lc with ED25519 key SHA256:jfjSeEI4+SQMQMt24+q1mXJ72rb2xy5lxClcHein+rI
Author: Aleksey T. Shamanov <user@test.lc>
Date: Thu Apr 3 10:36:20 2025 +0500
Test signingЕдинственная проблема, с которой я столкнулся, была связана с использованием аутентификатора YubiKey, с SSH-ключом, требовавшим подтверждения использования:
ssh-keygen -t ecdsa-sk -O resident -O application=ssh:mainkey -O verify-requiredДобавление ключа в ssh-agent требовало явного ввода пин-кода и касания аутентификатора, а ssh-agent не мог этого сделать. Проблему решила установка пакета ssh-askpass. Осталось добавить ключ в github/gitlab, и… Стоп. А в чём, собственно, новизна работы? Точно! Кроме Linux’а есть же ведь еще и Windows! Надеюсь, у вас, как и у меня, уже 10/11 со встроенным OpenSSH, так что всё должно быть просто.
Настройка подписи под Windows
# Проверяем наличие сервиса
PS C:\Users\atsha> Get-Service -Name ssh-agent
Status Name DisplayName
------ ---- -----------
Stopped ssh-agent OpenSSH Authentication Agent
# Настраиваем автоматический запуск и запускаем
PS C:\Users\atsha> Set-Service ssh-agent -StartupType Automatic
PS C:\Users\atsha> Start-Service ssh-agent
# Проверяем, что все работает
PS C:\Users\atsha> Get-Service -Name ssh-agent
Status Name DisplayName
------ ---- -----------
Running ssh-agent OpenSSH Authentication Agent
# Далее аналогично создаем и добавляем ключ
ssh-add "C:\Users\atsha\.ssh\id_ed25519"
PS C:\Users\atsha> ssh-add -l
256 SHA256:... user@test.lc (ED25519)Полностью аналогично настраиваем git:
git config --global gpg.format ssh
git config --global user.signingkey C:\Users\atsha\.ssh\id_ed25519.pub
git config --global user.name "Aleksey T. Shamanov"
git config --global user.email user@test.lc
git config --global gpg.ssh.allowedSignersFile ~/.ssh/allowed_signers
git config --global commit.gpgsign trueПроверяем подпись… Первый облом. По умолчанию git использует забандленный OpenSSH, который про встроенный в Windows не знает, знать не хочет и работать с его ssh-agent’ом не умеет. Нет, можно, конечно, настроить поставляемый с git’ом ssh/ssh-agent, поправить .bashrc, но, ээээ… А зачем тогда мы всё вышеописанное делали?
Для использования «системного» OpenSSH есть аж целых три способа:
Переустановить git с использованием внешнего OpenSSH:
2. Явным образом указать «нужный» SSH, задав переменную окружения GIT_SSH_COMMAND
PS C:\Users\atsha> Get-Command ssh.exe
CommandType Name Version Source
----------- ---- ------- ------
Application ssh.exe 9.5.3.1 C:\Windows\System32\OpenSSH\ssh.exe
$env:GIT_SSH_COMMAND = C:\Windows\System32\OpenSSH\ssh.exe3. Задать путь через конфигурацию: git config --global core.sshCommand "'C:\Windows\System32\OpenSSH\ssh.exe'"
Делаем, проверяем — error: Couldn't get agent socket. Ага. SSH есть, он правильный, но про сокет ssh-agent’а почему-то ничего не знает. А как, собственно, он про него узнает? А, да — по значению переменной SSH_AUTH_SOCK. Проверяем echo $env:SSH_AUTH_SOCK — ну да, пустота. Ok, Google — путь к сокету ssh-agent’а в Windows? Не то… Снова не то… Опять не то… О, вроде как pipe: \\.\pipe\openssh-ssh-agent Задаём значение сразу через системные переменные окружения (чтоб не мучиться с квотингом), проверяем:
PS C:\Users\atsha> echo $env:SSH_AUTH_SOCK
\\.\pipe\openssh-ssh-agent
PS D:\test> git commit -m 'Test signing'
[master (root-commit) f18245d] Test signing
1 file changed, 0 insertions(+), 0 deletions(-)
create mode 100644 testfile
PS D:\test> git log --show-signature
commit f18245d7df2fbed2c8e49b0b65dc52e435fbdd72 (HEAD -> master)
Good "git" signature for user@test.lc with ED25519 key SHA256:...
Author: Aleksey T. Shamanov <user@test.lc>
Date: Thu Apr 3 11:17:25 2025 +0500
Test signingVoila?! Не-а! Есть ведь ещё и окружение WSL2.
Настройка подписи в WSL2
Каждая проблема имеет решение — простое, понятное и неправильное. Есть оно и у этой задачи — просто берём, копируем ключик в wsl-окружение (Да бог с ним, можно даже не копировать, просто путь указать!) и добавляем его в ssh-agent окружения и проблема решена! Правда назвать это «решение» сколько-нибудь «удобным», кмк, не получится: два раза вводить пароль от ключа при любых подергушках, два независимых SSH-агента — ну, такое себе. Хорошо бы вот ну… один использовать!
И да, возможность есть, и даже не одна! Итак, вариант первый — из палки и верёвки.
Использование npiperelay
В Windows в качестве «unix-socket’ов» используются named pipes, о которых ни Linux, ни WSL 2 примерно ничего не знают. Но мир не без добрых людей, и так появился проект npiperelay, позволяющий получать доступ к Windows named pipes как к unix socket’ам.
На стороне WSL установим socat и протестируем его вызов:
export SSH_AUTH_SOCK=$HOME/.ssh/auth.sock
setsid socat UNIX-LISTEN:"~/.ssh/auth.sock,fork" EXEC:"/mnt/d/npiperelay.ex. -ei -s //./pipe/openssh-ssh-agent"
>/dev/null 2>&1 &
shaman@hwhost:~$ ssh-add -l 256 SHA256:... (ED25519)Та-дааам! Осталось только запихнуть это дело в .bashrc с проверкой существования сокета и можно пользоваться. Более того, «на сдачу» ещё и обычный ssh с ключом заработает!
И в общем всё в этом способе хорошо, но очень уж развесистая гирлянда выходит. Да и использование niperelay с последним коммитом, сделанным пять лет назад, некоторым образом напрягает. Можно ли обойтись без него? Можно!
Использование Windows OpenSSH в WSL
Обратили внимание на непосредственный вызов npiperelay.exe в прошлом способе? Вспомнили, что из WSL-окружения можно безболезненно вызывать приложения из основной системы? Ну, догадались?
Да, в общем-то никто нам не мешает в качестве core.sshCommand вызывать ssh.exe из состава Microsoft Windows. Уж он-то точно умеет со своим пайпом работать, мы проверяли! Единственный момент, который надо иметь в виду, — необходимость изменения путей под unix-like стандарт:
git config --global core.sshCommand /mnt/c/Windows/System32/OpenSSH/ssh.exe
git config --global user.signingkey /mnt/c/Users/atsha/.ssh/id_ed25519.pubРабота с IDE
Всё? Ну… да, но нет. Не из консоли ж мы коммитить будем, правда? Нет, бывает что и из неё, но, in general, скорее всего из IDE, и вот тут вполне может быть засада. При создании проекта в окружении WSL IntelliJ автоматически определяет для работы git из окружения WSL:
И всё бы ничего, вот только запускает его IDE в обход твоего .bashrc с заботливо наколбашенным пробросом сокета и/или заменой SSH. Самое «умное», что пришло мне в голову для решения этой задачи, — сделать файлик-обёртку git следующего содержания:
#!/bin/bash
SSH_AUTH_SOCK=$HOME/.ssh/agent.sock /usr/bin/git "$@"
# Путь к сокету будет отличаться в зависимости от способа работы с ним из окружения WSL…и явно прописать его в настройках. Решение корявенькое, но работает. Ещё одна минорная проблема, которая может возникнуть, — различие в правах WSL/Windows. WSL-окружение видит все файлы Windows-окружения с правами 777, что, очевидно, нервирует SSH. Если вы указываете в качестве user.signingkey путь к ключу в окружении Windows, «умный» SSH наотрез отказывается работать. В качестве решения можно использовать непосредственное задание публичного ключа вместо указания пути к нему:
git config --global user.signingkey "ssh-ed25519 AAAAC3 user@test.lc"
Ну, теперь-то уж точно всё? Практически. Остался достаточно редкий кейс с использованием всякого рода удалённых виртуалок.
Удалённая работа
Собственно, с одной стороны, никто нам не помешает просто скопировать ключи на удалённую машину, «после чего решение сведется к предыдущему варианту», но без нужды разбрасываться закрытым ключом по различным машинам — ну очень такое себе.
На этот случай есть вполне типовое решение от проекта OpenSSH — “SSH agent forwarding”, позволяющее пробросить сокет через SSH-соединение. Для настройки нам необходимо создать файл ~/.ssh/config (Да-да, под Windows вполне работает) и прописать в нём разрешение пересылки агента для требуемого хоста или хостов:
Host 192.168.1.61
HostName haproxy.test.lc
User shaman@test.lc
ForwardAgentИ подключиться к нему через ssh с указанием ключа -A:
ssh -l shaman@test.lc 192.168.1.61 -A
shaman@test.lc@haproxy:~$ ssh-add -l
256 SHA256:... user@test.lc (ED25519)На сим с настройкой клиентской части мы закончили (варианты использования gitbash ssh\putty+pagent и т. д. не рассматриваем как очевидно маргинальные) и можно задуматься и о централизованном управлении ключами в корпоративной среде - но это уже са-аа-авсем другая история...