similar to: SFTP and outstanding requests

Dear list, Attached is a patch that adds support for the SSH_FXP_LINK request, as described in draft-ietf-secsh-filexfer-07 onwards, to the sftp server and client. It is for and has been tested on the current portable snapshot but also applies to openbsd CVS. Thanks, -- Peter -------------- next part -------------- A non-text attachment was scrubbed... Name: openssh-sftp-hardlink-pcvs-v2.patch

I am using sshfs with FUSE to mount a remote directory over ssh/sftp (on linux). It would be nice if df could be able to show the total size/free space of the mounted directory. I am aware that returning size/free space would have some limitations. For example, if a subdir of the mounted directory has another filesystem mounted on the remote server, this can not be represented simply. However,

https://bugzilla.mindrot.org/show_bug.cgi?id=3054 Bug ID: 3054 Summary: sftp -R num_requests allows num_requests+1 Product: Portable OpenSSH Version: 8.0p1 Hardware: All OS: All Status: NEW Severity: minor Priority: P5 Component: sftp Assignee: unassigned-bugs at mindrot.org

In certain situations sftp download speed can be much less than that of scp. After many days of trying to find the cause finally I found it to be the tcp nagle algorithm, which if turned off with TCP_NODELAY eliminates the problem. Now I see it being discussed back in 2002, but it still unresolved in openssh-4.2 :( Simple solution would be to add a NoDelay option to ssh which sftp would set.

https://bugzilla.mindrot.org/show_bug.cgi?id=2948 Bug ID: 2948 Summary: implement "copy-data" sftp extension Product: Portable OpenSSH Version: -current Hardware: All URL: https://tools.ietf.org/html/draft-ietf-secsh-filexfer- extensions-00#section-7 OS: All Status: NEW

http://bugzilla.mindrot.org/show_bug.cgi?id=1286 Summary: SFTP keeps reading input until it runs out of buffer space Product: Portable OpenSSH Version: v4.5p1 Platform: All OS/Version: Linux Status: NEW Keywords: patch Severity: normal Priority: P2 Component: sftp

Hi All, After configuring and compiling OpenSSH version 4.6p1 in my SUN Solaris8 ultrasparc machine, I run "make tests" and got the following errors. The compiler used is GCC3.3. run test sftp.sh ... test basic sftp put/get: buffer_size 5 num_requests 1 sftp failed with 1 test basic sftp put/get: buffer_size 5 num_requests 2 sftp failed with 1 test basic sftp put/get: buffer_size 5

>Is there a simple way to achieve this behavior? Is there a document on >the sftp protocol somewhere? http://search.ietf.org/internet-drafts/draft-ietf-secsh-filexfer-00.txt -- Darren J Moffat

there is now a draft: http://www.ietf.org/internet-drafts/draft-ietf-secsh-filexfer-00.txt if someone could please check whether sftp-server.c comlies :)

Damien, Thanks for the response. Are you aware of any sftp server products that currently implement the uid / gid resolution or is this new draft just too unrefined / recent. Also, is there a definitive source for these drafts and where might they be published? Up till now I have just been reading the documentation available from www.openssh.org. I hope these questions aren't too

What to try: $ cd /tmp $ touch a b $ sftp localhost sftp> cd /tmp sftp> rename a b Couldn't rename file "/tmp/a" to "/tmp/b": Failure sftp> rm b Removing /var/tmp/b sftp> rename a b sftp> So, the sftp "rename" command refuses to rename a file to an existing one. Instead of using the rename(2) system call, which is present at least on

Reading 6.10 Dealing with Symbolic links in http://www.openssh.org/txt/draft-ietf-secsh-filexfer-02.txt it seems to say that the first argument ('linkpath') specifies the name of the symlink file to create. ("linkpath' specifies the path name of the symlink to be created"). However, sftp-server.c:process_symlink() seems to reverse this. I.E. the first argument

Hi OpenSSH developers, I'm using OpenSSH on a daily basis and I'm very pleased with the work you've done. I am contributing to some Open Source software hosted at Savannah https://savannah.nongnu.org/projects/tsp and we recently hit some sftp unexpected behavior: https://savannah.gnu.org/support/?105838 when using chmod sftp client command it appears that setuid / setgid bits are

Hello, This patch adds client and server support for transmitting the st_nlink field across SSH2_FXP_NAME and SSH2_FXP_ATTRS responses. Please let me know if there anything I can do to improve this patch. I am not subscribed to list so please CC me. Index: sftp-common.c =================================================================== RCS file: /cvs/src/usr.bin/ssh/sftp-common.c,v retrieving

On Wed, 27 Sep 2017, Martin Hecht wrote: > all tests passed on > > Ubuntu 16.04.3 LTS and > Scientific Linux release 6.9 (Carbon) > > On SUSE Linux Enterprise Server 11 SP3 LTSS I had to provide a local > installation of a newer openssl. I have chosen their current LTS version > 1.0.2l with shared library support enabled, and I had to tweak with > CFLAGS and LDFLAGS

Hi, it would be great, if the sftp protocol could be enhanced: get sha (or other hash value) from a file or part of a file. This would make it possible to run a rsync like file transfer on sftp. I would suggest a protocol like this Client sends to Server: get-supported hash-methods returns whitespace seperated list like md5 sha1 sha256 .... get-hash HASH-METHOD FILENAME STARTOFFSET

Hello, I am investigating a data-loss bug in SSHFS (https://github.com/libfuse/sshfs/issues/72). While the root cause is in SSHFS and has already been fixed, there seems to be some unfortunate interaction with what I believe is an OpenSSH bug: As far as I can tell, when sending a SSH_FXP_OPEN request with SSH_FXF_WRITE (i.e., opening the file write only), and then following up with a

Sorry if this is not the best place to post this question but I'm not sure who else to ask. After reading through the filexfer draft I am having trouble understanding how a sftp client goes about resolving uid / gid to its text representation. Without handling this translation for the user, how do they know the difference between one uid / gid to the next without opening up a terminal to the

Peter Stuge wrote: > > Matthieu Hautreux wrote: >> The change proposed by Cyril in sftp is a very pragmatic approach to >> deal with parallelism at the file transfer level. It leverages the >> already existing sftp protocol and its capability to write/read file >> content at specified offsets. This enables to speed up sftp transfers >> significantly by

Ok.. I'm starting official testing calls early this release. I'd like to have more feedback and more time for handling fixes. If people could test snapshots (http://www.openssh.org/portable.html, pick your favorate mirror and select snapshots directory) and report failures it would be useful. For those with pmake install there is regress/ which you can try out. It may help any platform