ewxrjk/sftpserver

Experimental SFTP server

Green End SFTP Server

This is an SFTP server supporting up to protocol version 6. It is possible to use it as a drop-in replacement for the OpenSSH server.

Requirements

This software runs under Linux and macOS. It may work on other UNIX platforms.

Installation

The general procedure is:

./autogen.sh
./configure
make check       # builds software and runs tests
make install     # probably as root

See INSTALL for generic instructions. Local configure options include:

• --enable-reversed-symlink - some (but annoyingly not all) SFTP clients get the arguments to the symlink operation the wrong way round. This option reverses the server’s interpretation of the arguments so that such clients can be made to work (while breaking correctly written clients).
• --enable-warnings-as-errors - enable treatment of warnings-as-errors. Developers should use this but end users probably don’t care.

You will need iconv and readline libraries.

It’s best to run make check before installing. This requires Python 3 to be installed:

apt install python3 python3-termcolor

Status

The code is written to be secure against malicious clients but not routinely tested against malicious clients (although it has undergone fuzzing). In the typical usage pattern for an SFTP server this is academic: why bother exploiting a SFTP server bug when you can log in as the same user?

However it is also possible to arrange for the SFTP server to run on a security boundary, for instance listening directly on a TCP port or running under a login that is only allowed to run the SFTP server.

Until such time as the test suite is expanded to include actively hostile clients, it is not recommended that this server be used in such configurations without some additional form of protection against malicious use.

Online Resources

• sgo-software-discuss: discussion of the server (and others), bug reports, etc
• sgo-software-announce: announcements of new versions
• www.greenend.org.uk/rjk/sftpserver: home page
• github.com/ewxrjk/sftpserver: source code

To get the latest source (to within 24 hours):

git clone git://github.com/ewxrjk/sftpserver.git

New releases are signed with PGP key 9006B0ED710DB81B76D368D9D3388BA18A741BEF.

Bugs, Patches, etc

Please either send bug reports, improvements, etc to sgo-software-discuss or use GitHub.

If you send patches, please use diff -u format.

Licence

Copyright (C) 2007, 2009-2011, 2014-18 Richard Kettlewell

Portions copyright (C) 2015 Michel Kraus

This program is free software; you can redistribute it and/or modify it under the terms of the GNU General Public License as published by the Free Software Foundation; either version 2 of the License, or (at your option) any later version.

This program is distributed in the hope that it will be useful, but WITHOUT ANY WARRANTY; without even the implied warranty of MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU General Public License for more details.

You should have received a copy of the GNU General Public License along with this program; if not, write to the Free Software Foundation, Inc., 59 Temple Place, Suite 330, Boston, MA 02111-1307 USA

sftpserver's Issues

New release?

I just ran into 4b5c7eb but it's been fixed years ago -- that's great. Can I help in any way with releasing a new version? Latest Debian appears to be shipping this bug still.

Large file sizes incorrect (Filezilla & Transmit clients)

The file size shown for large files have the right digits but are out by factor of - in the cases I've looked at - 10 or 100.
eg, ls -al gives 739159296, the SFTP client (Filezilla and Transmit) gives 73.9MB
ls -al gives 1365402224, the SFTP client eg Transmit gives 13.7MB

Same clients accessing other sites using FTP get the right answer.
I've set up SFTP on my Austor NAS and transferred a large file there, again the size numbers are right.

It is as if the SFTP clients ask for a directory listing from Greenend-sftp and for large files the number is incorrect, or greenend-ftp is using some convention that our sftp clients don't recognise?

It's hardly "mission critical" but is this a known bug, or "working as designed" or due to something other than greenend-sftp on dropbear?

...Ian.

Error: "Received SSH2_MSG_CHANNEL_DATA for nonexistent channel 0"

Hi,

when using Dropbear together with this sftp server (and WinSCP),
I get after like transferring a few hundred Megabytes:

Can I help debug this somehow?

Use statx if available

On some systems (Debian 11.3 for one) st_atimespec is absent and thus the timestamps for stat & friends don't have sub-second resolution. statx could be an alternative, that's what coreutils appears to be using. Has anyone looked into this before?

Proposal for a new `lsetstat` extension

When porting SSHFS over to SFTP v6, I encountered an old issue of theirs, being that there was no support for [email protected]. #640038 - sshfs: cannot set timestamps of symbolic links - Debian Bug report logs.

SFTP v3 handles user and group via IDs and not strings. So OpenSSH's [email protected] won't really be applicable here.

What do you think about creating a new extension, that extends SSH_FXP_FSETSTAT so it sets the stat on the symlink?

Test suite depends on Python 2

It's 2018, it should use Python 3.

Locking does not work.

Hi,

I've found out that locking does not work yet. I got the reply 8:unsupported.
See also comment on line 184 in v6.c.
Please enable. This requires possibly a table of current locks, and their level.

Stef

SFTP Client on Humax

I wondered if Greenend-SFTP provides the client on Humax as well as the server. The client has little to say who is the author and
source.

If it's not you then please close straight away, I'm sorry to have bothered you.

Our problem with the "quick and dirty" SFTP client on Humax is that it doesn't work with Dropbear's SSH DBClient; on our 2018 version of dropbear's DBClient the SFTP client cannot tell SSH client where the private key is. And there's no working
"standard location" for dropbear, nor any configuration file.

...Ian.

Job reordering trips OpenSSH `scp`

Job reordering is probably not an issue in this project in particular, because it seems OpenSSH scp is the one that has problems handling reordering of responses. I posted this to raise awareness of the problem, and to request a configure option to disable reordering for the sake of compatibility.

See: openssh/openssh-portable@9b73345#commitcomment-110679778

For the moment, my hack around the issue is to always return 0 from reorderable() in serialize.c.

Bogus compiler warning on 64-bit platforms

sftpclient.c:558:10: warning: comparison of constant 92233720368547758 with expression of type 'uint32_t' (aka 'unsigned int') is always false [-Wtautological-constant-out-of-range-compare]
    if(n > SIZE_MAX / sizeof(struct sftpattr))
       ~ ^ ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
1 warning generated.

Harmless in terms of the code but it means -Werror can't be enabled.

cross_complier is lack of "-lpthread"

need to append "-lpthread" at end of CC in makefile like:
CC = arm-hisiv500-linux-gcc -Wall -W -Wpointer-arith -Wbad-function-cast -Wno-type-limits -Wwrite-strings -Wmissing-prototypes -Wmissing-declarations -Wnested-externs -lpthread

Testing for nanosecond timestamp support

The recent trouble with addition of nanosecond timestamp support suggests that this part of the code is under-tested. More tests should be added to properly exercise this code.

Some care is needed to ensure that it has a reasonable chance of working across platforms.

sftpclient does not handle cwd correctly

example session:

$ ./sftpclient localhost
sftp> pwd
/home/vapier
sftp> ls -l f
-rw-r--r--   ? 8282     100             0 Sep 30 16:09 f
sftp> ls -l /tmp/f
-rw-r--r--   ? 8282     100          7720 Sep 28 01:54 /tmp/f
sftp> cd /tmp
sftp> ls -l f
-rw-r--r--   ? 8282     100             0 Sep 30 16:09 f

even though i did cd /tmp, the ls -l f request requested information about f instead of /tmp/f. the server does not maintain cwd state for the client (ignoring the initial chdir($HOME) that most servers do), so the client has to manually construct the fullpath based on its local understanding of the cwd.

hence, ls -l f should be translated by the client to ls -l /tmp/f. but it is not.

server logging also shows this:

Sep 30 16:09:30 [sftp-server] session opened for local user vapier from [::1]
Sep 30 16:09:30 [sftp-server] received client version 3
Sep 30 16:09:30 [sftp-server] downgrading server version from 4
Sep 30 16:09:40 [sftp-server] debug3: request 1: realpath
Sep 30 16:09:40 [sftp-server] realpath "."
Sep 30 16:09:40 [sftp-server] debug1: request 1: sent names count 1
Sep 30 16:09:42 [sftp-server] debug3: request 2: lstat
Sep 30 16:09:42 [sftp-server] lstat name "f"
Sep 30 16:09:42 [sftp-server] debug1: request 2: sent attrib have 0xf
Sep 30 16:09:48 [sftp-server] debug3: request 3: lstat
Sep 30 16:09:48 [sftp-server] lstat name "/tmp/f"
Sep 30 16:09:48 [sftp-server] debug1: request 3: sent attrib have 0xf
Sep 30 16:09:57 [sftp-server] debug3: request 4: realpath
Sep 30 16:09:57 [sftp-server] realpath "/tmp"
Sep 30 16:09:57 [sftp-server] debug1: request 4: sent names count 1
Sep 30 16:09:57 [sftp-server] debug3: request 5: lstat
Sep 30 16:09:57 [sftp-server] lstat name "/tmp"
Sep 30 16:09:57 [sftp-server] debug1: request 5: sent attrib have 0xf
Sep 30 16:09:58 [sftp-server] debug3: request 6: lstat
Sep 30 16:09:58 [sftp-server] lstat name "f"
Sep 30 16:09:58 [sftp-server] debug1: request 6: sent attrib have 0xf
Sep 30 16:10:48 [sftp-server] debug1: read eof
Sep 30 16:10:48 [sftp-server] session closed for local user vapier from [::1]

Omitting invalid timestamps (v3)

sftpserver/v3.c

Lines 115 to 123 in 62913a9

	/* Check that the conversion was sound. SFTP v3 becomes unsound in 2038CE.
	* If you're looking at this code then, I suggest using a later protocol
	* version. If that's not acceptable, and you either don't care about
	* bogus timestamps or have some other workaround, then delete the
	* checks. */
	if(m != attrs->mtime.seconds)
	sftp_fatal("sending out-of-range mtime");
	if(a != attrs->atime.seconds)
	sftp_fatal("sending out-of-range mtime");

The comment here is a bit misleading when it says that V3 will become unsound in 2038, since V3 also can't represent timestamps before 1970 and indeed the condition here triggers in this case. It's easy to imagine legitimate uses for such old timestamps, and of course that's why V5 switched to signed values.

Also I've come across a few files from the far future, usually resulting from unpacking a corrupted archive.

At any rate, using sftp_fatal here is a little unfortunate. First, despite the name and its documentation, it doesn't actually terminate the process so the connection just hangs. But even if it did close the connection, this would be a pretty harsh treatment when all the client wanted to do was learn the attributes of a file. Would it be better to simply omit the timestamps from the output in this case? A white lie, so to speak?

LeakSanitizer reports memory leak in config file parser

Environment

export UBSAN_OPTIONS=print_stacktrace\=1
export CXX=clang\+\+\-14\ \ \-Wno\-deprecated\-copy
export LC_CTYPE=en_GB\.UTF\-8
export CFLAGS=\-fsanitize\=address\,undefined\,integer\,nullability\ \-O0\ \-fno\-optimize\-sibling\-calls\ \-fno\-omit\-frame\-pointer\ \-fno\-sanitize\-recover\=all\ \-g
export CC=clang\-14
export CXXFLAGS=\-fsanitize\=address\,undefined\,integer\,nullability\ \-O0\ \-fno\-optimize\-sibling\-calls\ \-fno\-omit\-frame\-pointer\ \-fno\-sanitize\-recover\=all\ \-g\ \-Wno\-deprecated\-copy

Error

*                                                                                                                                                                                                           
*                                =================================================================                                                                                                          
*                                ==140010==ERROR: LeakSanitizer: detected memory leaks                                                                                                                      
*                                                                                                                                                                                                           
*                                Direct leak of 11 byte(s) in 1 object(s) allocated from:                                                                                                                   
*                                    #0 0x55b7b8ebc3ce in __interceptor_malloc (/var/lib/build/_builds/clang-sanitizers/sftpserver/gesftpserver+0xda3ce) (BuildId: a8816a334a9ba78f8ebddcccb90949de47333bbf)
*                                    #1 0x55b7b8f0a9ca in sftp_xmalloc /var/lib/build/_builds/clang-sanitizers/sftpserver/utils.c:59:14                                                                     
*                                    #2 0x55b7b8f4233b in sftpconf_split /var/lib/build/_builds/clang-sanitizers/sftpserver/sftpconf.c:33:18                                                                
*                                    #3 0x55b7b8f41974 in sftpconf_read /var/lib/build/_builds/clang-sanitizers/sftpserver/sftpconf.c:82:21                                                                 
*                                    #4 0x55b7b8ef7809 in main /var/lib/build/_builds/clang-sanitizers/sftpserver/sftpserver.c:507:3                                                                        
*                                    #5 0x7f4ffce9b189 in __libc_start_call_main csu/../sysdeps/nptl/libc_start_call_main.h:58:16                                                                           
*                                                                                                                                                                                                           
*                                SUMMARY: AddressSanitizer: 11 byte(s) leaked in 1 allocation(s).                                                                                                           

Test against well-known clients

Description

Periodically we run into issues with well known clients, e.g. Paramiko or OpenSSH.
In order to get earlier site of these (and identify configurations that support them, prevent regressions) it should be possible to routinely test against them.

Analysis

My expectation is that this will be a set of docker containers used to run tests against various clients (and probably various platforms).

Handling of local encoding in gesftpserver

I tried out the latest gesftpserver code on my distro of choice (Gentoo Linux).

As a test, I downloaded some files using WinSCP with SFTP v6 enabled. Transferring files with ASCII filenames works fine, but transferring filenames with characters outside the ASCII range fails and the connection gets dropped.

I debugged the gesftpserver process, and I was hitting a fatal error in sftp_send_path. This ends up calling sftp_iconv to translate the path from the "local encoding" to UTF-8. I store all my filenames in UTF-8 on disk, so this doesn't make much sense.

Looking into it, I see that sshd (OpenSSH) has LANG=en_US.UTF-8 set in the environment, which it inherits from systemd. However, when sshd forks to start a new login session, it wipes the environment, including LANG. In other words, sftp_iconv fails fails due to LANG and LC_CTYPE being unset in the environment.

I was able to get the transfer to succeed by setting LANG=en_US.UTF-8 via the pam_env module, which gets invoked after the new session is created by sshd.

It seems like there must be a better way to make this work. I know that Linux doesn't really keep track of the encoding used for filenames. However, maybe the gesftpserver program could check to see if the string is already a valid UTF-8 sequence before throwing an encoding error?

sftp version >3 results in strange windows mount behaviour?

Hi,

i switched openssh sft module on a ubuntu machine to Green End SFTP Server and WinSCP correctly reports "sftp-6" on connecting, so all seems fine. If i now use any virtual drive (windows based) mount client that explicitly supports sftp version greater than 3, i loose the ability to directly execute windows .exe files from my portable apps collection? (I see a "the request is not supported" error in Win7.)

"https://www.eldos.com/sftp-net-drive/" ----> supports V3-6 settable in the profile
"http://www.southrivertech.com/products/webdrive/" ----> supports V3-4, settable

I also noticed that in Version3 i can use a media player and directly play/seek in a large mp4 file without a complete download, so random block access works. The moment i set anything higher then V3 i also loose this ability along with not being able to directly start executable over the mounted sftp drive.

Any idea what causes this changed behavior for sftp version 4-6 on clients that actually support them?

thx
Andy

Empty path should resolve to homedir.

Hi,
an empty path should lead to the homedirectory, as mentioned in

https://tools.ietf.org/html/draft-ietf-secsh-filexfer-13#section-6

but also in earlier versions.
The current version responds with ENOENT.

Stef

Feature request: Allow sftpclient to bypass ssh

Currently sftpclient can connect to the SFTP server in one of the following ways:

1. With OpenSSH ssh. This is the default.
2. With Dropbear SSH's client dbclient. This is available with the -r option.
3. Any other program through the -P option.

In the last setup, one can supply two undocumented options --program-config and --program-debug-path as shown here. But they seem to be the only options that affect the command line.

My use case is that I want to try out a server-client setup locally without passing through ssh. The quick solution is to use nc. But nc requires two positional arguments for host and port. This is currently impossible with options at disposal in sftpclient. My workaround is to wrap around nc to read arguments from environment variables, allowing it to be called without any arguments.

I feel that the client can invoke nc to make the connection. Do you consider adding a general option that specifically allows bypassing ssh in this way?