Always "Disconnected" after Login submit, never spawns ssh

[GoogleCodeExporter]

What steps will reproduce the problem?
1. Install on CentOS 5.2, OpenSSH_4.3p2, OpenSSL 0.9.8b 04 May 2006
2. yum install pyOpenSSL -> OK
3. ./webshell.py &
4. Browse to https://MYIP:8022/
5. Login: [ANY USERNAME]

What is the expected output? What do you see instead?
Expecting a terminal session to start via SSH. Instead, the response is
always "Disconnected". 

What version of the product are you using? On what operating system?

WebShell-0.9.6
Installed on CentOS 5.2, OpenSSH_4.3p2, OpenSSL 0.9.8b 04 May 2006

Please provide any additional information below.

Scanning through the source code in webshell.py, I found f.proc_spawn()
with code needed to produce the resulting exec:

ssh \
-oPreferredAuthentications=keyboard-interactive,password \
-oNoHostAuthenticationForLocalhost=yes \
-oLogLevel=FATAL \
-F/dev/null \
-l [ANY USERNAME] localhost

If it run this ssh command from the shell on the server, ssh returns
immediately and silently and never begins a session. For some reason, the
above ssh command only works if I add the parameter -p 22 to force the
localhost SSH connection port to 22. On this host I have per-user
~username/.ssh/config files that set a non-default port for initiating ssh
connections, however the -F/dev/null seems like it should force ssh to
ignore that, but it's not working. As far as I can tell that's the only
thing about this environment that is non-standard.

Even if I add the '-p 22' to the webshell.py cmd as so:

cmd += ' -F/dev/null -p 22 -l' + login +' localhost'

The webshell does not seem to spawn the ssh process and still returns
"Disconnected".

Original issue reported on code.google.com by keenske...@gmail.com on 8 Jan 2010 at 3:16

[GoogleCodeExporter]

I am also having same problem.. Let me know the solution of this issue.. 

Original comment by selvaraj...@gmail.com on 2 Mar 2010 at 9:50

[GoogleCodeExporter]

For what it's worth, I encountered the same problem.  I remembered shortly 
later that
I had password authentication disabled on the machine I tested.  I moved the 
test to
another machine, and it worked fine.

I have no idea if this is what the others have encountered, but it might be 
worth
checking.

Original comment by rtbent...@gmail.com on 3 Mar 2010 at 10:17