gpg-agent загадочным образом перестал работать - агент в удаленной системе больше не подключается к сокету ssh

Если вы хотите найти файлы, основываясь на том, что в них --, а не на их именах, --вам нужно искать в них. find не сделает этого сам по себе, но вы можете указать ему выполнить другую программу, которая будет делать это.

Я бы начал с файла(1 ), который выведет некоторое описание файла. Если это полезно для ваших файлов XML, я бы написал сценарий, который печатает имя файла, если find говорит, что это правильный тип.Затем вызовите этот скрипт для всех подходящих файлов с:

find. -type f -exec my-xml-detector {} \;
2
06.01.2018, 06:03
1 ответ

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

  • Второй сеанс SSH связывает каналы первого (должно ли это произойти?)
  • StreamLocalBindUnlink в SSHD на REMOTE неправильно собирает каналы (, возможно, потому, что они все еще открыты агентом на удаленном конце?)

Отличным обходным решением было бы использование отдельного и специального хоста в.ssh/config для переадресации агента gpg и убедитесь, что вы используете вход на этот хост только один раз!

Те несколько случаев, когда это случалось, были очень неприятными, потому что сочетание каналов/запущенных агентов и экземпляров , где новый сеанс sshd не создавал новые сокеты , приводило ко всякого рода путанице. (снова, возможно, из-за того, что старые файлы сокетов остаются открытыми работающим агентом ). И обычно у меня нет времени пытаться решить такую ​​​​проблему.

После того, как я, наконец, столкнулся с этой проблемой, я смог устранить неполадки и исправить их, я могу надежно воспроизвести проблему и показать, как ее исправить:

Рабочая система

REMOTE:$ echo "$(uname -a)" | gpg --armor --clearsign --default-key 0x1234
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA512

Linux pooter 5.4.0-42-generic #46-Ubuntu SMP Fri Jul 10 00:24:02 UTC 2020 x86_64 x86_64 x86_64 GNU/Linux
-----BEGIN PGP SIGNATURE-----

iQIzBAEBCgAdFiEE/0lJ/t51agRvvTILdQ2kyDf6wDYFAl9JgSYACgkQdQ2kyDf6

-----END PGP SIGNATURE-----

Запустите другой SSH или Rsync из локальной системы

LOCAL: $ rsync -avze ssh test.txt pooter:
bind [127.0.0.1]:5901: Address already in use

SCP не вызывает проблем, но RSYNC явно выполняет вход по ssh, поскольку я вижу, что переадресация портов не работает, поскольку файл копируется

Теперь происходит сбой удаленного шифрования/дешифрования

REMOTE:$ echo "$(uname -a)" | gpg --armor --clearsign --default-key 0x1234
gpg: all values passed to '--default-key' ignored
gpg: no default secret key: No secret key
gpg: [stdin]: clear-sign failed: No secret key

Исправление

  1. Завершить все сеансы SSH с переадресацией сокетов
  2. Уничтожить всех агентов gpg в УДАЛЕННОЙ системе
  3. Убедитесь, что каналы в /var/run/xxxx/gnupg установлены
  4. Если каналы исчезли, войдите в систему с переадресацией сокетов и убедитесь, что они воссозданы

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

Теперь все должно снова работать для шифрования/дешифрования

0
28.08.2020, 22:52

Теги

Похожие вопросы