У вас есть выбор. Вот несколько предложений:
Подключитесь от serverB к root @ serverA, используя аутентификацию на основе сертификата, и запустите сценарий в корневом контексте на этом сервере.
Затем вы можете использовать ту же аутентификацию на основе сертификата, чтобы вернуть полученный файл с помощью scp
или rsync
. Обратной стороной является то, что ваша учетная запись на serverB тогда имеет полный неограниченный доступ к root @ serverA. однако в строго управляемой среде это может быть приемлемо.
Подключитесь от serverB к root @ serverA, используя аутентификацию на основе сертификата, которая ограничивает соединение запуском одной команды - вашего скрипта.
Если бы команда выводила свой файл на stdout , его можно было бы захватить непосредственно из сеанса ssh
с serverB на root @ serverA без необходимости передавать файл после завершения сценария . Ваша учетная запись на serverB не будет иметь произвольного доступа к root @ serverA.
Пример необходимой записи для root @ serverA в его файле ~ root / .ssh / authorized_keys
для выполнения команды bake
может выглядеть примерно так:
ssh-rsa AAAAB3Nza ... Fr9FvN me @ roaima, command = "/ usr / local / bin / bake", no-agent-forwarding, no-port-forwarding, no-X11-forwarding
Подключитесь с serverB к serverA и используйте sudo
для запуска сценария. Вы можете настроить sudo
, чтобы разрешить вашей единственной учетной записи запускать сценарий от имени пользователя root, но без запроса пароля.
Эта запись в / etc / sudoers
позволяет пользователю «roaima» запускать указанный сценарий с аргументами или без них от имени пользователя root с помощью такой команды, как sudo / usr / local / bin / bake --fruit = apple, blackberry --type = pie
roaima ALL = NOPASSWD: / usr / local / bin / bake
Более сложные вещи с триггерами, например, подключение к определенному TCP-порту на serverA и запустив ваш скрипт, запустите его как root.
Это означает, что любой, у кого есть доступ к этому TCP-порту на serverA, может запустить ваш скрипт, поэтому вам нужно учитывать проблемы DDOS и предотвращать одновременный запуск нескольких экземпляров скрипта.Однако это устранит необходимость иметь какой-либо интерактивный корневой доступ на serverA - даже через sudo
.
Под X буфера обмена на самом деле нет. Все выборки (первичный, вторичный буфер обмена )копируются, когда два вовлеченных X-клиента общаются друг с другом. (Подробности см., например, в статье Википедии ).
Это означает, что если один X-клиент, удерживающий выбор, больше не работает, выбор пропал.
Что вы можете сделать, так это запустить другой клиент, например. xclipboard
, который немедленно копирует выбор из вашегоxterm
(или любого другого X-клиента ), как только он будет сделан, и может участвовать в описанной выше связи, даже когда xterm
больше не работает. Конечно, теперь вы должны продолжать xclipboard
работать...
Я никогда не замечал, чтобы Firefox делал что-то по-другому, но если выбор действительно доступен после закрытия Firefox, должен быть запущен какой-то другой X-клиент, возможно, что-то, что является частью вашего рабочего стола. Так что да, Firefox должен использовать какой-то внешний инструмент (, но, как я уже сказал, я сам этого не наблюдал. Но тогда я не использую «рабочий стол» в этом смысле, простоfvwm
).