# HOWTO: chroot SFTP (only) -- not working

## thoughtform

For the past few days I have been experimenting with various methods of secure file transfe, jail, jailkit, etc.

I finally settled on sftp and chose what I thought to be the simplest option after reading up on a Gentoo-wiki about this:

http://www.minstrel.org.uk/papers/sftp/

I followed the instructions to the letter but I'm stuck with these results:

from the client side:

root@ipcop:~ # sftp traumahound@10.74.78.113

Connecting to 10.74.78.113...

Password:

Received message too long 1936094320

from the server logs:

Dec 26 22:18:34 [sshd] Connection from 10.74.78.1 port 32988

Dec 26 22:18:34 [sshd] Failed none for traumahound from 10.74.78.1 port 32988 ssh2

Dec 26 22:18:38 [sshd] Accepted keyboard-interactive/pam for traumahound from 10.74.78.1 port 32988 ssh2

Dec 26 22:18:38 [sshd] pam_unix(sshd:session): session opened for user traumahound by (uid=0)

Dec 26 22:18:38 [sshd] subsystem request for sftp

Dec 26 22:18:38 [sshd] Connection closed by 10.74.78.1

Dec 26 22:18:38 [sshd] pam_unix(sshd:session): session closed for user traumahound

Dec 26 22:18:38 [sshd] Closing connection to 10.74.78.1

need some help here.

thanks

----------

## TheMinstrel

This is one of the most common problems with the solution - there are a few things you can check:

1. Did you follow the 'chmod +s /path/to/sftp-server' instruction?

2. Did you set the chroot'd home directory to be owned by the user?

3. Make sure you have the right path to sftp-server in your sshd_config...

I hope one of these solves the problem for you!

-- 

Minstrel

----------

## thoughtform

 *TheMinstrel wrote:*   

> This is one of the most common problems with the solution - there are a few things you can check:
> 
> 1. Did you follow the 'chmod +s /path/to/sftp-server' instruction?
> 
> 2. Did you set the chroot'd home directory to be owned by the user?
> ...

 

hey thanks for your reply!

1. 

drwxr-xr-x  2 root root   4096 Dec 26 21:00 .

drwxr-xr-x 10 root root   4096 Dec 26 21:00 ..

-rwsr-sr-x  1 root root  43500 Dec 26 21:00 sftp-server

-rws--x--x  1 root root 156572 Dec 26 21:00 ssh-keysign

patrick libexec # pwd

/usr/local/libexec

2. 

patrick home # ls -la traumahound/

total 24

drwx--x--x  3 traumahound users 4096 Dec 26 22:12 .

drwxr-xr-x 13 root        root  4096 Dec 26 22:12 ..

-rw-r--r--  1 traumahound users  127 Dec 26 22:12 .bash_logout

-rw-r--r--  1 traumahound users  193 Dec 26 22:12 .bash_profile

-rw-r--r--  1 traumahound users  551 Dec 26 22:12 .bashrc

drwx------  2 traumahound users 4096 Dec 26 22:12 .ssh

3.

This was not correct, I had overlooked it.

I corrected my sshd_config to read:

# override default of no subsystems

Subsystem       sftp    /usr/local/libexec/sftp-server

UsePrivilegeSeparation yes

X11Forwarding no

IgnoreRhosts yes

IgnoreUserKnownHosts no

PrintMotd yes

StrictModes yes

RSAAuthentication yes

PermitRootLogin no

PermitEmptyPasswords no

AllowUsers patrick traumahound

LogLevel VERBOSE

GatewayPorts no

AllowTcpForwarding yes

KeepAlive yes

I restarted sshd and tried again, I still get the same error message.

----------

## TheMinstrel

Well, that should have solved the problem (the change to sftp-server path), and I was going to suggest you restart the SSH daemon, but I see you already did.  One further possibility:

 *Scorpaen wrote:*   

> 
> 
> 2. 
> 
> patrick home # ls -la traumahound/
> ...

 

Try removing the '.ssh' directory in the user's area (actually, you can remove all of these files) - it may be there's a configuration conflict going on (although this shouldn't be the case).  Certainly chroot'd SFTP users don't need any profile information, so the files are redundant in any case.

-- 

Minstrel

----------

## thoughtform

patrick traumahound # ls -la

total 8

drwx--x--x  2 traumahound users 4096 Dec 28 14:52 .

drwxr-xr-x 13 root        root  4096 Dec 26 22:12 ..

removed those files, restarted sshd, still same error.

puzzling!

----------

## TheMinstrel

 *Scorpaen wrote:*   

> patrick traumahound # ls -la
> 
> total 8
> 
> drwx--x--x  2 traumahound users 4096 Dec 28 14:52 .
> ...

 

Hmm...

The 'Message too long' error you're receiving is because the first characters received by the SSH client are 'sftp' instead of a proper SSH handshake.  This is likely to be the beginning of an error message, such as 'sftp-server could not start' or something along those lines.  Double-check you only have one instance of sftp-server, one sshd_config, one installation of SSH, etc. and so there's no conflict...  Did you remove the packaged version of OpenSSH before starting the process?

--

Minstrel

----------

## thoughtform

ok that was stupid of me. i'd stopped the gentoo ebuild sshd but not uninstalled it.

so...

i uninstalled my system version of openssh.

just to be SURE i rebooted the computer.

i went to the portable openssh source dir and did the 

./configure make make install

checked out the config file for sshd, it has the correct path for sftp-server

chmod +s /usr/local/libexec/sftp-server

then i launched it with /usr/local/sbin/sshd

i still get the same error from the client.

so.... i enabled -vvvv on the client hoping it would tell me something.

not much really but here it is anyway:

root@ipcop:~ # sftp -vvvvvvvvvvvvv traumahound@10.74.78.113

Connecting to 10.74.78.113...

OpenSSH_4.5p1, OpenSSL 0.9.7m 23 Feb 2007

debug1: Reading configuration data /etc/ssh/ssh_config

debug2: ssh_connect: needpriv 0

debug1: Connecting to 10.74.78.113 [10.74.78.113] port 22.

debug1: Connection established.

debug1: permanently_set_uid: 0/0

debug1: identity file /root/.ssh/id_rsa type -1

debug1: identity file /root/.ssh/id_dsa type -1

debug1: Remote protocol version 2.0, remote software version OpenSSH_4.7

debug1: match: OpenSSH_4.7 pat OpenSSH*

debug1: Enabling compatibility mode for protocol 2.0

debug1: Local version string SSH-2.0-OpenSSH_4.5

debug2: fd 3 setting O_NONBLOCK

debug1: SSH2_MSG_KEXINIT sent

debug1: SSH2_MSG_KEXINIT received

debug2: kex_parse_kexinit: diffie-hellman-group-exchange-sha256,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,arcfour128,arcfour256,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,arcfour128,arcfour256,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@openssh.com,zlib

debug2: kex_parse_kexinit: none,zlib@openssh.com,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-sha256,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,arcfour128,arcfour256,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,arcfour128,arcfour256,arcfour,aes192-cbc,aes256-cbc,rijndael-cbc@lysator.liu.se,aes128-ctr,aes192-ctr,aes256-ctr

debug2: kex_parse_kexinit: hmac-md5,hmac-sha1,umac-64@openssh.com,hmac-ripemd160,hmac-ripemd160@openssh.com,hmac-sha1-96,hmac-md5-96

debug2: kex_parse_kexinit: hmac-md5,hmac-sha1,umac-64@openssh.com,hmac-ripemd160,hmac-ripemd160@openssh.com,hmac-sha1-96,hmac-md5-96

debug2: kex_parse_kexinit: none,zlib@openssh.com

debug2: kex_parse_kexinit: none,zlib@openssh.com

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(1024<1024<8192) sent

debug1: expecting SSH2_MSG_KEX_DH_GEX_GROUP

debug2: dh_gen_key: priv key bits set: 135/256

debug2: bits set: 535/1024

debug1: SSH2_MSG_KEX_DH_GEX_INIT sent

debug1: expecting SSH2_MSG_KEX_DH_GEX_REPLY

debug3: check_host_in_hostfile: filename /root/.ssh/known_hosts

debug3: check_host_in_hostfile: match line 1

debug1: Host '10.74.78.113' is known and matches the RSA host key.

debug1: Found key in /root/.ssh/known_hosts:1

debug2: bits set: 525/1024

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: /root/.ssh/id_rsa ((nil))

debug2: key: /root/.ssh/id_dsa ((nil))

debug1: Authentications that can continue: publickey,password,keyboard-interactive

debug3: start over, passed a different list publickey,password,keyboard-interactive

debug3: preferred 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: /root/.ssh/id_rsa

debug3: no such identity: /root/.ssh/id_rsa

debug1: Trying private key: /root/.ssh/id_dsa

debug3: no such identity: /root/.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

traumahound@10.74.78.113's password:

debug3: packet_send2: adding 48 (len 67 padlen 13 extra_pad 64)

debug2: we sent a password packet, wait for reply

debug1: Authentication succeeded (password).

debug2: fd 4 setting O_NONBLOCK

debug3: fd 5 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: client_session2_setup: id 0

debug1: Sending subsystem: sftp

debug2: channel 0: request subsystem confirm 1

debug2: fd 3 setting TCP_NODELAY

debug2: callback done

debug2: channel 0: open confirm rwindow 0 rmax 32768

debug2: channel 0: rcvd adjust 2097152

debug1: client_input_channel_req: channel 0 rtype exit-status reply 0

Received message too long 1936094320

debug2: channel 0: read<=0 rfd 4 len -1

debug2: channel 0: read failed

debug2: channel 0: close_read

debug2: channel 0: input open -> drain

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: send eof

debug2: channel 0: input drain -> 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 6 c -1

debug1: fd 0 clearing O_NONBLOCK

root@ipcop:~ # debug3: fd 1 is not O_NONBLOCK

debug1: Transferred: stdin 0, stdout 0, stderr 0 bytes in 0.0 seconds

debug1: Bytes per second: stdin 0.0, stdout 0.0, stderr 0.0

debug1: Exit status 1

SSHD debug3

Dec 28 16:41:09 [sshd] Accepted password for traumahound from 10.74.78.1 port 33054 ssh2

Dec 28 16:41:09 [sshd] debug1: monitor_child_preauth: traumahound has been authenticated by privileged process

Dec 28 16:41:09 [sshd] debug3: mm_get_keystate: Waiting for new keys

Dec 28 16:41:09 [sshd] debug3: mm_request_receive_expect entering: type 24

Dec 28 16:41:09 [sshd] debug3: mm_request_receive entering

Dec 28 16:41:09 [sshd] debug3: mm_newkeys_from_blob: 0x80a4ef0(118)

Dec 28 16:41:09 [sshd] debug2: mac_setup: found hmac-md5

Dec 28 16:41:09 [sshd] debug3: mm_get_keystate: Waiting for second key

Dec 28 16:41:09 [sshd] debug3: mm_newkeys_from_blob: 0x80a4ef0(118)

Dec 28 16:41:09 [sshd] debug2: mac_setup: found hmac-md5

Dec 28 16:41:09 [sshd] debug3: mm_get_keystate: Getting compression state

Dec 28 16:41:09 [sshd] debug3: mm_get_keystate: Getting Network I/O buffers

Dec 28 16:41:09 [sshd] debug3: mm_share_sync: Share sync

Dec 28 16:41:09 [sshd] debug3: mm_share_sync: Share sync end

Dec 28 16:41:09 [sshd] debug1: permanently_set_uid: 1009/100

Dec 28 16:41:09 [sshd] debug2: set_newkeys: mode 0

Dec 28 16:41:09 [sshd] debug2: set_newkeys: mode 1

Dec 28 16:41:09 [sshd] debug1: Entering interactive session for SSH2.

Dec 28 16:41:09 [sshd] debug2: fd 5 setting O_NONBLOCK

Dec 28 16:41:09 [sshd] debug2: fd 6 setting O_NONBLOCK

Dec 28 16:41:09 [sshd] debug1: server_init_dispatch_20

Dec 28 16:41:09 [sshd] debug1: server_input_channel_open: ctype session rchan 0 win 131072 max 32768

Dec 28 16:41:09 [sshd] debug1: input_session_request

Dec 28 16:41:09 [sshd] debug1: channel 0: new [server-session]

Dec 28 16:41:09 [sshd] debug1: session_new: init

Dec 28 16:41:09 [sshd] debug1: session_new: session 0

Dec 28 16:41:09 [sshd] debug1: session_open: channel 0

Dec 28 16:41:09 [sshd] debug1: session_open: session 0: link with channel 0

Dec 28 16:41:09 [sshd] debug1: server_input_channel_open: confirm session

Dec 28 16:41:09 [sshd] debug2: User child is on pid 14970

Dec 28 16:41:09 [sshd] debug3: mm_request_receive entering

Dec 28 16:41:09 [sshd] debug1: server_input_channel_req: channel 0 request subsystem reply 1

Dec 28 16:41:09 [sshd] debug1: session_by_channel: session 0 channel 0

Dec 28 16:41:09 [sshd] debug1: session_input_channel_req: session 0 req subsystem

Dec 28 16:41:09 [sshd] subsystem request for sftp

Dec 28 16:41:09 [sshd] debug1: subsystem: exec() /usr/local/libexec/sftp-server

Dec 28 16:41:09 [sshd] debug3: channel 0: close_fds r -1 w -1 e -1 c -1

Dec 28 16:41:09 [sshd] debug2: fd 3 setting TCP_NODELAY

Dec 28 16:41:09 [sshd] debug2: fd 8 setting O_NONBLOCK

Dec 28 16:41:09 [sshd] debug3: fd 8 is O_NONBLOCK

Dec 28 16:41:09 [sshd] debug2: notify_done: reading

Dec 28 16:41:09 [sshd] debug1: Received SIGCHLD.

Dec 28 16:41:09 [sshd] debug1: session_by_pid: pid 14971

Dec 28 16:41:09 [sshd] debug1: session_exit_message: session 0 channel 0 pid 14971

Dec 28 16:41:09 [sshd] debug2: channel 0: request exit-status confirm 0

Dec 28 16:41:09 [sshd] debug1: session_exit_message: release channel 0

Dec 28 16:41:09 [sshd] debug2: channel 0: write failed

Dec 28 16:41:09 [sshd] debug2: channel 0: close_write

Dec 28 16:41:09 [sshd] debug2: channel 0: output open -> closed

Dec 28 16:41:09 [sshd] debug2: channel 0: read<=0 rfd 8 len 0

Dec 28 16:41:09 [sshd] debug2: channel 0: read failed

Dec 28 16:41:09 [sshd] debug2: channel 0: close_read

Dec 28 16:41:09 [sshd] debug2: channel 0: input open -> drain

Dec 28 16:41:09 [sshd] debug2: channel 0: ibuf empty

Dec 28 16:41:09 [sshd] debug2: channel 0: send eof

Dec 28 16:41:09 [sshd] debug2: channel 0: input drain -> closed

Dec 28 16:41:09 [sshd] debug2: channel 0: send close

Dec 28 16:41:09 [sshd] debug3: channel 0: will not send data after close

Dec 28 16:41:09 [sshd] debug2: channel 0: rcvd close

Dec 28 16:41:09 [sshd] debug3: channel 0: will not send data after close

Dec 28 16:41:09 [sshd] debug2: channel 0: is dead

Dec 28 16:41:09 [sshd] debug2: channel 0: gc: notify user

Dec 28 16:41:09 [sshd] debug1: session_by_channel: session 0 channel 0

Dec 28 16:41:09 [sshd] debug1: session_close_by_channel: channel 0 child 0

Dec 28 16:41:09 [sshd] debug1: session_close: session 0 pid 0

Dec 28 16:41:09 [sshd] debug2: channel 0: gc: user detached

Dec 28 16:41:09 [sshd] debug2: channel 0: is dead

Dec 28 16:41:09 [sshd] debug2: channel 0: garbage collecting

Dec 28 16:41:09 [sshd] debug1: channel 0: free: server-session, nchannels 1

Dec 28 16:41:09 [sshd] debug3: channel 0: status: The following connections are open:\r\n  #0 server-session (t4 r0 i3/0 o3/0 fd 8/8 cfd -1)\r\n

Dec 28 16:41:09 [sshd] debug3: channel 0: close_fds r 8 w 8 e -1 c -1

Dec 28 16:41:09 [sshd] Connection closed by 10.74.78.1

Dec 28 16:41:09 [sshd] debug1: do_cleanup

Dec 28 16:41:09 [sshd] Closing connection to 10.74.78.1

Dec 28 16:41:09 [sshd] debug3: mm_request_send entering: type 58

Dec 28 16:41:09 [sshd] debug3: monitor_read: checking request 58

Dec 28 16:41:09 [sshd] debug3: mm_answer_term: tearing down sessions

----------

## qubix

have you tried net-misc/scponly? They've even got a nice howto of making sftp/scp chroot-only.

----------

## TheMinstrel

 *Scorpaen wrote:*   

> ok that was stupid of me. i'd stopped the gentoo ebuild sshd but not uninstalled it.
> 
> so...
> 
> i uninstalled my system version of openssh.
> ...

 

You definitely used the modified sftp-server.c from my site?  This one's got me baffled...

--

Minstrel

----------

## thoughtform

yes i did use the modified version.

i've had to give up on it for now but thanks for looking into it.

i may pick this back up at a later date.

Scorpaen

----------

