openssh portable 8.0p1-4 from debian/ubuntu Hi, sftp can't fetch files that are inside a directory with [ or ] characters. It can "cd" just fine into them, but fetching the file fails: $ sftp squid-ds216.lxd Connected to squid-ds216.lxd. sftp> ls -l drwxrwxr-x 2 ubuntu ubuntu 3 Sep 10 13:21 [pub] drwxr-xr-x 2 ubuntu ubuntu 2 Sep 5 20:40 bzr sftp> cd \[pub\] sftp> ls -l -rw-rw-r-- 1 ubuntu ubuntu 12 Sep 10 13:21 hello.txt sftp> get hello.txt File "/home/ubuntu/[pub]/hello.txt" not found. $ ssh squid-ds216.lxd ... $ ls -lad \[pub\] drwxrwxr-x 2 ubuntu ubuntu 3 Sep 10 13:21 '[pub]' $ cd \[pub\]/ $ ls -la total 10 drwxrwxr-x 2 ubuntu ubuntu 3 Sep 10 13:21 . drwxr-xr-x 7 ubuntu ubuntu 17 Sep 10 13:21 .. -rw-rw-r-- 1 ubuntu ubuntu 12 Sep 10 13:21 hello.txt
Created attachment 3440 [details] Retry unglobbed filename on get remote_glob failure I think this should fix it. Filenames for sftp get commands are processed using remote_glob() to wildcard-expand them. In this case it was interpreting and eating the special characters. This patch makes the remote_glob() call return the original, unmodified filename when expansion fails. Pretty much every other remote_glob() call in the sftp client already does this for precisely this reason.
retarget to 8.6
retarget after 8.6p1 release
I wondered whether this change from the OpenSSH 9.1/9.1p1 release notes might relate to this bug: * sftp(1), scp(1): when performing operations that glob(3) a remote path, ensure that the implicit working directory used to construct that path escapes glob(3) characters. This prevents glob characters from being processed in places they shouldn't, e.g. "cd /tmp/a*/", "get *.txt" should have the get operation treat the path "/tmp/a*" literally and not attempt to expand it. It doesn't seem to have used the same patch as Damien posted here in 2020, but nevertheless the bug seems to be fixed: I can no longer reproduce it using Andreas's procedure. Should this be closed?