Как передать данные в соединение sftp?
FTP поддерживает put "|..." "remote-file.name" Команда для передачи данных на FTP-соединение. Есть ли что-то подобное для sftp?
В sftp я получаю следующую ошибку:
sftp 'jmw@backupsrv:/uploads'
sftp> put "| tar -cx /storage" "backup-2012-06-19--17-51.tgz"
stat | tar -cv /storage: No such file or directory
как указано выше, клиент sftp явно не выполняет команду.
я хочу использовать команду pipe для прямого перенаправления файлового потока в sftp. (потому что недостаточно места для создания файла резервной копии на том же диске перед его загрузкой на сервер sftp.)
4 ответа
voretaq7 отметил, что клиент sftp не поддерживает передачу данных по трубопроводам для пользователей, которым разрешено использовать sftp только для подключения к серверу.
К счастью, есть libssh2, которая поддерживает sftp. поэтому нам просто нужно 2 других клиента, использующих libssh2, которые я назвал:
- sftp_stdin_upload (для загрузки на сервер sftp)
- sftp_stdout_download (для загрузки с сервера sftp)
исходный код можно найти по следующему URL: http://www.qxs.ch/2012/07/05/sftp-upload-tool/
Так как я не настолько опытен в программировании на libssh2, я рад любой обратной связи с исходным кодом.
Так как это первый результат, который вы нашли, погуглив по этому вопросу, и он еще не был упомянут, я добавлю также решение, которое нашел здесь:
Вы можете использовать реализацию curls sftp для этого. Поскольку curl, вероятно, уже установлен на многих системах, это может быть предпочтительнее решения с использованием пользовательских клиентов.
пример использования:
pg_dump -d database | pigz -1 | curl -u username -T - sftp://sftpserver/folder/dbbackup.sql.gz
curl использует ваш .ssh/known_hosts файл для проверки ключа. Это может завершиться ошибкой, если ваш ssh-клиент использует более новые стандарты шифрования, не поддерживаемые библиотекой, используемой в curl
чтобы исправить это, вы можете добавить другие типы ключей в известный файл hosts, используя следующую команду:
ssh-keyscan sftpserver >> ~/.ssh/known_hosts
или вы можете отключить проверку ключа с помощью -k флаг (хотя я бы не рекомендовал это)
Мне было очень интересно найти решение этой проблемы. Требуется инструмент nc (netcat) на обеих машинах и SSH (SFTP не требуется).
В этом примере я буду называть машину, на которой есть данные для резервного копирования, linux-a, и машину, которая должна получить резервную копию linux-b.
На linux-a netcat прослушивает порт (я взял 2000) и перенаправляю его в файл. Это будет просто сидеть и ждать, пока что-то не пройдет через этот порт.
[kenny@linux-b /var/backups]$ nc -l 2000 > backup.tgz
На linux-b откройте ssh-туннель к linux-a, я снова использовал порт 2000. Это перенаправит все, что вы выбросите на TCP-порт 2000 на локальном хосте, на TCP-порт 2000 на linux-a, где прослушивает netcat.
[kenny@linux-a /var/data]$ ssh -L 2000:localhost:2000 -CfN linux-b
Теперь создайте архив tar, но отправьте вывод в stdout (используя -) и передайте его в gzip для некоторого сжатия. Теперь передайте это другому netcat, который отправит его на локальный хост по TCP через порт 2000.
[kenny@linux-a /var/data]$ tar cf - important-data | gzip -fc | nc localhost 2000
Были сделаны! На linux-b netcat больше не слушает, и создается новый файл. Самое приятное, что архив tar никогда не помещался на жесткий диск linux-a.
[kenny@linux-b /var/backups]$ file backup.tgz
backup.tgz: gzip compressed data, from Unix, last modified: Thu Jul 5 13:48:03 2012
Я знаю, что это не совсем то, что вы просили в вопросе, но если у вас есть netcat, это жизнеспособное решение для вашего типа проблемы.
Редактировать: я забыл об одном: если вы будете следовать этим инструкциям, у вас все еще будет SSH-туннель, плавающий на linux-a. Узнайте, что такое идентификатор процесса, и убейте его.
[kenny@linux-a /var/data]$ ps -ef | grep "ssh -L"
kenny 5741 1 0 13:40 ? 00:00:00 ssh -L 2000:localhost:2000 -CfN linux-b
kenny 5940 3360 0 14:13 pts/1 00:00:00 grep --color=auto ssh -L
[kenny@linux-a /var/data]$ kill 5741
output-stream-generating-command | ssh user@remotehost 'input-stream-accepting-command' это вариант, если у вашего удаленного пользователя есть действующая оболочка.