SOLVED! Re: problems with chroot sftp user

[Richard Pereira_1]

Hi,

Going in circles with this problem. Client wants to have a chrooted sftp only user. They have had some in the past but I cannot confirm when exactly. I tried adding a new user and it fails, so to remove any weird perms issues, I will use a new user with a completely new path.

OS verison B.11.11

OpenSSH_3.7.1p2-pwexp26, SSH protocols 1.5/2.0, OpenSSL 0.9.7c 30 Sep 2003
HP-UX_Secure_Shell-A.03.71.000, HP_UX Secure Shell version

I go and use the povided script /opt/ssh/ssh_chroot_setup.sh, create a new user called bob, provided the path /newroot, modified his entry in /etc/passwd to this

bob:6o9NUcbnPEuqE:107:20:chrooted user:/newroot/./home/bob:/bin/sh

also made sure /etc/passwd and /etc/group were copied into /newroot/etc

Now, if I try to sftp as any regular user, it works and I can even see sftp-server putting positive logging info into syslog.log

But if i try to sftp as bob i get the following output and it kicks me out. The syslog only shows a std ssh succesfull login.

[rpereira@devap1]# sftp -vvv bob@server    
Connecting to server...
OpenSSH_3.7.1p2-pwexp26, SSH protocols 1.5/2.0, OpenSSL 0.9.7c 30 Sep 2003
HP-UX_Secure_Shell-A.03.71.000, HP_UX Secure Shell version
debug1: Reading configuration data /opt/ssh/etc/ssh_config
debug3: Seeding PRNG from /opt/ssh/libexec/ssh-rand-helper
debug2: ssh_connect: needpriv 0
debug1: Connecting to s530k_nb [10.128.85.145] port 22.
debug1: Connection established.
debug1: identity file /home/rpereira/.ssh/id_rsa type -1
debug1: identity file /home/rpereira/.ssh/id_dsa type -1
debug1: Remote protocol version 2.0, remote software version OpenSSH_4.1
debug1: match: OpenSSH_4.1 pat OpenSSH*
debug1: Enabling compatibility mode for protocol 2.0
debug1: Local version string SSH-2.0-OpenSSH_3.7.1p2-pwexp26
debug3: RNG is ready, skipping seeding
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,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: kex_parse_kexinit: diffie-hellman-group-exchange-sha1,diffie-hellman-group14-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: server->client aes128-cbc hmac-md5 none
debug2: mac_init: found hmac-md5
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
debug2: dh_gen_key: priv key bits set: 128/256
debug2: bits set: 1033/2048
debug1: SSH2_MSG_KEX_DH_GEX_INIT sent
debug1: expecting SSH2_MSG_KEX_DH_GEX_REPLY
debug3: check_host_in_hostfile: filename /home/myuser/.ssh/known_hosts
debug3: check_host_in_hostfile: match line 15
debug3: check_host_in_hostfile: filename /home/myuser/.ssh/known_hosts
debug3: check_host_in_hostfile: match line 15
debug1: Host 's530k_nb' is known and matches the RSA host key.
debug1: Found key in /home/myuser/.ssh/known_hosts:15
debug2: bits set: 1055/2048
debug1: ssh_rsa_verify: signature correct
debug2: kex_derive_keys
debug2: set_newkeys: mode 1
debug1: SSH2_MSG_NEWKEYS sent
debug1: expecting SSH2_MSG_NEWKEYS
debug2: set_newkeys: mode 0
debug1: SSH2_MSG_NEWKEYS received
debug1: SSH2_MSG_SERVICE_REQUEST sent
debug2: service_accept: ssh-userauth
debug1: SSH2_MSG_SERVICE_ACCEPT received
debug2: key: /home/myuser/.ssh/id_rsa (00000000)
debug2: key: /home/myuser/.ssh/id_dsa (00000000)
debug3: input_userauth_banner

|-----------------------------------------------------------------|
| This system is for the use of authorized users only.            |
| Individuals using this computer system without authority, or in |
| excess of their authority, are subject to having all of their   |
| activities on this system monitored and recorded by system      |
| personnel.                                                      |
|                                                                 |
|| Anyone using this system expressly consents to such monitoring |
| and is advised that if such monitoring reveals possible         |
| evidence of criminal activity, system personnel may provide the |
| evidence of such monitoring to law enforcement officials.       |
|-----------------------------------------------------------------|


debug1: Authentications that can continue: publickey,password,keyboard-interactive
debug3: start over, passed a different list publickey,password,keyboard-interactive
debug3: preferred gssapi,publickey,keyboard-interactive,password
debug3: authmethod_lookup publickey
debug3: remaining preferred: keyboard-interactive,password
debug3: authmethod_is_enabled publickey
debug1: Next authentication method: publickey
debug1: Trying private key: /home/myuser/.ssh/id_rsa
debug3: no such identity: /home/myuser/.ssh/id_rsa
debug1: Trying private key: /home/myuser/.ssh/id_dsa
debug3: no such identity: /home/myuser/.ssh/id_dsa
debug2: we did not send a packet, disable method
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
debug1: Authentications that can continue: publickey,password,keyboard-interactive
debug3: userauth_kbdint: disable: no info_req_seen
debug2: we did not send a packet, disable method
debug3: authmethod_lookup password
debug3: remaining preferred:
debug3: authmethod_is_enabled password
debug1: Next authentication method: password
bob@server's password:
debug3: packet_send2: adding 64 (len 54 padlen 10 extra_pad 64)
debug2: we sent a password packet, wait for reply
debug1: Authentication succeeded (password).
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: 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-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)

debug3: channel 0: close_fds r -1 w -1 e 7
debug1: fd 0 clearing O_NONBLOCK
debug1: fd 1 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 141
Connection closed

[Dennis Handly]

>also made sure /etc/passwd and /etc/group were copied into /newroot/etc

I thought you need to copy more than those files?

[Richard Pereira_1]

It does but what else should I check for?

[Patrick Wallek]

Here are some links with info on chroot'ing SFTP:

http://h30499.www3.hp.com/t5/Security/Configuring-sftp-with-chroot/td-p/4261898

http://bizsupport1.austin.hp.com/bizsupport/TechSupport/Document.jsp?lang=en&cc=us&taskId=120&prodSeriesId=3215373&prodTypeId=18964&objectID=c01711417

[Richard Pereira_1]

thanks for the link. I've already used the same instructions as the first one. My chroot user cant sftp but regular users can. Second link I dont think will work since my version of ssh is so much older.

[Richard Pereira_1]

heres more info, if i try calling the subsystem (ssh -s sftp-server -vvv bob@server)

i get a slightly different ending

ebug3: packet_send2: adding 64 (len 54 padlen 10 extra_pad 64)
debug2: we sent a password packet, wait for reply
debug1: Authentication succeeded (password).
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: ssh_session2_setup: id 0
debug1: Sending subsystem: sftp-server
debug2: channel 0: request subsystem
debug2: callback done
debug2: channel 0: open confirm rwindow 0 rmax 32768
Request for subsystem 'sftp-server' failed on channel 0
debug1: Calling cleanup 0x4001595a(0x0)
debug1: channel 0: free: client-session, nchannels 1
debug3: channel 0: status: The following connections are open:
  #0 client-session (t4 r0 i0/0 o0/0 fd 5/6)

debug3: channel 0: close_fds r 5 w 6 e 7
debug1: Calling cleanup 0x40015a3a(0x0)
Connection closed

so for some reason it cant call or execute sftp-server?? permissions look ok.

[Matti_Kurkela]

Check your /opt/ssh/etc/sshd_config, in particular the Subsystem lines.

If the sftp subsystem is pointing to a file (typically /opt/ssh/libexec/sftp-server), run "ldd /opt/ssh/libexec/sftp-server" to see a list of libraries required by the sftp-server. Make sure the sftp-server binary and all these required libraries are accessible within the chroot. Those libraries themselves may depend on other libraries: check them the same way.

If your (very old) SSH version supports an in-process sftp server, you can change the Subsystem line in sshd_config to:

Subsystem sftp internal-sftp

 This makes building the chroot environment much easier. Unfortunately, I have some doubt whether your old SSH version supports that setting or not. (If it is supported, it should be mentioned in the sshd_config man page.)

[Richard Pereira_1]

Correct. my version is too old to use that sftp internal directive.

SOLVED IT!

I was missing a library for sftp-server to run properly in the chrooted directory. I had previously ran a ldd on /chroot/opt/ssh/libexec/sftp-server but didn't notice that 1 lib was a in fact a link that pointed to another link that pointed to a library file.

To confirm, I changed the chrooted user shell to /sbin/sh. Did a ssh into the chrooted environment, a cd into /opt/ssh/libexec and tried to manually start sftp-server and got a missing library error.

specifically I was missing " /usr/lib/libgssapi_krb5.sl -> ./gss/libgssapi_krb5.sl " so I copied it under /chroot/usr/lib/gss/libgssapi_krb5.sl, changed the users shell back to the sftponly script and now i get a sftp prompt!

Im still confused how it dissapeared from a working chroot but it seems the /opt/ssh/ssh_chroot_setup.sh is out of date since it omits this lib and didnt copy it in my test chroot directory either.