Bug 2123 - does not seem to support sftp protocol version 5 rename flag for overwriting files
Summary: does not seem to support sftp protocol version 5 rename flag for overwriting ...
Status: CLOSED WORKSFORME
Alias: None
Product: Portable OpenSSH
Classification: Unclassified
Component: sftp-server (show other bugs)
Version: 6.0p1
Hardware: Other Linux
: P5 enhancement
Assignee: Assigned to nobody
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2013-07-01 20:01 AEST by Martin Steigerwald
Modified: 2016-08-02 10:42 AEST (History)
2 users (show)

See Also:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Martin Steigerwald 2013-07-01 20:01:20 AEST
Due to http://bugs.debian.org/714606 I seek an alternative to ruby-net-ssh ssh.exec("mv old new") the authorized key file for our distkeys SSH key distribution tool that I currently packages for Debian (see there bug #712787).

I thought about using ruby-net-sftp rename! function as follows:

@sftp.rename!( newauthkeyfile, @authkeyfile, 0x0001 )


But I do get:

./distkeys -K somekey.pub -H somehost remove

Host: somehost
Connecting to host somehost (user: someuser, port: someport)...
Opening SFTP session...
Key somekey removed.
Creating a backup to .ssh/authorized_keys-2013-07-01.bak if not already done today...
Uploading keys to .ssh/authorized_keys-new...
File does exist and has correct size, moving to .ssh/authorized_keys...
.ssh/authorized_keys-new
.ssh/authorized_keys
/usr/lib/ruby/vendor_ruby/net/sftp/session.rb:846:in `wait_for': Net::SFTP::StatusException (4, "failure") (Net::SFTP::StatusException)
        from /usr/lib/ruby/vendor_ruby/net/sftp/session.rb:590:in `rename!'
        from ./distkeys:210:in `block in commit'
        from /usr/lib/ruby/vendor_ruby/net/sftp/request.rb:87:in `call'
        from /usr/lib/ruby/vendor_ruby/net/sftp/request.rb:87:in `respond_to'
        from /usr/lib/ruby/vendor_ruby/net/sftp/session.rb:948:in `dispatch_request'
        from /usr/lib/ruby/vendor_ruby/net/sftp/session.rb:911:in `when_channel_polled'
        from /usr/lib/ruby/vendor_ruby/net/ssh/connection/channel.rb:311:in `call'
        from /usr/lib/ruby/vendor_ruby/net/ssh/connection/channel.rb:311:in `process'
        from /usr/lib/ruby/vendor_ruby/net/ssh/connection/session.rb:214:in `block in preprocess'
        from /usr/lib/ruby/vendor_ruby/net/ssh/connection/session.rb:214:in `each'
        from /usr/lib/ruby/vendor_ruby/net/ssh/connection/session.rb:214:in `preprocess'
        from /usr/lib/ruby/vendor_ruby/net/ssh/connection/session.rb:197:in `process'
        from /usr/lib/ruby/vendor_ruby/net/ssh/connection/session.rb:161:in `block in loop'
        from /usr/lib/ruby/vendor_ruby/net/ssh/connection/session.rb:161:in `loop'
        from /usr/lib/ruby/vendor_ruby/net/ssh/connection/session.rb:161:in `loop'
        from /usr/lib/ruby/vendor_ruby/net/sftp/session.rb:802:in `loop'
        from /usr/lib/ruby/vendor_ruby/net/sftp/request.rb:72:in `wait'
        from /usr/lib/ruby/vendor_ruby/net/sftp/session.rb:842:in `wait_for'
        from /usr/lib/ruby/vendor_ruby/net/sftp/session.rb:320:in `lstat!'
        from ./distkeys:200:in `commit'
        from ./distkeys:589:in `handle_host'
        from ./distkeys:681:in `block in handle_gwhost'
        from ./distkeys:664:in `each'
        from ./distkeys:664:in `handle_gwhost'
        from ./distkeys:696:in `loop'
        from ./distkeys:801:in `<main>'


If I prepend an

@sftp.remove!( @authkeyfile )

the file rename works. But I'd like to avoid having the race condition.

Ideally I like to use flags 0x0001 for overwrite and 0x0002 for rewriting atomically for better security.

But according to ruby-net-sftp docs these require SFTP protocol version 5:

http://net-ssh.rubyforge.org/sftp/v2/api/

sftp client manpage as of openssh-client 6.0p1-4 (same on server) only refers to protocol versions 1 and 2, but I am not sure whether this refers to SSH or SFTP protocol version.

After trying to use SFTP to workaround the initial issue with ruby-net-ssh I will now try ruby-net-scp for both file upload and rename.

Thanks,
Martin
Comment 1 Martin Steigerwald 2013-07-01 20:03:53 AEST
git repo of script is at:

git://oss.teamix.org/distkeys.git

tag to reproduce problem is:

openssh-bug-2123

Thanks,
Martin
Comment 2 Darren Tucker 2013-07-01 20:18:55 AEST
OpenSSH does not support sftp protocol version 5 and given the required complexity to do so is unlikely to any time soon.

It does implement a vendor extension to protocol version 3 ("posix-rename@openssh.com") that does what you want.

The details are in 
http://openssh.com/specs.html and http://www.openbsd.org/cgi-bin/cvsweb/src/usr.bin/ssh/PROTOCOL?rev=HEAD;content-type=text/plain
Comment 3 Martin Steigerwald 2013-07-01 21:35:54 AEST
Thanks, Darren, reported issue upstream at:

please support protocol version 3 ("posix-rename@openssh.com")
https://github.com/net-ssh/net-sftp/issues/31

Since Ruby Net SCP does not yet seem to support renames I am using the delete first, rename them work-around for now to get distkeys compatible with Ruby 1.9 until a more solution becomes viable.
Comment 4 Damien Miller 2013-10-10 11:51:27 AEDT
Closing: this looks like a bug in ruby-net-ssh rather than sftp-server.
Comment 5 Martin Steigerwald 2013-10-14 19:09:57 AEDT
Damien, huh? It is an SFTP v5 protocol feature that OpenSSH does not support. In what way is this SFTP v5 protocol less important than the vendor extension to protocol version 3 ("posix-rename@openssh.com").

In other words: I do not agree to the notion of "we don't support this feature of the protocol, but the client uses is, thus its the client fault" I read out of your statement.

Resolution "WORKSFORME" also does not seem to apply or did you test with recent version of ruby-net-sftp or did you at least test the vendor extension rename function?
Comment 6 Damien Miller 2013-10-14 21:35:02 AEDT
It's totally the client's fault if it calls a protocol method that doesn't exist for the revision of the protocol that the server advertises.

We decided long ago not to support versions of the sftp protocol after 3; the standards process ran off the rails at that point. We're happy to add specific features that people need as protocol extensions (and document them in our PROTOCOL file).
Comment 7 Martin Steigerwald 2013-10-14 23:14:01 AEDT
Hmmm, okay, the server doesn't advertise V5. Well.
Comment 8 Damien Miller 2016-08-02 10:42:12 AEST
Close all resolved bugs after 7.3p1 release