Я могу использовать файл конфигурации ssh, чтобы включить пересылку ключей ssh, добавленных в ssh-agent. Как я могу сделать то же самое с ключами gpg?
Оба ответа предлагают запустить socat, чтобы выставить unix-сокет агента GPG на порт tcp. Однако, в отличие от сокетов Unix, порты TCP не имеют одинакового уровня в управлении доступом. В частности, _every_ пользователь на том же хосте теперь может подключаться к вашему агенту GPG. Это, вероятно, нормально, если у вас есть однопользовательский ноутбук, но если другие пользователи также могут войти в ту же систему (систему, в которой работает агент GPG), они также могут получить доступ к вашему агенту GPG, что создает серьезную проблему безопасности. Разрешение socat напрямую запустить SSH с использованием типа адреса EXEC, вероятно, является лучшим способом исправить это.
Matthijs Kooijman 10 лет назад
3
Для другой презентации решения openssh 6.7+ см. Https://2015.rmll.info/IMG/pdf/an-advanced-introduction-to-gnupg.pdf.
phs 8 лет назад
0
[Это] (http://www.gossamer-threads.com/lists/gnupg/users/77816) было полезно для меня.
phs 7 лет назад
0
@DrewR. Рад это слышать.
Brian Minton 9 лет назад
0
Я обнаружил необходимую критическую деталь: на удаленной машине (без личного ключа) должен присутствовать _public_ ключ удостоверения подписи. Локальная версия gpg 2.1.15 OS X, удаленная версия 2.1.11 linux.
phs 8 лет назад
1
16
b0fh
РЕДАКТИРОВАТЬ: Этот ответ устарел теперь, когда надлежащая поддержка была реализована в OpenSSH, см. Ответ Брайана Минтона.
SSH способен только пересылать TCP-соединения в туннеле.
Однако вы можете использовать такую программу, как socatретрансляцию сокета unix через TCP, с чем-то вроде этого (вам понадобится socat как на клиенте, так и на хостах сервера):
# Get the path of gpg-agent socket: GPG_SOCK=$(echo "$GPG_AGENT_INFO" | cut -d: -f1) # Forward some local tcp socket to the agent (while true; do socat TCP-LISTEN:12345,bind=127.0.0.1 UNIX-CONNECT:$GPG_SOCK; done) & # Connect to the remote host via ssh, forwarding the TCP port ssh -R12345:localhost:12345 host.example.com # (On the remote host) (while true; do socat UNIX-LISTEN:$HOME/.gnupg/S.gpg-agent,unlink-close,unlink-early TCP4:localhost:12345; done) &
Проверьте, работает ли это с gpg-connect-agent. Убедитесь, что GPG_AGENT_INFO на удаленном хосте не определен, чтобы он возвращался к $HOME/.gnupg/S.gpg-agentсокету.
Теперь, надеюсь, все, что вам нужно, это способ запустить все это автоматически!
Что ж, ключи агента ssh пересылаются автоматически, когда в файле конфигурации задана переадресация. Я попробую это.
txwikinger 14 лет назад
0
Вы правы, ssh-agent также использует сокет unix, но имеет специальную поддержку для него (немного усталый здесь :) Тем не менее, решение должно работать.
b0fh 14 лет назад
0
Для этого решения мой gpg-агент был бы общедоступным через порт 12345, если бы я не был за брандмауэром / NAT. Это должно быть упомянуто в ответе, пожалуйста.
Jonas Schäfer 12 лет назад
1
Полагаю, твое последнее изменение исправило эту проблему, Джонас? теперь это только привязка к `localhost`.
jmtd 12 лет назад
0
Для меня это не получается с помощью следующего аргумента из `gpg-connect-agent` удаленного хоста:` не может подключиться к серверу: ec = 31.16383 gpg-connect-agent: ошибка отправки команды RESET: неверное значение передано в IPC`. Удаленный `socat` тогда умирает. Местный `socat` умирает и произносит` socat [24692] E connect (3, AF = 1 "", 2): неверный аргумент`. [Эта страница] (http://snafu.priv.at/interests/crypto/remotegpg.html) заставляет меня поверить, что это никогда не сработает, потому что агент не хранит ключ (только пароль). Кто-нибудь подтвердил, что это работает?
jmtd 12 лет назад
0
@jmtd да, это решает проблему конфиденциальности. Тем не менее, я не смог заставить его работать с socat, поэтому я взломал скрипт на python, который делает свое дело: http://fpaste.org/Um0D/ (это может потребовать улучшения). Другие проблемы, которые у меня были с socat, были задержка tcp сокетов и прочее.
Jonas Schäfer 12 лет назад
0
@JonasWielicki - ссылка на fpaste.org теперь не работает. Можете ли вы предоставить свой сценарий через новую ссылку на pfaste.org или еще лучше в качестве A для этого Q?
slm 10 лет назад
0
@slm Я использовал fpaste, поскольку это был информационный комментарий. На самом деле, я даже не могу вспомнить, что это было, хотя комментарии заставляют поверить, что это была простая утилита, похожая на socat, привязывающая к localhost и пересылающая трафик между tcp и сокетом unix.
Jonas Schäfer 10 лет назад
0
3
antifuchs
I had to do the same, and based my script on the solution by b0fh, with a few tiny modifications: It traps exits and kills background processes, and it uses the "fork" and "reuseaddr" options to socat, which saves you the loop (and makes the background socat cleanly kill-able).
The whole thing sets up all forwards in one go, so it probably comes closer to an automated setup.
Note that on the remote host, you will need:
The keyrings you intend to use to sign/en/decrypt stuff.
Depending on the version of gpg on the remote, a fake GPG_AGENT_INFO variable. I prefill mine with ~/.gnupg/S.gpg-agent:1:1 - the first 1 is a PID for the gpg agent (I fake it as "init"'s, which is always running), the second is the agent protocol version number. This should match the one running on your local machine.
#!/bin/bash -e FORWARD_PORT=$ trap '[ -z "$LOCAL_SOCAT" ] || kill -TERM $LOCAL_SOCAT' EXIT GPG_SOCK=$(echo "$GPG_AGENT_INFO" | cut -d: -f1) if [ -z "$GPG_SOCK" ] ; then echo "No GPG agent configured - this won't work out." >&2 exit 1 fi socat TCP-LISTEN:$FORWARD_PORT,bind=127.0.0.1,reuseaddr,fork UNIX-CONNECT:$GPG_SOCK & LOCAL_SOCAT=$! ssh -R $FORWARD_PORT:127.0.0.1:$FORWARD_PORT socat 'UNIX-LISTEN:$HOME/.gnupg/S.gpg-agent,unlink-close,unlink-early,fork,reuseaddr TCP4:localhost:$FORWARD_PORT'
I believe there's also a solution that involves just one SSH command invocation (connecting back from the remote host to the local one) using -o LocalCommand, but I couldn't quite figure out how to conveniently kill that upon exit.
Вы не пропустили какой-то аргумент 'user @ host' перед socat, в последней команде? Во всяком случае, даже после исправления этого, у меня не получается с «socat [6788] E connect (3, AF = 2 127.0.0.1:0, 16): соединение отказано», которое появляется локально, при удаленной попытке gpg-connect-agent.
David Faure 8 лет назад
0
2
MaLo
В новых версиях дистрибутивов GnuPG или Linux пути сокетов могут меняться. Это можно узнать через
На удаленном компьютере также измените конфигурацию сервера SSH и добавьте этот параметр (/ etc / ssh / sshd_config):
StreamLocalBindUnlink yes
Перезапустите сервер SSH, переподключитесь к удаленному компьютеру - тогда он должен работать.
Более подробное руководство, включая некоторые способы устранения неполадок, можно найти здесь: https://mlohr.com/gpg-agent-forwarding/
MaLo 6 лет назад
0
Если на удаленном хосте запущена текущая версия Debian, он запускает `systemctl --global mask --now gpg-agent.service gpg-agent.socket gpg-agent-ssh.socket gpg-agent-extra.socket gpg- agent-browser.socket` необходим для предотвращения запуска systemd сокета, крадущего удаленный gpg-agent. Согласно https://bugs.debian.org/850982 это предполагаемое поведение.
sampi 6 лет назад
0
1
doak
Согласно GnuPG Wiki, вы должны перенаправить удаленный сокет S.gpg-agent.extraв локальный сокет S.gpg-agent. Кроме того, вам нужно включить StreamLocalBindUnlinkна сервере. Имейте в виду, что вам также нужна открытая часть вашего ключа, доступная на удаленной GnuPG .
Используйте gpgconf --list-dir agent-socketсоответственно gpgconf --list-dir agent-extra-socketна пульте, чтобы получить фактические пути.
Резюме
Добавленная конфигурация на пульте /etc/sshd_config:
StreamLocalBindUnlink yes
Импортируйте ваш открытый ключ на удаленный компьютер: