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
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
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.
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
This is an rsh problem, not a ssh problem
Mass change of RESOLVED bugs to CLOSED