similar to: which sftp protocol is openssh or sftp-server using or support?

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

Dear list, Attached is a patch that implements the "append" command in a sftp session, as describe in "draft-ietf-secsh-filexfer-01" and further releases. It is for and had been tested on the current version of OpenSSH (the Portable CVS) and it works, also against non patched versions. The patch is "simple" it it just like the "do_upload" function in

Hello, I've gathered from searching Bugzilla[1][2] that a patch to update OpenSSH's SFTP implementation to support version 4 or above of the protocol is unlikely to be accepted. However, I find myself wishing for the name-based owner and group handling specified in version 4 of the spec[3]. As a possible compromise, if I submitted a patch to add an OpenSSH-specific extension to return

https://bugzilla.mindrot.org/show_bug.cgi?id=1953 --- Comment #3 from Christoph Anton Mitterer <calestyo at scientia.net> --- Does anyone know whether anything is going on with SFTP (especially also with repsect to ACLs and XATTRs)? More than a year ago we saw this http://tools.ietf.org/html/draft-moonesamy-secsh-filexfer-00 which apparently tried to restart the draft-ietf-secsh-filexfer

https://bugzilla.mindrot.org/show_bug.cgi?id=1068 Damien Miller <djm at mindrot.org> changed: What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |RESOLVED Resolution| |WONTFIX CC|

http://bugzilla.mindrot.org/show_bug.cgi?id=861 Summary: Swapped parameters of SSH_FXP_SYMLINK packet of SFTP protocol Product: Portable OpenSSH Version: -current Platform: All OS/Version: All Status: NEW Severity: normal Priority: P2 Component: sftp-server AssignedTo:

>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

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

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,

Hello, This is probably a long email, but please bear with me. I plan to submit a patch and would like to explain what I will do before doing it so I don't lose time if there's some flaw in my plan. I currently use sshfs to mount directories from some computers and a NAS into other computers. I recently noticed that when copying some files from one computer into one of these sshfs

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 :)

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

https://bugzilla.mindrot.org/show_bug.cgi?id=2227 Bug ID: 2227 Summary: Support version 6 Product: Portable OpenSSH Version: 6.6p1 Hardware: 68k OS: Mac OS X Status: NEW Severity: enhancement Priority: P5 Component: sftp-server Assignee: unassigned-bugs at mindrot.org

I received the following e-mail in response to an e-mail I had sent to SSH communications questioning the wisdom of their requesting OpenSSH to change it's name. Contained in the message is that statement that SSH Communications did not exert their trademark rights earlier becuase it's only recently that OpenSSH has become more visible. In the United States, this would invalidate the

https://bugzilla.mindrot.org/show_bug.cgi?id=1953 TJ Saunders <tj at castaglia.org> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |tj at castaglia.org --- Comment #6 from TJ Saunders <tj at castaglia.org> --- Instead of using custom SFTP

Hi, I wondered if there had ever been consideration to implementing check-file-handle / check-file-name in OpenSSH's sftp server? While it's only specified in an expired draft[1] some other implementations do support it. [1]: https://datatracker.ietf.org/doc/html/draft-ietf-secsh-filexfer-extensions-00#section-3

Dear SSH community, It has been brought to my attention that is has been disputed whether the term "SSH" can be used freely as a term to describe implementations compatible with the "SSH" protocols, due to trademark issues. In particular, the owner of the "SSH" trademark argues that implementations compatible with the "SSH" protocols shall no longer be

Are there any plans to support the SSH_FXF_TEXT file open flag (as specified in draft-ietf-secsh-filexfer-08.txt) in OpenSSH's sftpd? How about some of the other extensions (e.g. retrieving MD5 hashes and UTF-8 filenames)? Thanks for any info, -- Jim Matthews Fetch Softworks http://fetchsoftworks.com

https://bugzilla.mindrot.org/show_bug.cgi?id=1844 eb <email.bug at arcor.de> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |email.bug at arcor.de --- Comment #10 from eb <email.bug at arcor.de> --- Instead of patching in yet another

On Fri, 8 Nov 2024 at 03:16, Darren Tucker <dtucker at dtucker.net> wrote: > > On Thu, 7 Nov 2024 at 07:55, Chris Rapier <rapier at psc.edu> wrote: > >[...]I had been using > > Blake2b512 for the hashing algorithm but I want to put in a path to use > > xxhash instead. Maintaining backward compatibility means I need to know > > something about the remote.