Howto create chrooted Openssh SFTP without shell access through rssh.

[jchau]

*** glibc detected *** -rssh: malloc(): memory corruption: 0x0804fc78 ***

hmmm, I've seen the "Connection closed" before & it can be caused by a variety of problems: wrong file permissions, missing libraries in the chroot directory, using a disallowed protocol, or just about anything that might cause rssh to quit.

However, I never seen the memory corruption error from. The logical next step would be to run memcheck to see if it's the physical memory's fault. However, I'm not sure if the error should persist if it was bad memory.

The next step should be to check to see if all the libraries needed are available, in the correct location, and up-to date in the chroot directory. To double check, you can use ldd on the binaries. For example,

jimmy@Jimmy-Laptop:~$ ldd `which scp`
        linux-gate.so.1 =>  (0xffffe000)
        libresolv.so.2 => /lib/tls/i686/cmov/libresolv.so.2 (0xb7f03000)
        libcrypto.so.0.9.8 => /usr/lib/i686/cmov/libcrypto.so.0.9.8 (0xb7dc9000)
        libutil.so.1 => /lib/tls/i686/cmov/libutil.so.1 (0xb7dc4000)
        libz.so.1 => /usr/lib/libz.so.1 (0xb7db0000)
        libnsl.so.1 => /lib/tls/i686/cmov/libnsl.so.1 (0xb7d9a000)
        libcrypt.so.1 => /lib/tls/i686/cmov/libcrypt.so.1 (0xb7d6c000)
        libselinux.so.1 => /lib/libselinux.so.1 (0xb7d58000)
        libgssapi_krb5.so.2 => /usr/lib/libgssapi_krb5.so.2 (0xb7d3c000)
        libkrb5.so.3 => /usr/lib/libkrb5.so.3 (0xb7cbf000)
        libk5crypto.so.3 => /usr/lib/libk5crypto.so.3 (0xb7c9a000)
        libkrb5support.so.0 => /usr/lib/libkrb5support.so.0 (0xb7c95000)
        libcom_err.so.2 => /lib/libcom_err.so.2 (0xb7c92000)
        libc.so.6 => /lib/tls/i686/cmov/libc.so.6 (0xb7b5e000)
        libdl.so.2 => /lib/tls/i686/cmov/libdl.so.2 (0xb7b5a000)
        libsepol.so.1 => /lib/libsepol.so.1 (0xb7b1c000)
        /lib/ld-linux.so.2 (0xb7f2b000)

Notice that "linux-gate.so.1" does not have a corresponding file location. You can safely ignore this library (it should be readily available from memory). However, also notice that "/lib/ld-linux.so.2" doesn't follow the format that the others do. Because the format in which this library is presented is different, the mkchroot.sh script will not copy this one; you will need to copy this one manually.

When checking the libraries, pay special attention to the ones mentioned in the error. To play it safe, you can just copy all of them over again.

If that doesn't work, we can do some more pondering later. Strange thing about the memory error though is that it appears after rssh tells you that your account is restricted; it normally exits immediately after that. This makes me think that your problem is also caused by something else.

[aprita]

Thanks a lot for your quick reply. As you suggested I did a memcheck but nothing showed up. I saw through googling that there are a few memchecks out there. Anyone particular you had in mind? I simply used the memtest+86 which is provided in the GRUB boot manager.

I also went through the libraries and hand copied all of them as you suggested. Same result ...

Here my output for the ldd check:

user@goofy:/home/office/lib$ ldd `which sftp`
        linux-gate.so.1 =>  (0xffffe000)
        libresolv.so.2 => /lib/tls/i686/cmov/libresolv.so.2 (0xb7ef8000)
        libcrypto.so.0.9.8 => /usr/lib/i686/cmov/libcrypto.so.0.9.8 (0xb7dbe000)
        libutil.so.1 => /lib/tls/i686/cmov/libutil.so.1 (0xb7db9000)
        libz.so.1 => /usr/lib/libz.so.1 (0xb7da5000)
        libnsl.so.1 => /lib/tls/i686/cmov/libnsl.so.1 (0xb7d8f000)
        libcrypt.so.1 => /lib/tls/i686/cmov/libcrypt.so.1 (0xb7d61000)
        libselinux.so.1 => /lib/libselinux.so.1 (0xb7d4d000)
        libgssapi_krb5.so.2 => /usr/lib/libgssapi_krb5.so.2 (0xb7d31000)
        libkrb5.so.3 => /usr/lib/libkrb5.so.3 (0xb7cb4000)
        libk5crypto.so.3 => /usr/lib/libk5crypto.so.3 (0xb7c8f000)
        libkrb5support.so.0 => /usr/lib/libkrb5support.so.0 (0xb7c8a000)
        libcom_err.so.2 => /lib/libcom_err.so.2 (0xb7c87000)
        libedit.so.2 => /usr/lib/libedit.so.2 (0xb7c6b000)
        libncurses.so.5 => /lib/libncurses.so.5 (0xb7c2b000)
        libc.so.6 => /lib/tls/i686/cmov/libc.so.6 (0xb7af6000)
        libdl.so.2 => /lib/tls/i686/cmov/libdl.so.2 (0xb7af2000)
        libsepol.so.1 => /lib/libsepol.so.1 (0xb7ab5000)
        /lib/ld-linux.so.2 (0xb7f1f000)
user@goofy:/home/office/lib$ ldd `which scp`
        linux-gate.so.1 =>  (0xffffe000)
        libresolv.so.2 => /lib/tls/i686/cmov/libresolv.so.2 (0xb7f8a000)
        libcrypto.so.0.9.8 => /usr/lib/i686/cmov/libcrypto.so.0.9.8 (0xb7e50000)
        libutil.so.1 => /lib/tls/i686/cmov/libutil.so.1 (0xb7e4b000)
        libz.so.1 => /usr/lib/libz.so.1 (0xb7e37000)
        libnsl.so.1 => /lib/tls/i686/cmov/libnsl.so.1 (0xb7e21000)
        libcrypt.so.1 => /lib/tls/i686/cmov/libcrypt.so.1 (0xb7df3000)
        libselinux.so.1 => /lib/libselinux.so.1 (0xb7ddf000)
        libgssapi_krb5.so.2 => /usr/lib/libgssapi_krb5.so.2 (0xb7dc3000)
        libkrb5.so.3 => /usr/lib/libkrb5.so.3 (0xb7d46000)
        libk5crypto.so.3 => /usr/lib/libk5crypto.so.3 (0xb7d21000)
        libkrb5support.so.0 => /usr/lib/libkrb5support.so.0 (0xb7d1c000)
        libcom_err.so.2 => /lib/libcom_err.so.2 (0xb7d19000)
        libc.so.6 => /lib/tls/i686/cmov/libc.so.6 (0xb7be5000)
        libdl.so.2 => /lib/tls/i686/cmov/libdl.so.2 (0xb7be1000)
        libsepol.so.1 => /lib/libsepol.so.1 (0xb7ba3000)
        /lib/ld-linux.so.2 (0xb7fb1000)

I then even copied the entire /lib/ folder to the chroot /lib/ folder as was suggested in a different post. Same result ... After that I commented out the chroot option in the rssh.conf file and everything worked fine again without the chroot jail.

I don't know if this is relevant, but when I compare the output from the log file with other users on the web they have some statements after

rssh[6291]: chroot cmd line: /usr/lib/rssh/rssh_chroot_helper 2 "/usr/lib/openssh/sftp-server"

or a slightly different argument for the rss_chroot_helper. Could these problems come from the rss_chroot_helper?

Is there any other kind of log files or such that would be able to provide some more insight into this problem? (I'm still kinda new to linux and don't really know it inside and out yet)
Once again, thanks a bunch for your help.

[jchau]

Thanks a lot for your quick reply. As you suggested I did a memcheck but nothing showed up. I saw through googling that there are a few memchecks out there. Anyone particular you had in mind? I simply used the memtest+86 which is provided in the GRUB boot manager.

I then even copied the entire /lib/ folder to the chroot /lib/ folder as was suggested in a different post. Same result ... After that I commented out the chroot option in the rssh.conf file and everything worked fine again without the chroot jail.

I don't know if this is relevant, but when I compare the output from the log file with other users on the web they have some statements after

rssh[6291]: chroot cmd line: /usr/lib/rssh/rssh_chroot_helper 2 "/usr/lib/openssh/sftp-server"

or a slightly different argument for the rss_chroot_helper. Could these problems come from the rss_chroot_helper?

Is there any other kind of log files or such that would be able to provide some more insight into this problem? (I'm still kinda new to linux and don't really know it inside and out yet)
Once again, thanks a bunch for your help.

memtest is fine; that was the one I was thinking of anyway.

about rssh_chroot_helper. make sure the one in the real root is suid root (needs to run as root). also make sure that there is a usr/lib/openssh/sftp-server in your chroot directory. some people have noexec set on their home partition; if /home is a different partition, make sure this isn't the case. make sure the user you are using has access to and own their home folder; their home folder should be in the chroot directory.

you can add a few -v options to get some more verbosity when using sftp to try to pin-point the problem.

as for the command logged, I don't see anything particular about it; what did you notice?


BTW, this week is the last week of classes for me and my professors decided to play catch-up with the syllabus by assigning loads of work, so I probably won't respond again until next week.

[aprita]

so, out of some kind of magic I am now not getting the memory error anymore when attempting to log in using ssh. It now nicely rejects me and closes the connection. Honestly cannot say what I did that would have caused it. Didn't restart the machine or anything. Just hoping it'll still like this now ...

The problem with not being able to log in using sftp still pertains and probably due to chroot. I checked and rssh_chroot_helper does indeed have suid root. Further the home directory is on the same partition and the user has ownership and access to it. Also there is a sftp-server in the chroot directory with execution permission from owner (root) through world. I added two -v's to my sftp login attempts and this is was I got (I wasn't able to extract anything useful, but maybe you can):

siddha@goofy:~$ sftp -v -v -oPort=2255 office@localhost
Connecting to localhost...
OpenSSH_4.3p2 Debian-5ubuntu1, OpenSSL 0.9.8b 04 May 2006
debug1: Reading configuration data /etc/ssh/ssh_config
debug1: Applying options for *
debug2: ssh_connect: needpriv 0
debug1: Connecting to localhost [127.0.0.1] port 2255.
debug1: Connection established.
debug1: identity file /home/siddha/.ssh/id_rsa type -1
debug1: identity file /home/siddha/.ssh/id_dsa type -1
debug1: Remote protocol version 2.0, remote software version OpenSSH_4.3p2 Debian-5ubuntu1
debug1: match: OpenSSH_4.3p2 Debian-5ubuntu1 pat OpenSSH*
debug1: Enabling compatibility mode for protocol 2.0
debug1: Local version string SSH-2.0-OpenSSH_4.3p2 Debian-5ubuntu1
debug2: fd 3 setting O_NONBLOCK
debug1: SSH2_MSG_KEXINIT sent
debug1: SSH2_MSG_KEXINIT received
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,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-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
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: 132/256
debug2: bits set: 528/1024
debug1: SSH2_MSG_KEX_DH_GEX_INIT sent
debug1: expecting SSH2_MSG_KEX_DH_GEX_REPLY
debug1: Host 'localhost' is known and matches the RSA host key.
debug1: Found key in /home/siddha/.ssh/known_hosts:1
debug2: bits set: 519/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: /home/siddha/.ssh/id_rsa ((nil))
debug2: key: /home/siddha/.ssh/id_dsa ((nil))
debug1: Authentications that can continue: publickey,keyboard-interactive
debug1: Next authentication method: publickey
debug1: Trying private key: /home/siddha/.ssh/id_rsa
debug1: Trying private key: /home/siddha/.ssh/id_dsa
debug2: we did not send a packet, disable method
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:
debug2: input_userauth_info_req
debug2: input_userauth_info_req: num_prompts 0
debug1: Authentication succeeded (keyboard-interactive).
debug2: fd 4 setting O_NONBLOCK
debug1: channel 0: new [client-session]
debug2: channel 0: send open
debug1: Entering interactive session.
debug2: callback start
debug2: client_session2_setup: id 0
debug1: Sending environment.
debug1: Sending env LANG = en_US.UTF-8
debug2: channel 0: request env confirm 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 131072
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
debug1: client_input_channel_req: channel 0 rtype exit-status reply 0
debug2: channel 0: rcvd close
debug2: channel 0: close_read
debug2: channel 0: input open -> closed
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
debug1: fd 0 clearing 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
Connection closed

I don't know if this matters but I set my sftp server to a non-standard port (2255).

Further, as for the command logging. My log files end with outputs from the rssh executable, but do not receive any outputs from rssh_chroot_helper like juicybananahead or OnlyJedi got in their previous posts in this thread. My log file ends with the line:

rssh[6291]: chroot cmd line: /usr/lib/rssh/rssh_chroot_helper 2 "/usr/lib/openssh/sftp-server"

no comments such as (tooken from OnlyJedi):

May 13 12:38:33 localhost rssh_chroot_helper[22813]: new session for sft, UID=10000
May 13 12:38:33 localhost rssh_chroot_helper[22813]: user's home dir is /media/files/pub/home/sft
May 13 12:38:33 localhost rssh_chroot_helper[22813]: chrooted to /media/files/pub
May 13 12:38:33 localhost rssh_chroot_helper[22813]: changing working directory to /home/sft (inside jail)

Does this mean that possibly rssh_chroot_helper is never called? or is it possibly not logging it?

Hope your profs didn't load you too badly. I myself am also enjoying the fun week before finals rush on projects and studying as well. Good luck with all your stuff!

[aprita]

never mind ... after rebooting my machine and trying to logging in through shh I get the same crash again.

[edylie]

I am running ubuntu 6.10 and for those getting the connection closed message, make sure you have null in your /home/chroot/dev directory

if it does not exist, excute the following command

sudo mknod -m 666 /home/chroot/dev/null c 1 3

cheers,
Edy

[aprita]

wow, now that's what I called problem solved (for me at least) . Thanks so much for your help edy and jchau! How did you figure that out edy?

The null dev fixed my sftp login problems, as for my memory crash.... What I have noticed is that when I leave my machine on for a while (say over night after a fresh reboot) the crash can't be reproduced the next morning and it appears to work the way it should. Have no idea how to find out why and what is causing it but figure it's only marginally related to this program but more so to the underlying OS. If anyone has any ideas on what could be causing this they would be greatly appreciated.

Thanks a again for all your help guys,
aprita

[jchau]

Thanks edylie. I forgot about that; the Gentoo guide mentioned it too. I added it to the original Howto post.

[aprita]

In case anyone would be interested in using rssh and rsync (wrapped using ssh) along with a chroot jail and you successfully followed through the howto kindly provided by jchau but ran into a problem like the following when using rsync :

rsync: connection unexpectedly closed (0 bytes received so far) [sender]
rsync error: error in rsync protocol data stream (code 12) at io.c(434)

try copying:
/usr/bin/rsync into the jail (e.g. /home/jail/usr/bin/rsync) and
/lib/libpopt.so.0 into the jail as well (e.g. /home/jail/lib/libpopt.so.0)

Helped me and hope it'll help you as well.
Cheers,
aprita

[neo4242002]

Hi genius… First of all thanks you very much for this wonderful Howto. Something I been searching for long time.

I am kind of a newbee to this type of work. But I enjoy them learning. So I need some help from experts. I am using Ubuntu 6.10 Server (Edgy Eft) and I have followed all setups without missing anything. But I am still unable to work SFTP in my server.

CAN SOMEONE HELP ME PLEASE

I had couple of problems during the installation and everything passed her for you guys reference.

rssh -v

rssh 2.3.2
Copyright 2002-5 Derek D. Martin <rssh-discuss at lists dot sourceforge dot net>

    rssh config file = /etc/rssh.conf
  chroot helper path = /usr/lib/rssh/rssh_chroot_helper
     scp binary path = /usr/bin/scp
  sftp server binary = /usr/lib/openssh/sftp-server
     cvs binary path = /usr/bin/cvs
   rdist binary path = /usr/bin/rdist
   rsync binary path = /usr/bin/rsync

nano ~/mkchroot.sh

scp_path="/usr/bin/scp"
sftp_server_path="/usr/lib/openssh/sftp-server"
rssh_path="/usr/bin/rssh"
chroot_helper_path="/usr/lib/rssh/rssh_chroot_helper" 

:~# ./mkchroot.sh /home/chroot
-e NOT changing owner of root jail.
-e NOT changing perms of root jail.
setting up /home/chroot/usr/bin
setting up /home/chroot/usr/lib/openssh
setting up /home/chroot/usr/lib/rssh
Copying libraries for /usr/bin/scp.
-e      (0xffffe000)
cp: cannot stat `(0xffffe000)': No such file or directory
-e      /lib/tls/i686/cmov/libresolv.so.2
-e      /usr/lib/i686/cmov/libcrypto.so.0.9.8
-e      /lib/tls/i686/cmov/libutil.so.1
-e      /usr/lib/libz.so.1
-e      /lib/tls/i686/cmov/libnsl.so.1
-e      /lib/tls/i686/cmov/libcrypt.so.1
-e      /lib/libselinux.so.1
-e      /usr/lib/libgssapi_krb5.so.2
-e      /usr/lib/libkrb5.so.3
-e      /usr/lib/libk5crypto.so.3
-e      /usr/lib/libkrb5support.so.0
-e      /lib/libcom_err.so.2
-e      /lib/tls/i686/cmov/libc.so.6
-e      /lib/tls/i686/cmov/libdl.so.2
-e      /lib/libsepol.so.1
Copying libraries for /usr/lib/openssh/sftp-server.
-e      (0xffffe000)
cp: cannot stat `(0xffffe000)': No such file or directory
-e      /lib/tls/i686/cmov/libresolv.so.2
-e      /usr/lib/i686/cmov/libcrypto.so.0.9.8
-e      /lib/tls/i686/cmov/libutil.so.1
-e      /usr/lib/libz.so.1
-e      /lib/tls/i686/cmov/libnsl.so.1
-e      /lib/tls/i686/cmov/libcrypt.so.1
-e      /lib/libselinux.so.1
-e      /usr/lib/libgssapi_krb5.so.2
-e      /usr/lib/libkrb5.so.3
-e      /usr/lib/libk5crypto.so.3
-e      /usr/lib/libkrb5support.so.0
-e      /lib/libcom_err.so.2
-e      /lib/tls/i686/cmov/libc.so.6
-e      /lib/tls/i686/cmov/libdl.so.2
-e      /lib/libsepol.so.1
Copying libraries for /usr/bin/rssh.
-e      (0xffffe000)
cp: cannot stat `(0xffffe000)': No such file or directory
-e      /lib/tls/i686/cmov/libc.so.6
Copying libraries for /usr/lib/rssh/rssh_chroot_helper.
-e      (0xffffe000)
cp: cannot stat `(0xffffe000)': No such file or directory
-e      /lib/tls/i686/cmov/libc.so.6
copying name service resolution libraries...
tar: Removing leading `/' from member names
        lib/libnss_compat-2.4.so
        lib/libnss_compat.so.2
        lib/libnss_files-2.4.so
        lib/libnss_files.so.2
Setting up /etc in the chroot jail
cp: omitting directory `/etc/ld.so.conf.d'
-e Chroot jail configuration completed.
-e
NOTE: if you are not using the passwd file for authentication,
-e you may need to copy some of the /lib/libnss_* files into the jail.

-e NOTE: you must MANUALLY edit your syslog rc script to start syslogd
-e with appropriate options to log to /home/chroot/dev/log.  In most cases,
-e you will need to start syslog as:

-e    /sbin/syslogd -a /home/chroot/dev/log

-e NOTE: we make no guarantee that ANY of this will work for you... -e if it
doesn't, you're on your own.  Sorry!

root@buzz:/home# ls -l
total 16
drwxr-xr-x 7 root     root     4096 2007-02-06 18:27 chroot
drwxr-xr-x 2 root     root     4096 2007-02-06 17:46 chroot.
drwxr-xr-x 2 ftp      nogroup  4096 2007-02-06 15:37 ftp

/home# ldd /usr/bin/scp | grep "ld-linux.so.2"
        /lib/ld-linux.so.2 (0xb7fde000)

/home/chroot# ls -al /home/chroot/lib
total 476
drwxr-xr-x 3 root root   4096 2007-02-06 19:36 .
drwxr-xr-x 7 root root   4096 2007-02-06 18:27 ..
-rwxr-xr-x 1 root root 105112 2007-02-06 19:39 ld-linux.so.2
-rw-r--r-- 1 root root   5560 2007-02-06 19:36 libcom_err.so.2
-rw-r--r-- 1 root root  26332 2007-01-24 22:19 libnss_compat-2.4.so
lrwxrwxrwx 1 root root     20 2007-02-06 19:36 libnss_compat.so.2 -> libnss_compat-2.4.so
-rw-r--r-- 1 root root  34276 2007-01-24 22:19 libnss_files-2.4.so
lrwxrwxrwx 1 root root     19 2007-02-06 19:36 libnss_files.so.2 -> libnss_files-2.4.so
-rw-r--r-- 1 root root  75228 2007-02-06 19:36 libselinux.so.1
-rw-r--r-- 1 root root 203552 2007-02-06 19:36 libsepol.so.1
drwxr-xr-x 3 root root   4096 2007-02-06 17:46 tls

/home/chroot# cp /lib/libnss_compact.so.2 /home/chroot/lib/
cp: cannot stat `/lib/libnss_compact.so.2': No such file or directory

useradd -d /home/chroot/home/sft -s /usr/bin/rssh sft

/home/chroot# cat /etc/ssh/sshd_config | grep "Subsystem sftp "
#Subsystem sftp /usr/lib/openssh/sftp-server
Subsystem sftp /usr/lib/sftp-server

/home/chroot# ln -s /usr/lib/openssh/sftp-server /usr/lib/
ln: creating symbolic link `/usr/lib/sftp-server' to `/usr/lib/openssh/sftp-server': File exists

# Allow client to pass locale environment variables
AcceptEnv LANG LC_*

#Subsystem sftp /usr/lib/openssh/sftp-server
Subsystem sftp /usr/lib/sftp-server

:/home/chroot# ln /home/chroot/usr/lib/openssh/sftp-server /home/chroot/usr/lib/
ln: creating hard link `/home/chroot/usr/lib/sftp-server' to `/home/chroot/usr/lib/openssh/sftp-server': File exists

I just worry about that "File Exists", other than that everything made exactly on this Howto. I have also noticed my file making following error when i try to FTP. Also my Putty get close automatically just after type my password. Any ideas guys?

Status:	Connecting to 192.168.101.8:22 ...
Status:	Connected with 192.168.101.8:22, initializing SFTP connection...
Command:	CONNECT sft@192.168.101.8:22
Response:	Fatal: unable to initialise SFTP: could not connect
Error:	Unable to connect!
Status:	Waiting to retry... (5 retries left)