- Community Home
- >
- Servers and Operating Systems
- >
- Operating Systems
- >
- Operating System - HP-UX
- >
- SOLVED! problems with chroot sftp user
Categories
Company
Local Language
Forums
Discussions
Forums
- Data Protection and Retention
- Entry Storage Systems
- Legacy
- Midrange and Enterprise Storage
- Storage Networking
- HPE Nimble Storage
Discussions
Discussions
Discussions
Forums
Discussions
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
- BladeSystem Infrastructure and Application Solutions
- Appliance Servers
- Alpha Servers
- BackOffice Products
- Internet Products
- HPE 9000 and HPE e3000 Servers
- Networking
- Netservers
- Secure OS Software for Linux
- Server Management (Insight Manager 7)
- Windows Server 2003
- Operating System - Tru64 Unix
- ProLiant Deployment and Provisioning
- Linux-Based Community / Regional
- Microsoft System Center Integration
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Community
Resources
Forums
Blogs
- Subscribe to RSS Feed
- Mark Topic as New
- Mark Topic as Read
- Float this Topic for Current User
- Bookmark
- Subscribe
- Printer Friendly Page
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
03-06-2012 10:23 AM - edited 03-15-2012 07:58 AM
03-06-2012 10:23 AM - edited 03-15-2012 07:58 AM
SOLVED! problems with chroot sftp user
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
- Tags:
- chroot
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
03-06-2012 01:16 PM
03-06-2012 01:16 PM
Re: problems with chroot sftp user
>also made sure /etc/passwd and /etc/group were copied into /newroot/etc
I thought you need to copy more than those files?
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
03-06-2012 02:24 PM
03-06-2012 02:24 PM
Re: problems with chroot sftp user
It does but what else should I check for?
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
03-06-2012 02:49 PM
03-06-2012 02:49 PM
Re: problems with chroot sftp user
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
03-07-2012 06:10 AM
03-07-2012 06:10 AM
Re: problems with chroot sftp user
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.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
03-07-2012 07:49 AM
03-07-2012 07:49 AM
Re: problems with chroot sftp user
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.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
03-08-2012 05:08 AM
03-08-2012 05:08 AM
Re: problems with chroot sftp user
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.)
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
03-15-2012 07:57 AM
03-15-2012 07:57 AM
SOLVED! Re: problems with chroot sftp user
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.