sftp subsystem request failed

subsystem request failed on channel 0
Couldn't read packet: Connection reset by peer

This happened when using sshd chrooting on Linux.

This was sorted after changing

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

to

Subsystem sftp internal-sftp

REFERENCE:
http://forums.debian.net/viewtopic.php?f=5&t=42818

Privilege separation of OpenSSH

sshd will run as root until the user authenticates, at which point the sshd child will be setuid(2) the authenticated user. For instance, on my home machine, see:

root       998  0.0  0.2  2700  832 ?        S    Aug08   0:03 /usr/local/sbin/sshd
root     16477  0.0  0.2  6152  848 ?        S    Aug09   0:00 sshd: azarin [priv]
azarin   16479  0.0  0.3  6168 1100 ?        S    Aug09   0:12 sshd: azarin () pts/15

In this case, the main sshd daemon, pid 998, is listening on 22/tcp.  I
logged in and the sshd all of my processes see in this session is under
pid 16479.

If you do not trust the portion of sshd running as root then here are some
things you are going to run into:

* sshd cannot bind to port 22/tcp or any other port 1024 or below.  Due to
limitations in kernels, only a user with uid 0 (i.e. 'root') can bind to a
port numbered 1024 or below.  To the best of my knowledge, apache and
BIND's named (if you use the -u flag) accomplish binding to a privileged
port by binding as the port then spawning a child that is setuid(2)'d to
the appropriate user.  sshd, however, does not do this.

* If you use shadowed passwords, then this will not work.  Period.
/etc/shadow on most systems is chmod 600 and owned by root.  (Any other
combination of ownership and permissions is broken.)  I do not know if
using PAM will remove this requirement, but I do not think so.  Also,
other password authentication mechanisms may also fail.

If you are set on running sshd as a non uid 0 user (i.e. not root), then
you will have to bind it to a port above 1024/tcp.  Also, since password
authentication may not work, the use of key-based authentication is your
best bet for gaining access.  Lastly, this sshd will *only* allow login by
the user running it.  It will not allow authentication for another user
since you cannot setuid(2) to that user.


Personally, I suggest using a version of OpenSSH that supports privilege
separation.  In a controlled environment, requiring key-based
authentication is a good idea.  However, if everyone who will SSH to this
machine is not very technically savvy and have a habit of accessing from
multiple computers, a requirement on key-based authentication may be too
much of a hassle.

REFERENCE: http://seclists.org/basics/2003/Aug/564

compiling OpenSSH

1. download source code from openssh.com.

2. zlib-dev and openssl-dev packages are prerequisites, for both Unix-like and Windows Cygwin.

3. ./configure --prefix to specify the installed dir. then make&make install.

4. create or modify the startup of sshd via rc-conf, upstart, or cygrunsrv on Windows.

ssh SendEnv LANG encoding problem

If there's problem to show characters correctly for non-English LANG, we can comment out the line of 'SendEnv LANG' in /etc/ssh/ssh_config, in order to use the server setup instead.