Карта закрытых и открытых ключей ssh ​​для клиента

Вы не можете иметь несколько адресатов в одной команде 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 ), тогда вам не придется ничего вводить при каждом соединении.

3
03.07.2017, 10:25
2 ответа

Клиент отправляет свой идентификатор открытого ключа, и сервер проверяет, есть ли этот ключ в списке authorized_keys.

  • Клиент начинает с отправки идентификатора пары ключей, с помощью которой он хотел бы аутентифицироваться, на сервер.

  • Сервер проверяет авторизованный файл _ключей учетной записи, в которую клиент пытается войти для получения идентификатора ключа.

  • Если в файле найден открытый ключ с совпадающим идентификатором, сервер генерирует случайное число и использует открытый ключ для шифрования этого числа.

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

https://www.digitalocean.com/community/tutorials/understanding-the-ssh-encryption-and-connection-process

2
27.01.2020, 21:18

Это очень хорошо объяснено в RFC4252 , включая сообщения, которые отправляются туда и обратно клиентом и сервером:

  • Первое сообщение SSH_MSG_USERAUTH_REQUESTсодержит большой двоичный объект открытого ключа, который используется для сравнения с ключом, хранящимся в authorized_keys
  • .
  • Сервер отвечает SSH_MSG_USERAUTH_PK_OKили ошибкой
  • Второй SSH_MSG_USERAUTH_REQUESTснова содержит открытый ключ (, предполагая, что это снова большой двоичный объект )вместе с подписью над известными данными (, включая открытый ключ ).

Первые два пункта не являются обязательными, и вы можете выполнить только последний (, но выяснение того, какой ключ использовать, экономит вычислительную мощность ).

2
27.01.2020, 21:18

Теги

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