voretaq7 указал, что клиент sftp не поддерживает передачу данных по каналу для пользователей, которым разрешено использовать sftp только для подключения к серверу.
к счастью, есть это libssh2, который поддерживает sftp. поэтому нам просто нужны 2 других клиента, использующих libssh2, которые я назвал:
исходный код можно найти в следующий URL: http://www.qxs.ch/2012/07/05/sftp-upload-tool/
, так как я не так уж опытен в программировании libssh2, я рад любым отзывам к исходному коду.
Мне было очень интересно найти решение этой проблемы. Для этого требуется инструмент 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 на localhost, на TCP-порт 2000 на linux-a, где netcat прослушивает.
[kenny@linux-a /var/data]$ ssh -L 2000:localhost:2000 -CfN linux-b
Теперь создайте tar-архив, но отправьте вывод на stdout (используя -) и направьте его в gzip для некоторого сжатия. Теперь направьте его другому netcat, который отправит его на localhost по 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, это жизнеспособное решение для вашего типа проблемы.
Edit: Я забыл об одной вещи: если вы будете следовать этим инструкциям, у вас все равно будет 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
команда-поток-вывода | ssh user @ remotehost 'input-stream-accept-command'
- вариант, если у вашего удаленного пользователя есть действующая оболочка.
Так как это первый результат, который вы найдете при поиске в Google для этого вопроса, и он еще не упоминался, я также добавлю решение, которое я нашел здесь:
вы можете использовать для этого реализацию 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
. Чтобы исправить это, вы можете добавить другие типы ключей в файл известных хостов, используя следующую команду:
ssh-keyscan sftpserver >> ~/.ssh/known_hosts
или вы можете отключить проверку ключа с помощью флага -k
(хотя я бы не рекомендовал это)