Вы не можете иметь несколько адресатов в одной команде scp
. Если вы хотите создать одно соединение SSH, вам понадобится другой инструмент.
Простейшее решение - смонтировать удаленную файловую систему через SSHFS , а затем использовать команду cp
. Для этого требуется доступ по SFTP.
mkdir host_server
sshfs username@host_server:/file host_server
cp /file/source1/* host_server/destination1
cp /file/source2/* host_server/destination2
cp /file/source3/* host_server/destination3
fusermount -u host_server
rmdir host_server
Другое решение - сначала организовать файлы локально, а затем скопировать иерархию. Для этого требуется rsync.
mkdir destination1 destination2 destination3
ln -s /file/source1/* destination1
ln -s /file/source2/* destination2
ln -s /file/source3/* destination3
rsync -a --copy-unsafe-links destination1 destination2 destination3 username@host_server:/file
rm -r destination1 destination2 destination3
Другое решение - продолжать использовать scp
, но сначала открыть главное соединение с сервером. Это объясняется в Использование уже установленного канала SSH
В качестве альтернативы, просто оставьте это и сделайте три соединения scp
. Но не используйте свой пароль для входа в систему; вместо этого создайте пару ключей и загрузите закрытый ключ в свой ключевой агент ( ssh-add ~ / .ssh / id_rsa
), тогда вам не придется ничего вводить при каждом соединении.
Клиент отправляет свой идентификатор открытого ключа, и сервер проверяет, есть ли этот ключ в списке authorized_keys
.
Клиент начинает с отправки идентификатора пары ключей, с помощью которой он хотел бы аутентифицироваться, на сервер.
Сервер проверяет авторизованный файл _ключей учетной записи, в которую клиент пытается войти для получения идентификатора ключа.
Если в файле найден открытый ключ с совпадающим идентификатором, сервер генерирует случайное число и использует открытый ключ для шифрования этого числа.
Сервер отправляет клиенту это зашифрованное сообщение. Если у клиента действительно есть связанный закрытый ключ, он сможет расшифровать сообщение с помощью этого ключа, раскрывая исходный номер.
Это очень хорошо объяснено в RFC4252 , включая сообщения, которые отправляются туда и обратно клиентом и сервером:
SSH_MSG_USERAUTH_REQUEST
содержит большой двоичный объект открытого ключа, который используется для сравнения с ключом, хранящимся в authorized_keys
SSH_MSG_USERAUTH_PK_OK
или ошибкой SSH_MSG_USERAUTH_REQUEST
снова содержит открытый ключ (, предполагая, что это снова большой двоичный объект )вместе с подписью над известными данными (, включая открытый ключ ). Первые два пункта не являются обязательными, и вы можете выполнить только последний (, но выяснение того, какой ключ использовать, экономит вычислительную мощность ).