sftp, chrooted, connection closed

[Carme Torca]

Hi,

I have installed in one HP-UX 11.23

OpenSSL A.00.09.08n.011 Secure Network Communications Protocol
Secure_Shell A.05.50.014 HP-UX Secure Shell

And I have created one user (prova3), but when I tried to do a connection, it says "Connection Closed"

I put the vervose log:

#sftp -v prova3@hpit61
OpenSSH_5.5p1+sftpfilecontrol-v1.3-hpn13v7, OpenSSL 0.9.8n 24 Mar 2010
HP-UX Secure Shell-A.05.50.014, HP-UX Secure Shell version
debug1: Reading configuration data /opt/ssh/etc/ssh_config
debug1: Connecting to hpit61 [14.20.7.39] port 22.
debug1: Connection established.
debug1: permanently_set_uid: 0/3
debug1: identity file /.ssh/id_rsa type -1
debug1: identity file /.ssh/id_rsa-cert type -1
debug1: identity file /.ssh/id_dsa type -1
debug1: identity file /.ssh/id_dsa-cert type -1
debug1: Remote protocol version 1.99, remote software version OpenSSH_5.5p1+sftpfilecontrol-v1.3-hpn13v7
debug1: match: OpenSSH_5.5p1+sftpfilecontrol-v1.3-hpn13v7 pat OpenSSH*
debug1: Enabling compatibility mode for protocol 2.0
debug1: Local version string SSH-2.0-OpenSSH_5.5p1+sftpfilecontrol-v1.3-hpn13v7
debug1: SSH2_MSG_KEXINIT sent
debug1: SSH2_MSG_KEXINIT received
debug1: AUTH STATE IS 0
debug1: REQUESTED ENC.NAME is 'aes128-ctr'
debug1: kex: server->client aes128-ctr hmac-md5 none
debug1: REQUESTED ENC.NAME is 'aes128-ctr'
debug1: kex: client->server aes128-ctr hmac-md5 none
debug1: SSH2_MSG_KEX_DH_GEX_REQUEST(1024<1024<8192) 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 'hpit61' is known and matches the RSA host key.
debug1: Found key in /.ssh/known_hosts:5
debug1: ssh_rsa_verify: signature correct
debug1: SSH2_MSG_NEWKEYS sent
debug1: expecting SSH2_MSG_NEWKEYS
debug1: SSH2_MSG_NEWKEYS received
debug1: Roaming not allowed by server
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: Trying private key: /.ssh/id_dsa
debug1: Next authentication method: keyboard-interactive
Password:
debug1: Authentications that can continue: publickey,password,keyboard-interactive
Password:
debug1: Authentication succeeded (keyboard-interactive).
debug1: Final hpn_buffer_size = 2097152
debug1: HPN Disabled: 1, HPN Buffer Size: 2097152
debug1: channel 0: new [client-session]
debug1: Requesting no-more-sessions@openssh.com
debug1: Entering interactive session.
debug1: Sending subsystem: sftp
debug1: client_input_channel_req: channel 0 rtype exit-status reply 0
debug1: client_input_channel_req: channel 0 rtype eow@openssh.com reply 0
debug1: channel 0: free: client-session, nchannels 1
debug1: fd 0 clearing O_NONBLOCK
debug1: fd 1 clearing O_NONBLOCK
Transferred: sent 1672, received 2168 bytes, in 0.0 seconds
Bytes per second: sent 68372.9, received 88655.8
debug1: Exit status 1
debug1: main thread: 0 drains, 0 waits
debug1: tid 2 - 4 fills, 0 skips, 1 waits
debug1: tid 3 - 0 fills, 4 skips, 1 waits
debug1: main thread: 0 drains, 0 waits
debug1: tid 4 - 4 fills, 0 skips, 1 waits
debug1: tid 5 - 0 fills, 4 skips, 1 waits
Connection closed
#


I don't know it it is normal:

Transferred: sent 1672, received 2168 bytes, in 0.0 seconds
Bytes per second: sent 68372.9, received 88655.8

Maybe is there one bug? But I have the lasted version of ssl and ssh installed...


Thanks a lot of!
Carmen.

[Matti_Kurkela]

Check the syslog at the server side.

The client-side log only tells that the authentication was successful, and then the connection just dies. Perhaps the remote endpoint could not start the sftp-server process: in that case, the error will be stored in the server's syslog.

Setting up a chrooted SFTP service will usually be much easier if you can use sshd's internal SFTP support instead of the external sftp-server process. To do this, change the Subsystem configuration line in the server's sshd_config file to:

Subsystem sftp internal-sftp

MK

[Jeeshan]

check the server where you are trying to log in.

if the user exist there or not.


or try to restart the service.

[Rita C Workman]

This may be a little left field, but sftp require two ports to be open (22 and 115).
Check with your network guy and see if 115 is open.

Rita

[Steven Schweda]

> This may be a little left field, but sftp
> require two ports to be open (22 and 115).

It's further out than left field. Different
game. Port 115 is "Simple File Transfer
Protocol (SFTP)", not "Secure [...]".

http://en.wikipedia.org/wiki/Simple_File_Transfer_Protocol

Not of much interest to most folks nowadays.
Port 22 (SSH) is plenty, and it's obviously
not blocked here.


Regarding the actual problem, normally I'd
suggest looking in the system log file on the
server, but in this case:

> [...]
> Transferred: sent 1672, received 2168 bytes, in 0.0 seconds
> Bytes per second: sent 68372.9, received 88655.8
[...]

That looks to me like some actual file
transfer. Around here, a simple command like
"sftp -v prova3@hpit61" stops at an "sftp> "
prompt, and waits for commands. For example:

dyi # uname -a
HP-UX dyi B.11.31 U ia64 4235313755 unlimited-user license

dyi # ssh -V
OpenSSH_5.2p1+sftpfilecontrol-v1.3-hpn13v5, OpenSSL 0.9.8k 25 Mar 2009
HP-UX Secure Shell-A.05.20.015, HP-UX Secure Shell version


dyi # sftp -v sms@dyi
Connecting to dyi...
OpenSSH_5.2p1+sftpfilecontrol-v1.3-hpn13v5, OpenSSL 0.9.8k 25 Mar 2009
HP-UX Secure Shell-A.05.20.015, HP-UX Secure Shell version
debug1: Reading configuration data /opt/ssh/etc/ssh_config
[...]
debug1: Authentications that can continue: publickey,password,keyboard-interactive
debug1: Next authentication method: publickey
debug1: Trying private key: /root/.ssh/id_rsa
debug1: Trying private key: /root/.ssh/id_dsa
debug1: read PEM private key done: type DSA
debug1: Authentication succeeded (publickey).
debug1: Final hpn_buffer_size = 2097152
debug1: HPN Disabled: 1, HPN Buffer Size: 2097152
debug1: channel 0: new [client-session]
debug1: Requesting no-more-sessions@openssh.com
debug1: Entering interactive session.
debug1: Sending subsystem: sftp
sftp>


If your "sftp" isn't stopping at the prompt,
then I wonder what you're running.

type sftp

Is this the real "sftp" program or some shell
script? If it's not a script, then I'd try
it as some other user. (Perhaps something in
the SSH client configuration file is causing
it to use some batch file without telling us?
Seems unlikely, though.)