Переадресация портов без учетной записи на хост-компьютере
Хотя у меня нет полного решения, я нашел обходной путь:
Используя альтернативный домашний каталог для GnuPG с помощью параметра --homedirили переменной окружения GNUPGHOME, можно заставить GnuPG использовать другой набор файлов хранилища ключей и связанные с ними пути сокетов агентов. Имея это в виду, я могу запустить оболочку внутри нового gpg-agentсеанса :
gpg-agent \
--homedir /my/other/keys \
--default-cache-ttl 86400 \
--max-cache-ttl 86400 \
--daemon \
\
/bin/bash
Срок действия любых введенных фраз-паролей либо истечет, если указанный TTL превысит (один день в этом примере ), либо они будут «забыты» при выходе из новой оболочки, так как это приведет к тому, что родительский gpg-agentэкземпляр самоуничтожится. -прекратить.
Причина, по которой я не считаю это полным решением, заключается в том, что оно вынуждает использовать отдельный брелок. Однако это прекрасно работает для моего конкретного случая использования, и поэтому я не стал проводить дальнейшие исследования.
Можно добиться полного эффекта независимых сеансов для одной и той же цепочки ключей, используя символические ссылки на связку ключей GnuPG по умолчанию, при условии достаточного внимания к этому. поддержание любой блокировки между различными gpg-agentэкземплярами. Я оставлю это читателю в качестве упражнения...
Таким образом, предположив, что NAT1 имеет общедоступный IP-адрес, запустите x11vncна локальном порту A, настройте NAT1 для переадресации этого порта (, возможно, на какой-либо другой порт )на любом общедоступном IP-адресе NAT1, B выполните переадресацию в стиле хоста -с помощью sshот A к порту NAT1 через raspi.
Недостатком этого является то, что все остальные также смогут подключиться к этому порту в NAT1, поэтому в основном каждый может управлять A через x11vnc, если только вы не запустите его с экрана входа в систему из диспетчера дисплеев.
Так что это очень небезопасная установка. Это неприменимо, если вся ваша установка находится во внутренней сети (, но тогда нет реальной причины использовать NAT ).
В качестве альтернативы, если либо B, либо rasppi могут хранить учетные данные, вы можете перенаправить порт ssh из A через NAT1. Затем вы можете использовать переадресацию ssh из B через rasppi в A (или, может быть, даже напрямую из B в A ).
Опять же,все остальные теперь могут получить доступ к перенаправленному порту ssh, но, по крайней мере, это работает с учетными данными, и вы можете защитить его (, например, использовать сертификат и включить пароль для входа в систему ).