secure shell 4.30_002 and chrooted ftp accounts.

[Antonio Cardoso_1]

Hi all,
I had the secure shell T1471AA A.04.20.004 working properly with chrooted accounts for both ssh and sftp.
After installing the A.04.30.002 version, accounts are still working with ssh but when connecting with sftp I get:
sftp myuser@myserver
Connecting to myserver...
Password:
Connection closed

in syslog, no error:
Jul 5 20:49:29 cairanne sshd[1616]: Connection from 155.132.233.83 port 53344
Jul 5 20:49:31 cairanne sshd[1616]: Failed none for sxmcftp from 155.132.233.83 port 53344 ssh2
Jul 5 20:49:35 cairanne sshd[1616]: Accepted keyboard-interactive/pam for sxmcftp from 155.132.233.83 port 53344 ssh2


I checked the configuration against instructions in /opt/ssh/README.hp but found no problem.

Did anyone already configure A.04.30.002 with chrooted accounts for sftp ?

thanks.
antonio.

[Steven E. Protter]

Shaom antonio,

There have been complaints on the 4.3 release.

I have not chrooted nor used this release.

please try ssh -vvv

You might get something helpful.

SEP

[Antonio Cardoso_1]

Shalom SEP,

I even tried to configure a new chrooted ssh/scp/sftp account using the embedded script /opt/ssh/ssh_chroot_setup.sh and get the same result: sftp for chrooted account prematurely closes connection.

Using -vvv as suggested shows:
---------------------------------------------
1) traces of sftp to non-chrooted account
(starting at authentication step):
debug2: we sent a keyboard-interactive packet, wait for reply
debug2: input_userauth_info_req
debug2: input_userauth_info_req: num_prompts 1
Password:
debug3: packet_send2: adding 32 (len 20 padlen 12 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 setting 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: client_session2_setup: id 0
debug1: Sending subsystem: sftp
debug2: channel 0: request subsystem confirm 1
debug2: callback done
debug2: channel 0: open confirm rwindow 0 rmax 32768
debug2: channel 0: rcvd adjust 5242880
debug2: Remote version: 3
debug3: Sent message fd 6 T:16 I:1
debug3: SSH_FXP_REALPATH . -> /home/axadmin
sftp>

----------------------------------------------
2) traces of sftp to chrooted account (starting at authentication step):
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
Password:
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 setting 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: client_session2_setup: id 0
debug1: Sending subsystem: sftp
debug2: channel 0: request subsystem confirm 1
debug2: callback done
debug2: channel 0: open confirm rwindow 0 rmax 32768
debug2: channel 0: rcvd adjust 5242880
debug1: client_input_channel_req: channel 0 rtype exit-status 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 cfd -1)

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

If anyone as another info, it will be welcome.

antonio.

[Steven E. Protter]

Its a bug.

Don't assume HP knows about it. Please contact the response center and report it. This is a serious security flaw and it doesn't matter whether or not you have a software contract.

SEP

[Antonio Cardoso_1]

SEP,
is there a WEB portal to submit the issue (the only one I found requires a software contract)

[Hiran Arias_1]

This is what I got from ITRC support:

cp -Rp /dev/null /newroot/dev/null
chmod 666 /newroot/dev/null

This solve the problem.

[Steven E. Protter]

Shalom,

This release is fatally flawed and should be backed out.

You should replace it with the last 4.2 release if you can get a copy. Call the response center if not and have them give it to you via ftp.

Also there is a major bug admitted by HP concerning largefiles and they promise a new release by the end of this month.

A thread exists on ITRC on this issue.

Thanks for the points from before. Good Luck with this one. My requests for a stable 4.2 version have been inpolitely ignored.

SEP

[Hiran Arias_1]

Hi SEP,

I just look into the download area and a new version of Secure Shell has been released: A.04.30.014/A.04.30.015.

In this version they fix the sftp problem on chrooted accounts and the 2Gb files transfer for the scp command.