problems with sftp on Tru64
From: Pablo Endres (Pablo_Endres_at_digitel.com.ve)
Date: 10/17/03
- Previous message: gary.ruesch_at_sungard.com: "RBACs and SSH"
- Next in thread: Darren Tucker: "Re: problems with sftp on Tru64"
- Reply: Darren Tucker: "Re: problems with sftp on Tru64"
- Maybe reply: Pablo Endres: "RE: problems with sftp on Tru64"
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ] [ attachment ]
Date: Fri, 17 Oct 2003 16:22:53 -0400 To: <secureshell@securityfocus.com>
Hi guy's,
I've been trying to make sftp work with OpenSSH_3.5p1 on my tru64 4.0G server.
SSH works fine, but when I try to use the subsystem all I get is connection closed. I tryed whats on the faq:
ssh <sever> /usr/bin/true and all I get is a list of my enviroment.
Using the client with -vvv I get the following:
stssema1: > sftp -v stssema2
Connecting to stssema2...
OpenSSH_3.7.1p2, SSH protocols 1.5/2.0, OpenSSL 0.9.7b 10 Apr 2003
debug1: Reading configuration data /etc/ssh/ssh_config
debug1: Connecting to stssema2 [.71] port 22.
debug1: Connection established.
debug1: identity file /.ssh/id_rsa type -1
debug1: identity file /.ssh/id_dsa type 2
debug1: Remote protocol version 1.99, remote software version OpenSSH_3.5p1
debug1: match: OpenSSH_3.5p1 pat OpenSSH_3.2*,OpenSSH_3.3*,OpenSSH_3.4*,OpenSSH_3.5*
debug1: Enabling compatibility mode for protocol 2.0
debug1: Local version string SSH-2.0-OpenSSH_3.7.1p2
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: SSH2_MSG_KEX_DH_GEX_INIT sent
debug1: expecting SSH2_MSG_KEX_DH_GEX_REPLY
debug1: Host 'stssema2' is known and matches the RSA host key.
debug1: Found key in /.ssh/known_hosts:1
debug1: ssh_rsa_verify: signature correct
debug1: SSH2_MSG_NEWKEYS sent
debug1: expecting SSH2_MSG_NEWKEYS
debug1: SSH2_MSG_NEWKEYS received
debug1: SSH2_MSG_SERVICE_REQUEST sent
debug1: SSH2_MSG_SERVICE_ACCEPT received
debug1: Authentications that can continue: publickey,password,keyboard-interactive
debug1: Next authentication method: publickey
debug1: Trying private key: /.ssh/id_rsa
debug1: Offering public key: /.ssh/id_dsa
debug1: Server accepts key: pkalg ssh-dss blen 433
debug1: read PEM private key done: type DSA
debug1: Authentication succeeded (publickey).
debug1: channel 0: new [client-session]
debug1: Entering interactive session.
debug1: Sending subsystem: sftp
debug1: client_input_channel_req: channel 0 rtype exit-status reply 0
debug1: channel 0: free: 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
On the server the dubug output is the following:
stssema2: /> /usr/security/sbin/sshd -D -ddd
debug3: Seeding PRNG from /usr/security/libexec/openssh/ssh-rand-helper
debug1: sshd version OpenSSH_3.5p1
debug1: private host key: #0 type 0 RSA1
debug3: Not a RSA1 key file /etc/ssh/ssh_host_rsa_key.
debug1: read PEM private key done: type RSA
debug1: private host key: #1 type 1 RSA
debug3: Not a RSA1 key file /etc/ssh/ssh_host_dsa_key.
debug1: read PEM private key done: type DSA
debug1: private host key: #2 type 2 DSA
debug1: Bind to port 22 on 0.0.0.0.
Server listening on 0.0.0.0 port 22.
Generating 768 bit RSA key.
RSA key generation complete.
debug1: Server will not fork when running in debugging mode.
Connection from .70 port 2449
debug1: Client protocol version 2.0; client software version OpenSSH_3.7.1p2
debug1: match: OpenSSH_3.7.1p2 pat OpenSSH*
debug1: Enabling compatibility mode for protocol 2.0
debug1: Local version string SSH-1.99-OpenSSH_3.5p1
debug1: list_hostkey_types: ssh-rsa,ssh-dss
debug1: SSH2_MSG_KEXINIT sent
debug1: SSH2_MSG_KEXINIT received
debug2: kex_parse_kexinit: diffie-hellman-group-exchange-sha1,diffie-hellman-group1-sha1
debug2: kex_parse_kexinit: ssh-rsa,ssh-dss
debug2: kex_parse_kexinit: aes128-cbc,3des-cbc,blowfish-cbc,cast128-cbc,arcfour,aes192-cbc,aes256-cbc,rijndael-cbc@lysator.liu.se
debug2: kex_parse_kexinit: aes128-cbc,3des-cbc,blowfish-cbc,cast128-cbc,arcfour,aes192-cbc,aes256-cbc,rijndael-cbc@lysator.liu.se
debug2: kex_parse_kexinit: hmac-md5,hmac-sha1,hmac-ripemd160,hmac-ripemd160@openssh.com,hmac-sha1-96,hmac-md5-96
debug2: kex_parse_kexinit: hmac-md5,hmac-sha1,hmac-ripemd160,hmac-ripemd160@openssh.com,hmac-sha1-96,hmac-md5-96
debug2: kex_parse_kexinit: none,zlib
debug2: kex_parse_kexinit: none,zlib
debug2: kex_parse_kexinit:
debug2: kex_parse_kexinit:
debug2: kex_parse_kexinit: first_kex_follows 0
debug2: kex_parse_kexinit: reserved 0
debug2: kex_parse_kexinit: diffie-hellman-group-exchange-sha1,diffie-hellman-group1-sha1
debug2: kex_parse_kexinit: ssh-rsa,ssh-dss
debug2: kex_parse_kexinit: aes128-cbc,3des-cbc,blowfish-cbc,cast128-cbc,arcfour,aes192-cbc,aes256-cbc,rijndael-cbc@lysator.liu.se,aes128-ctr,aes192-ctr,aes256-ctr
debug2: kex_parse_kexinit: aes128-cbc,3des-cbc,blowfish-cbc,cast128-cbc,arcfour,aes192-cbc,aes256-cbc,rijndael-cbc@lysator.liu.se,aes128-ctr,aes192-ctr,aes256-ctr
debug2: kex_parse_kexinit: hmac-md5,hmac-sha1,hmac-ripemd160,hmac-ripemd160@openssh.com,hmac-sha1-96,hmac-md5-96
debug2: kex_parse_kexinit: hmac-md5,hmac-sha1,hmac-ripemd160,hmac-ripemd160@openssh.com,hmac-sha1-96,hmac-md5-96
debug2: kex_parse_kexinit: none,zlib
debug2: kex_parse_kexinit: none,zlib
debug2: kex_parse_kexinit:
debug2: kex_parse_kexinit:
debug2: kex_parse_kexinit: first_kex_follows 0
debug2: kex_parse_kexinit: reserved 0
debug2: mac_init: found hmac-md5
debug1: kex: client->server aes128-cbc hmac-md5 none
debug2: mac_init: found hmac-md5
debug1: kex: server->client aes128-cbc hmac-md5 none
debug1: SSH2_MSG_KEX_DH_GEX_REQUEST received
debug1: SSH2_MSG_KEX_DH_GEX_GROUP sent
debug1: dh_gen_key: priv key bits set: 124/256
debug1: bits set: 1572/3191
debug1: expecting SSH2_MSG_KEX_DH_GEX_INIT
debug1: bits set: 1568/3191
debug1: SSH2_MSG_KEX_DH_GEX_REPLY sent
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: KEX done
debug1: userauth-request for user root service ssh-connection method none
debug1: attempt 0 failures 0
debug2: input_userauth_request: setting up authctxt for root
debug2: input_userauth_request: try method none
Failed none for root from .70 port 2449 ssh2
debug1: userauth-request for user root service ssh-connection method publickey
debug1: attempt 1 failures 1
debug2: input_userauth_request: try method publickey
debug1: test whether pkalg/pkblob are acceptable
debug1: temporarily_use_uid: 0/1 (e=0/1)
debug1: trying public key file //.ssh/authorized_keys
debug3: secure_filename: checking '/.ssh'
debug3: secure_filename: checking '/'
debug3: secure_filename: terminating check at '/'
debug1: matching key found: file //.ssh/authorized_keys, line 1
Found matching DSA key: :cd
debug1: restore_uid: 0/1
debug2: userauth_pubkey: authenticated 0 pkalg ssh-dss
Postponed publickey for root from 10.27.40.70 port 2449 ssh2
debug1: userauth-request for user root service ssh-connection method publickey
debug1: attempt 2 failures 1
debug2: input_userauth_request: try method publickey
debug1: temporarily_use_uid: 0/1 (e=0/1)
debug1: trying public key file //.ssh/authorized_keys
debug3: secure_filename: checking '/.ssh'
debug3: secure_filename: checking '/'
debug3: secure_filename: terminating check at '/'
debug1: matching key found: file //.ssh/authorized_keys, line 1
Found matching DSA key: :cd
debug1: restore_uid: 0/1
debug1: ssh_dss_verify: signature correct
debug2: userauth_pubkey: authenticated 1 pkalg ssh-dss
Accepted publickey for root from .70 port 2449 ssh2
debug1: Entering interactive session for SSH2.
debug1: fd 3 setting O_NONBLOCK
debug1: fd 7 setting O_NONBLOCK
debug1: server_init_dispatch_20
debug1: server_input_channel_open: ctype session rchan 0 win 131072 max 32768
debug1: input_session_request
debug1: channel 0: new [server-session]
debug1: session_new: init
debug1: session_new: session 0
debug1: session_open: channel 0
debug1: session_open: session 0: link with channel 0
debug1: server_input_channel_open: confirm session
debug1: server_input_channel_req: channel 0 request subsystem reply 1
debug1: session_by_channel: session 0 channel 0
debug1: session_input_channel_req: session 0 req subsystem
subsystem request for sftp
debug1: subsystem: exec() /usr/security/libexec/openssh/sftp-server
debug1: fd 9 setting O_NONBLOCK
debug2: fd 9 is O_NONBLOCK
debug1: Received SIGCHLD.
debug1: session_by_pid: pid 9325
debug1: session_exit_message: session 0 channel 0 pid 9325
debug1: channel request 0: exit-status
debug1: session_exit_message: release channel 0
debug1: channel 0: write failed
debug1: channel 0: close_write
debug1: channel 0: chan_shutdown_write: shutdown() failed for fd9: Socket is not connected
debug1: channel 0: output open -> closed
debug1: session_close: session 0 pid 9325
debug2: notify_done: reading
debug1: channel 0: read<=0 rfd 9 len 0
debug1: channel 0: read failed
debug1: channel 0: close_read
debug1: channel 0: input open -> drain
debug1: channel 0: ibuf empty
debug1: channel 0: send eof
debug1: channel 0: input drain -> closed
debug1: channel 0: send close
debug3: channel 0: will not send data after close
debug1: channel 0: rcvd close
debug3: channel 0: will not send data after close
debug1: channel 0: is dead
debug1: channel 0: garbage collecting
debug1: channel_free: channel 0: server-session, nchannels 1
debug3: channel_free: status: The following connections are open:
#0 server-session (t4 r0 i3/0 o3/0 fd 9/9)
debug3: channel_close_fds: channel 0: r 9 w 9 e -1
Connection closed by .70
Closing connection to .70
Any ideas on what the problem could be??
Thanks in advance
--- Democracy is two wolves and a sheep voting on what to have for dinner. Liberty is two wolves attempting to have a sheep for dinner and finding a well-informed, well-armed sheep. Pablo Endres *NIX Admin GSM: +584129913209
- Previous message: gary.ruesch_at_sungard.com: "RBACs and SSH"
- Next in thread: Darren Tucker: "Re: problems with sftp on Tru64"
- Reply: Darren Tucker: "Re: problems with sftp on Tru64"
- Maybe reply: Pablo Endres: "RE: problems with sftp on Tru64"
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ] [ attachment ]
Relevant Pages
|