Bug 438

Summary:	SFTP does not work for users with RSH shells
Product:	Portable OpenSSH	Reporter:	Bassel <bmzoueit>
Component:	sftp	Assignee:	OpenSSH Bugzilla mailing list <openssh-bugs>
Status:	CLOSED INVALID
Severity:	normal
Priority:	P2
Version:	-current
Hardware:	SPARC
OS:	Solaris

Description Bassel 2002-11-19 04:38:25 AEDT

Users with rsh (ristricted) shells on our Solaris 8 servers are unable to use 
SFTP. rsh is included in the /etc/shells file, so that's not the issue. The rsh 
shell users can SSH to the servers just fine, but they can't use SFTP. Any idea 
why this is happening? here are the errors we're getting:

linuddb3# ./sftp -v -oPort=##### temp@localhost  
Connecting to localhost...
OpenSSH_3.2.3p1, SSH protocols 1.5/2.0, OpenSSL 0x0090605f
debug1: Reading configuration data /apps/openssh/3.2.3p1/etc/ssh_config
debug1: Rhosts Authentication disabled, originating port will not be trusted.
debug1: restore_uid
debug1: ssh_connect: getuid 0 geteuid 0 anon 1
debug1: Connecting to localhost [127.0.0.1] port #####.
debug1: temporarily_use_uid: 0/1 (e=0)
debug1: restore_uid
debug1: temporarily_use_uid: 0/1 (e=0)
debug1: restore_uid
debug1: Connection established.
debug1: identity file /.ssh/id_rsa type -1
debug1: identity file /.ssh/id_dsa type -1
debug1: Remote protocol version 1.99, remote software version OpenSSH_3.2.3p1
debug1: match: OpenSSH_3.2.3p1 pat OpenSSH*
Enabling compatibility mode for protocol 2.0
debug1: Local version string SSH-2.0-OpenSSH_3.2.3p1
debug1: SSH2_MSG_KEXINIT sent
debug1: SSH2_MSG_KEXINIT received
debug1: kex: server->client aes128-cbc hmac-md5 none
debug1: kex: client->server aes128-cbc hmac-md5 none
debug1: SSH2_MSG_KEX_DH_GEX_REQUEST sent
debug1: expecting SSH2_MSG_KEX_DH_GEX_GROUP
debug1: dh_gen_key: priv key bits set: 130/256
debug1: bits set: 1589/3191
debug1: SSH2_MSG_KEX_DH_GEX_INIT sent
debug1: expecting SSH2_MSG_KEX_DH_GEX_REPLY
debug1: Host 'localhost' is known and matches the RSA host key.
debug1: Found key in /.ssh/known_hosts:31
debug1: bits set: 1619/3191
debug1: ssh_rsa_verify: signature correct
debug1: kex_derive_keys
debug1: newkeys: mode 1
debug1: SSH2_MSG_NEWKEYS sent
debug1: waiting for SSH2_MSG_NEWKEYS
debug1: newkeys: mode 0
debug1: SSH2_MSG_NEWKEYS received
debug1: done: ssh_kex2.
debug1: send SSH2_MSG_SERVICE_REQUEST
debug1: service_accept: ssh-userauth
debug1: got SSH2_MSG_SERVICE_ACCEPT
debug1: authentications that can continue: publickey,password
debug1: next auth method to try is publickey
debug1: try privkey: /.ssh/id_rsa
debug1: try privkey: /.ssh/id_dsa
debug1: next auth method to try is password
temp@localhost's password: 
debug1: ssh-userauth2 successful: method password
debug1: fd 5 setting O_NONBLOCK
debug1: channel 0: new [client-session]
debug1: send channel open 0
debug1: Entering interactive session.
debug1: ssh_session2_setup: id 0
debug1: Sending subsystem: sftp
debug1: channel request 0: subsystem
debug1: channel 0: open confirm rwindow 0 rmax 32768
debug1: channel 0: rcvd eof
debug1: channel 0: output open -> drain
debug1: channel 0: obuf empty
debug1: channel 0: close_write
debug1: channel 0: output drain -> closed
debug1: client_input_channel_req: channel 0 rtype exit-status reply 0
debug1: channel 0: rcvd close
debug1: channel 0: close_read
debug1: channel 0: input open -> closed
debug1: channel 0: almost dead
debug1: channel 0: gc: notify user
debug1: channel 0: gc: user detached
debug1: channel 0: send close
debug1: channel 0: is dead
debug1: channel 0: garbage collecting
debug1: channel_free: channel 0: client-session, nchannels 1
debug1: fd 0 clearing O_NONBLOCK
debug1: Transferred: stdin 0, stdout 0, stderr 0 bytes in 0.1 seconds
debug1: Bytes per second: stdin 0.0, stdout 0.0, stderr 0.0
debug1: Exit status 1
Connection closed

Comment 1 Ben Lindstrom 2002-11-19 05:46:30 AEDT

if the user logs in and types /path/to/sftp-server  does he/she get an error?
If rsh is impeeding running the command then it is a rsh issue and not a sftp
issue.

- Ben

Comment 2 Bassel 2002-11-19 07:25:17 AEDT

when running the sftp-server with the path specified, we get the "restricted" 
error... 
$ /apps/ssh/current/libexec/sftp-server       
rsh: /apps/ssh/current/libexec/sftp-server: restricted 

but when running it without specifying the path, it works.. 
$ sftp-server 
^C 
$ 

sounds like its an rsh issue.. any ideas on top of your head? 

Thanks, 
Bassel.

Comment 3 Ben Lindstrom 2002-11-19 09:53:23 AEDT

Only advice I can give you.  Is make sure that sftp-server is in the core system
path and change:

sshd_config:
# override default of no subsystems
Subsystem       sftp    /path/to/sftp-server

to:
# override default of no subsystems
Subsystem       sftp    sftp-server

- Ben

Comment 4 Damien Miller 2003-01-03 15:02:28 AEDT

This is an rsh problem, not a ssh problem

Comment 5 Damien Miller 2004-04-14 12:24:18 AEST

Mass change of RESOLVED bugs to CLOSED