savannah-hackers
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

[Savannah-hackers] [ 101853 ] sftp problem


From: nobody
Subject: [Savannah-hackers] [ 101853 ] sftp problem
Date: Wed, 26 Feb 2003 04:40:53 -0500


Support Request #101853, was updated on 2003-Feb-16 21:57
You can respond by visiting: 
http://savannah.gnu.org/support/?func=detailsupport&support_id=101853&group_id=11

Category: Download Area
Status: Open
Priority: 9
Summary: sftp problem

By: alexl
Date: 2003-Feb-26 01:40
Logged In: YES 
user_id=1168
Browser: Mozilla/5.0 Galeon/1.2.6 (X11; Linux i686; U;) Gecko/20020830

I think I'm getting to the bottom of this problem.   I think
there is a bug in the "/usr/local/bin/cvssh" script.  All
users on Savannah that *don't* have shell access to
savannah/subversions, upon an SSH connection are redirected
to the script "/usr/local/bin/cvssh", unlike those of us
with shell accounts which execute /usr/local/bin/bash (or
/bin/bash).  (This explains why most Savannah admins can't
duplicate the problem at their end, since they have shell
accounts and aren't routed through cvssh).

Here is the relevant excerpt from this script
"/usr/local/bin/cvssh", note that when executing "scp
/upload" and "cvs server" commands, it allows them.  
However note the special status of sftp.

[...]

valid=no
status=1
if test $# -eq 2 && test "X$1" = X-c; then
 case "X$2" in
 'Xcvs server')
  # Actually run it.
  valid=yes
  $2
  ;;

 'Xscp '*'-t /upload/'*)
  # Actually run it.
  valid=yes
  $2
  ;;

 'X/usr/lib/sftp-server')
  valid=yes
  /usr/local/bin/savannah-sftp
  ;;

[...]

fi

if test $valid = no; then
 echo "You tried to execute: \`$0${1+ address@hidden'." 1>&2
 echo "Sorry, you are only allowed to execute : " 1>&2 
 echo "CVS_RSH=ssh cvs commands" 1>&2 
 echo "rsync from /cvsroot or /upload." 1>&2
 echo "rsync to /upload." 1>&2
 echo "sftp to and from /upload." 1>&2
fi


Firstly, the sftp command has to be the full path to the
file ("/usr/lib/sftp-server"), which explains why Bill and
other non-shell account holders get the "Sorry, you are only
allowed..." message, unless he specifies the "-s" option.  

Secondly, *if* this full command is sent, then it attempts
to fork "/usr/local/bin/savannah-sftp", unfortunately this
file is of zero length:

address@hidden:~> cat /usr/local/bin/savannah-sftp
address@hidden:~> ls -l /usr/local/bin/savannah-sftp
-rwsr-xr-x    1 root     root            0 Feb  2 02:53
/usr/local/bin/savannah-sftp

which explains why the connection appears to be made, and is
then mysteriously terminated (running savannah-sftp at the
command line on subversions simply returns nothing on stdout
and an exit code of 0, matching Bill's output).

The fix would appear to be changing this command in cvssh to
"/usr/libexec/openssh/sftp-server" to match what happens in
the case of holders of shell accounts.

I'm also not sure why the format of the sftp doesn't follow
the same convention as the scp command, i.e. why doesn't it
look like:

'Xsftp '*'/upload/'*)
  # Actually run it.
  valid=yes
  /usr/libexec/openssh/sftp-server

instead of putting the entire path to sftp in the if shell
statement?

In any case, I can duplicate Bill's behaviour here, by
specifying the path to the broken savannah-sftp command:

address@hidden alex]$ sftp -1v -s /usr/local/bin/savannah-sftp
 address@hidden:/upload
Connecting to sv.gnu.org...
OpenSSH_3.4p1, SSH protocols 1.5/2.0, OpenSSL 0x0090602f
debug1: Reading configuration data /home/alex/.ssh/config
debug1: Applying options for *
debug1: /home/alex/.ssh/config line 46: Deprecated option
"FallBackToRsh"
debug1: Reading configuration data /etc/ssh/ssh_config
debug1: Applying options for *
debug1: Rhosts Authentication disabled, originating port
will not be trusted.
debug1: ssh_connect: needpriv 0
debug1: Connecting to sv.gnu.org [199.232.41.3] port 22.
debug1: Connection established.
debug1: identity file /home/alex/.ssh/id_dsa type 2
debug1: Remote protocol version 1.99, remote software
version OpenSSH_3.4p1 Debian 1:3.4p1-0.0woody1
debug1: match: OpenSSH_3.4p1 Debian 1:3.4p1-0.0woody1 pat
OpenSSH*
debug1: Local version string SSH-1.5-OpenSSH_3.4p1
debug1: Waiting for server public key.
debug1: Received server public key (768 bits) and host key
(1024 bits).
debug1: Host 'sv.gnu.org' is known and matches the RSA1 host
key.
debug1: Found key in /home/alex/.ssh/known_hosts:61
debug1: Encryption type: 3des
debug1: Sent encrypted session key.
debug1: cipher_init: set keylen (16 -> 32)
debug1: cipher_init: set keylen (16 -> 32)
debug1: Installing crc compensation attack detector.
debug1: Received encrypted confirmation.
debug1: Trying RSA authentication via agent with
'address@hidden'
debug1: Received RSA challenge from server.
debug1: Sending response to RSA challenge.
debug1: Remote: RSA authentication accepted.
debug1: RSA authentication accepted by server.
debug1: Requesting compression at level 6.
debug1: Enabling compression at level 6.
debug1: Sending command: /usr/local/bin/savannah-sftp
debug1: Entering interactive session.
debug1: fd 0 setting O_NONBLOCK
debug1: Transferred: stdin 9, stdout 0, stderr 0 bytes in
1.9 seconds
debug1: Bytes per second: stdin 4.7, stdout 0.0, stderr 0.0
debug1: Exit status 0
debug1: compress outgoing: raw data 53, compressed 60,
factor 1.13
debug1: compress incoming: raw data 5, compressed 8, factor 1.60
Connection closed


----------------------------------------------------------------------

By: w.northcott
Date: 2003-Feb-25 12:49
Logged In: YES 
user_id=8368
Browser: Mozilla/5.0 (Macintosh; U; PPC Mac OS X; en-us) AppleWebKit/60 (like 
Gecko) Safari/60

The -s option helped.  Now I end the same as the other failures:
debug1: RSA authentication accepted by server.
debug1: Sending command: /usr/lib/sftp-server
debug1: Entering interactive session.
debug1: fd 0 setting O_NONBLOCK
debug1: Transferred: stdin 9, stdout 0, stderr 0 bytes in 2.5 seconds
debug1: Bytes per second: stdin 3.6, stdout 0.0, stderr 0.0
debug1: Exit status 0
Connection closed

No error but no sftp prompt.

----------------------------------------------------------------------
You can respond by visiting: 
http://savannah.gnu.org/support/?func=detailsupport&support_id=101853&group_id=11




reply via email to

[Prev in Thread] Current Thread [Next in Thread]