sftp problems with 3.9 on HP

Do you have a question? Post it now! No Registration Necessary.  Now with pictures!

Threaded View
I have started compiling 3.9 on my systems and I notice when testing
it on an HP11 compiled with pam and with UsePam set to yes and
ChallengeResponseAuthentication also set to yes that ssh connects just
fine but when I sftp to the system I get disconnected right after
entering the passowrd. Here is the sftp -v -v -v output from right
after printing out the banner:

debug1: Authentications that can continue:
debug3: start over, passed a different list
debug3: preferred publickey,keyboard-interactive,password
debug3: authmethod_lookup keyboard-interactive
debug3: remaining preferred: password
debug3: authmethod_is_enabled keyboard-interactive
debug1: Next authentication method: keyboard-interactive
debug2: userauth_kbdint
debug2: we sent a keyboard-interactive packet, wait for reply
debug2: input_userauth_info_req
debug2: input_userauth_info_req: num_prompts 1
debug3: packet_send2: adding 32 (len 21 padlen 11 extra_pad 64)
debug2: input_userauth_info_req
debug2: input_userauth_info_req: num_prompts 0
debug3: packet_send2: adding 48 (len 10 padlen 6 extra_pad 64)
debug1: Authentication succeeded (keyboard-interactive).
debug2: fd 5 setting O_NONBLOCK
debug2: fd 6 is O_NONBLOCK
debug1: channel 0: new [client-session]
debug3: ssh_session2_open: channel_new: 0
debug2: channel 0: send open
debug1: Entering interactive session.
debug2: callback start
debug2: ssh_session2_setup: id 0
debug1: Sending subsystem: sftp
debug2: channel 0: request subsystem
debug2: callback done
debug2: channel 0: open confirm rwindow 0 rmax 32768
debug2: channel 0: rcvd adjust 131072
debug1: client_input_channel_req: channel 0 rtype exit-signal reply 0
debug2: channel 0: rcvd eof
debug2: channel 0: output open -> drain
debug2: channel 0: obuf empty
debug2: channel 0: close_write
debug2: channel 0: output drain -> closed
debug2: channel 0: rcvd close
debug2: channel 0: close_read
debug2: channel 0: input open -> closed
debug3: channel 0: will not send data after close
debug2: channel 0: almost dead
debug2: channel 0: gc: notify user
debug2: channel 0: gc: user detached
debug2: channel 0: send close
debug2: channel 0: is dead
debug2: channel 0: garbage collecting
debug1: channel 0: free: client-session, nchannels 1
debug3: channel 0: status: The following connections are open:
  #0 client-session (t4 r0 i3/0 o3/0 fd -1/-1)

debug3: channel 0: close_fds r -1 w -1 e 7
debug1: fd 0 clearing O_NONBLOCK
debug2: fd 1 is not O_NONBLOCK
debug1: Transferred: stdin 0, stdout 0, stderr 0 bytes in 0.8 seconds
debug1: Bytes per second: stdin 0.0, stdout 0.0, stderr 0.0
debug1: Exit status -1
Connection closed

Re: sftp problems with 3.9 on HP

Make sure sftp subsystem is available at the correct path specified in
sshd config and it should not get commented in sshd_config file

    "Subsystem       sftp    /path/to/sftp-server"

Re: sftp problems with 3.9 on HP

selvesteen@hotmail.com (Michael Selvesteen) wrote in message
Quoted text here. Click to load it

Thats not the problem as that setting has the correct path and good
permissions for the sftp-server binary.

Re: sftp problems with 3.9 on HP

Quoted text here. Click to load it

You might get more info by running the server in debug mode.  Also,
$ ssh -v -s sshserver sftp
$ ssh -v sshserver /path/to/sftp-server

My guess is that one of the shared libraries that sftp-server is linked
against is not in the system's default library search path (ie
LD_LIBRARY_PATH or its equivalant on HP-UX).  If that's the case you
should get some kind of error out of the latter command.

Darren Tucker (dtucker at zip.com.au)
GPG key 8FF4FA69 / D9A3 86E9 7EEE AF4B B2D4  37C9 C982 80C7 8FF4 FA69
    Good judgement comes with experience. Unfortunately, the experience
usually comes from bad judgement.

Re: sftp problems with 3.9 on HP

dtucker@dodgy.net.au (Darren Tucker) wrote in message
Quoted text here. Click to load it

My bad, I had checked the permissions on sftp-server, but neglected to
check them on /usr/local/libexec which someone had reset to 700 so
sshd couldnt find sftp-server. Works fine now. Thanks.

Site Timeline