Bug 2123

Summary:	does not seem to support sftp protocol version 5 rename flag for overwriting files
Product:	Portable OpenSSH	Reporter:	Martin Steigerwald <ms>
Component:	sftp-server	Assignee:	Assigned to nobody <unassigned-bugs>
Status:	CLOSED WORKSFORME
Severity:	enhancement	CC:	djm, dtucker
Priority:	P5
Version:	6.0p1
Hardware:	Other
OS:	Linux

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