Я уже пару часов пытаюсь заставить rsync работать, но безуспешно 😣. У меня есть капля Digital Ocean, которую я хотел бы отправить через rsync, используя SSH.
локальный rsync, работающий на macOS 10.12.6, установленный через homebrew
rsync version 3.1.2 protocol version 31
удаленный rsync, работающий в Debian 8.x, установленный через apt
rsync version 3.1.1 protocol version 31
Я пытаюсь отправить один файл из локального ящика macOS в удаленный ящик Debian (дроплет Digital Ocean) Команда, которую я запускаю локально в Терминале на macOS
$ rsync -avvvv -e "ssh -p $SSH_PORT_# -v" dummy $USER@example.com:/home/$USER/www/
Некоторые лакомые кусочки,
1) dummy - это один файл размером 10 МБ в моей локальной системе.
2) Я могу успешно использовать ssh в удаленном цифровом океане с помощью следующей команды: $ ssh nathan
2.1) У меня есть "конфигурационный" файл в /Users/$USER/.ssh/
2.2) Содержимое файла /Users/$USER/.ssh/config
Ведущий натан
HostName $ REMOTE_IP_ADDRESS, т.е. 1.2.3.4
Пользователь $ REMOTE_USERNAME chris
порт $ SSH_PORT_ # 4242
IdentityFile /Users/$USER/.ssh/id_rsa
3) Я также могу ssh в удаленную каплю Digital Ocean с помощью следующей команды
$ ssh -l $USER -p 4242 $REMOTE_USERNAME example.com
Некоторые результаты выполнения вышеуказанной команды rsync,
открытие соединения с помощью: ssh -p 4242 -v -l $ USER example.com rsync --server -vvvvlogDtpre.iLsfxC. / home / $ USER / www / (12 аргументов)
кодировка проверки сообщения: UTF-8
OpenSSH_7.4p1, LibreSSL 2.5.0
debug1: чтение данных конфигурации /Users/$USER/.ssh/config
debug1: чтение данных конфигурации / etc / ssh / ssh_config
debug1: подключение к example.com [1.2.3.4] порт 4242.
debug1: соединение установлено.
debug1: строка локальной версии SSH-2.0-OpenSSH_7.4
debug1: версия удаленного протокола 2.0, версия удаленного программного обеспечения OpenSSH_6.7p1 Debian-5 + deb8u4
debug1: соответствует: OpenSSH_6.7p1 Debian-5 + deb8u4 pat OpenSSH * compat 0x04000000
debug1: аутентификация на example.com:4242 как «$ USER»
debug1: SSH2_MSG_KEXINIT отправлен
debug1: получен SSH2_MSG_KEXINIT
debug1: kex: алгоритм: curve25519-sha256@libssh.org
debug1: kex: алгоритм ключа хоста: ecdsa-sha2-nistp256
debug1: kex: server-> client cipher: chacha20-poly1305@openssh.com MAC: сжатие: нет
debug1: kex: client-> server cipher: chacha20-poly1305@openssh.com MAC: сжатие: нет
debug1: ожидание SSH2_MSG_KEX_ECDH_REPLY
debug1: ключ хоста сервера: ecdsa-sha2-nistp256 SHA256: REMOVED_KEY
debug1: Хост '[example.com]: 4242' известен и соответствует ключу хоста ECDSA.
debug1: найден ключ в /Users/$USER/.ssh/known_hosts:15
debug1: rekey after 134217728 блоков
debug1: SSH2_MSG_NEWKEYS отправлено
debug1: ожидание SSH2_MSG_NEWKEYS
debug1: получено SSH2_MSG_NEWKEYS
debug1: rekey after 134217728 блоков
debug1: получен SSH2_MSG_SERVICE_ACCEPT
debug1: аутентификация, которая может продолжаться: открытый ключ, пароль
debug1: Следующий метод аутентификации: publickey
debug1: Предлагает открытый ключ RSA: /Users/$USER/.ssh/id_rsa
debug1: сервер принимает ключ: pkalg ssh-rsa blen 279
debug1: аутентификация прошла успешно (открытый ключ).
Аутентифицировано на example.com ([1.2.3.4]: 4242).
debug1: канал 0: новый [клиент-сеанс]
debug1: запрос no-more-sessions@openssh.com
debug1: вход в интерактивный сеанс.
debug1: залог: сеть
debug1: отправка команды: rsync --server -vvvvlogDtpre.iLsfxC --log-format =% i. / главная / $ USER / www /
(Клиент) Версии протокола: удаленный = 31, согласованный = 31
И это все, что я могу использовать с помощью указанной выше команды rsync 😭 Если у вас есть какие-либо мысли / предложения, я бы очень хотел ❤️ их услышать.
ура 🍺 Крис
TL; DR; Проблема была связана с моим config.fish файл.
Как я пришел к решению.
Я решил для проверки работоспособности создать нового пользователя на обеих машинах и протестировать rsync / scp с вновь созданной учетной записью пользователя. Низкий и вот, оба в итоге заработали.
То, что я в итоге попробовал, перезагрузил удаленный ящик, запустил sshd в однопользовательском режиме, передав -vvvv флаг, просматривая журнал и не видя ничего, связанного с отправкой файла неправильно.
Единственный другой компьютер, к которому у меня есть локальный доступ, - это RasPi, поэтому я попробовал scp / rsync локально для RasPi, который закончился работать, поэтому я пришел к выводу, что он должен что-то делать с файлом конфигурации на сервере.