Sftp can't copy directories

Bug #33378 reported by Tero Karvinen on 2006-03-02
12
Affects Status Importance Assigned to Milestone
portable OpenSSH
Fix Released
Unknown
openssh (Ubuntu)
Wishlist
Unassigned

Bug Description

Sftp can't copy directories, even though the protocol supports it.

$ sftp tkarvine@127.0.0.69
Connecting to 127.0.0.69...
sftp> ls
somedir
sftp> get somedir
Fetching /home/tee/3004WTMi to 3004WTMi
Cannot download non-regular file: /home/tkarvine/somedir

Currently, every method of using ssh to transfer files requires a manual to use: nautilus ssh requires user to know home dir (https://launchpad.net/distros/ubuntu/+source/nautilus/+bug/30039), scp has tricky syntax and terse error messages, sftp can't transfer directories.

fts would be easy enough to use for recursive. I think 'put' can be written in
a matter of a night or two (Assuming one is awake <chuckle>), but there is one
minor downfall to fts. It assuming all access is local. And unlike glob it
does not support the ability to override opendir(), readdir(), closedir(), lstat
() and stat().

Unless there is something I'm missing get and put can't both use fts effectly
without forking the code and rewriting small chunks of it.

Would be nice if fts could be modified to support virtualizing those function
calls, but with it having a chance of going into POSIX (some century) I doubt
the API can change much.

Created an attachment (id=749)
Add recurse mode to sftp put command via fts.

Add recurse mode to sftp put command via fts.

Initial work was done against openssh snapshots from 2004/01. The patch is
attached here as a contribution to anyone considering adding this feature to
sftp. I assume it would require some reworking to be applied against a modern
OpenSSH snapshot.

(From update of attachment 749)
This patch was derived in part from Jared Yanovich's sftp patch posted to
openssh-unix-dev in Oct 2003.

http://marc.theaimsgroup.com/?l=openssh-unix-dev&m=106498593122963&w=2

I removed the code in my version of the patch that handled the 'recurse'
command in sftp but forgot to remove the documentation about that command.
Trivial to either add back or to remove the references to it in the docs.

Sftp can't copy directories, even though the protocol supports it.

$ sftp tkarvine@127.0.0.69
Connecting to 127.0.0.69...
sftp> ls
somedir
sftp> get somedir
Fetching /home/tee/3004WTMi to 3004WTMi
Cannot download non-regular file: /home/tkarvine/somedir

Currently, every method of using ssh to transfer files requires a manual to use: nautilus ssh requires user to know home dir (https://launchpad.net/distros/ubuntu/+source/nautilus/+bug/30039), scp has tricky syntax and terse error messages, sftp can't transfer directories.

Minor typo in example, should be:
Fetching /home/tkarvine/somedir to somedir

Loye Young (loyeyoung) wrote :

>Currently, every method of using ssh to transfer files requires a manual to use

This may have been fixed already. sshfs mounts the remote directory on the local file system, enabling transparent transfer of files. I believe that it invokes sftp to accomplish the task.

Scott Kitterman (kitterman) wrote :

This definitely works. I use it almost every day.

Changed in openssh:
status: New → Fix Released
Colin Watson (cjwatson) wrote :

sshfs is great, but doesn't justify closing this bug IMO; sftp could support this too and it would be useful for it to do so. In fact, it's an open bug upstream as well.

Changed in openssh:
status: Fix Released → Confirmed
Changed in openssh:
status: Unknown → Confirmed

Also, normal user is not allowed to use sshfs by default. It is not obvious how to securely allow this, and it doesn't "just work". Sshfs is pretty new and very reliable yet.

komputes (komputes) wrote :

Confirming this is still an issue on Intrepid with openssh-client 1:5.1p1-3ubuntu1. sshfs has its own issues.

Scott Ritchie (scottritchie) wrote :

As a human, I would expect sftp to be more or less syntax and feature equivalent to command line ftp. Before I took the time to figure out scp I would use the ridiculous workaround of tarring an entire folder before copying it with sftp.

So this bug has been stale for four years, but this feature is still wanted. See, for instance: https://bugs.launchpad.net/ubuntu/+source/openssh/+bug/33378

Has the code here bitrotted? Would someone mind taking care of this wonderful feature? You'll have my gratitude :)

We now have get and put recursion in CVS, developed by Carlos Silva part of the Google Summer of Code. This will be in the openssh-5.4

Changed in openssh:
status: Confirmed → Fix Released

Mass move of bugs RESOLVED->CLOSED following the release of openssh-5.5p1

Launchpad Janitor (janitor) wrote :
Download full text (6.4 KiB)

This bug was fixed in the package openssh - 1:5.5p1-3ubuntu1

---------------
openssh (1:5.5p1-3ubuntu1) maverick; urgency=low

  * Resynchronise with Debian. Remaining changes:
    - Add support for registering ConsoleKit sessions on login.
    - Drop openssh-blacklist and openssh-blacklist-extra to Suggests; they
      take up a lot of CD space, and I suspect that rolling them out in
      security updates has covered most affected systems now.
    - Convert to Upstart. The init script is still here for the benefit of
      people running sshd in chroots.
    - Install apport hook.
  * Stop setting OOM adjustment in Upstart job; sshd does it itself now.

openssh (1:5.5p1-3) unstable; urgency=low

  * Discard error messages while checking whether rsh, rlogin, and rcp
    alternatives exist (closes: #579285).
  * Drop IDEA key check; I don't think it works properly any more due to
    textual changes in error output, it's only relevant for direct upgrades
    from truly ancient versions, and it breaks upgrades if
    /etc/ssh/ssh_host_key can't be loaded (closes: #579570).

openssh (1:5.5p1-2) unstable; urgency=low

  * Use dh_installinit -n, since our maintainer scripts already handle this
    more carefully (thanks, Julien Cristau).

openssh (1:5.5p1-1) unstable; urgency=low

  * New upstream release:
    - Unbreak sshd_config's AuthorizedKeysFile option for $HOME-relative
      paths.
    - Include a language tag when sending a protocol 2 disconnection
      message.
    - Make logging of certificates used for user authentication more clear
      and consistent between CAs specified using TrustedUserCAKeys and
      authorized_keys.

openssh (1:5.4p1-2) unstable; urgency=low

  * Borrow patch from Fedora to add DNSSEC support: if glibc 2.11 is
    installed, the host key is published in an SSHFP RR secured with DNSSEC,
    and VerifyHostKeyDNS=yes, then ssh will no longer prompt for host key
    verification (closes: #572049).
  * Convert to dh(1), and use dh_installdocs --link-doc.
  * Drop lpia support, since Ubuntu no longer supports this architecture.
  * Use dh_install more effectively.
  * Add a NEWS.Debian entry about changes in smartcard support relative to
    previous unofficial builds (closes: #231472).

openssh (1:5.4p1-1) unstable; urgency=low

  * New upstream release (LP: #535029).
    - After a transition period of about 10 years, this release disables SSH
      protocol 1 by default. Clients and servers that need to use the
      legacy protocol must explicitly enable it in ssh_config / sshd_config
      or on the command-line.
    - Remove the libsectok/OpenSC-based smartcard code and add support for
      PKCS#11 tokens. This support is enabled by default in the Debian
      packaging, since it now doesn't involve additional library
      dependencies (closes: #231472, LP: #16918).
    - Add support for certificate authentication of users and hosts using a
      new, minimal OpenSSH certificate format (closes: #482806).
    - Added a 'netcat mode' to ssh(1): "ssh -W host:port ...".
    - Add the ability to revoke keys in sshd(8) and ssh(1). (For the Debian
      package, this overlaps with the key blacklisting facil...

Read more...

Changed in openssh (Ubuntu):
status: Confirmed → Fix Released
To post a comment you must log in.
This report contains Public information  Edit
Everyone can see this information.

Other bug subscribers

Remote bug watches

Bug watches keep track of this bug in other bug trackers.