Этот ответ развивается как на выбранный ответ , добавляя дополнительную безопасность.
В этом ответе обсуждается общая форма
<command that makes output> | \
ssh <user A>@<host A> <command that maps stdin to clipboard>
Если безопасность может быть недостаточной, это разрешения ssh, позволяющие <user B> на host B> до ssh в host A и выполнять любую команду.
Конечно, доступ B к A может быть уже закрыт с помощью ключа ssh и даже может иметь пароль. Но другой уровень безопасности может ограничивать область допустимых команд, которые B может выполнять на A, например, так что rm -rf / нельзя назвать. (Это особенно важно, когда ssh клавиша не не имеет пароля.)
К счастью, ssh имеет встроенную функцию, называемую ограничение команды или принудительная команда . См. ssh.com или
этот вопрос serverfault.com .
В приведенном ниже решении показано решение общей формы вместе с ssh ограничением команды принудительно.
Пример решения с ограничением команды добавлено
Это решение повышенной безопасности имеет общий вид - вызов из сеанса ssh на host-B просто:
cat <file> | ssh <user-A>@<host A> to_clipboard
Остальная часть этого показывает настройку, чтобы заставить это работать.
Настройка ограничения ssh на команды
Предположим, учетная запись пользователя на B имеет значение user-B, а B имеет ssh-ключ id-clip, созданный обычным способом (ssh-keygen).
Затем в каталоге user-A ssh есть файл
/home/user-A/.ssh/authorized_keys
, который распознает ключ id-clip и разрешает ssh соединение.
Обычно содержимое каждой строки authorized_keys - это в точности открытый ключ, который авторизуется, например, содержимое id-clip.pub.
Однако для обеспечения ограничения команды необходимо, чтобы содержимое открытого ключа предшествовало (в той же строке) команде, которая должна быть выполнена.
В нашем случае:
command="/home/user-A/.ssh/allowed-commands.sh id-clip",no-agent-forwarding,no-port-forwarding,no-user-rc,no-x11-forwarding,no-pty <content of file id-clip.pub>
Указанная команда "/home/user-A/.ssh/allowed-commands.sh id-clip" и только , которая назначена, выполняется при каждом использовании ключа id-clip, инициирует ssh соединение с host-A - независимо от того, какая команда написано ssh командная строка .
Команда указывает файл сценария allowed-commands.sh, а содержимое этого файла сценария
#/bin/bash
#
# You can have only one forced command in ~/.ssh/authorized_keys. Use this
# wrapper to allow several commands.
Id=${1}
case "$SSH_ORIGINAL_COMMAND" in
"to-clipboard")
notify-send "ssh to-clipboard, from ${Id}"
cat | xsel --display :0 -i -b
;;
*)
echo "Access denied"
exit 1
;;
esac
Исходящий вызов ssh на аппарате B был
... | ssh <user-A>@<host A> to_clipboard
Строка to-clipboard передается в allowed-commands.sh переменной окружения SSH_ORIGINAL_COMMAND.
Кроме того, мы передали имя ключа id-clip из строки в authorized_keys, доступ к которой имеет только id-clip.
Линия
notify-send "ssh to-clipboard, from ${Id}"
- это просто всплывающее окно с сообщением о том, что буфер обмена пишется - это, вероятно, также хорошая функция безопасности. (notify-send работает на Ubuntu 18.04, возможно, не на других).
В строке
cat | xsel --display :0 -i -b
параметр --display :0 необходим, потому что у процесса нет собственного X-дисплея с буфером обмена,
так что это должно быть конкретно указано. Это значение :0 работает в Ubuntu 18.04 с сервером окон Wayland. На других установках это может не работать. Для стандартного X-сервера этот ответ может помочь.
host-A /etc/ssh/sshd_config параметры
Наконец, несколько параметров в /etc/ssh/sshd_config на хосте A, которые должны быть установлены для обеспечения разрешения на подключение и разрешения на использование ssh -ключа только без пароля:
PubkeyAuthentication yes
PasswordAuthentication no
ChallengeResponseAuthentication no
AllowUsers user-A
Чтобы сервер sshd перечитал конфигурацию
sudo systemctl restart sshd.service
или
sudo service sshd.service restart
заключение
Требуется некоторая настройка, но другие функции, кроме to-clipboard, могут быть построены параллельно в той же самой структуре.