Post-Login automation does not work in conjunction with forced shellscript execution ("command=..." in authorized_keys)

[GoogleCodeExporter]

What steps will reproduce the problem?
1. On the server: In authorized_keys, force the execution of a shellscript as 
described here: 
http://binblog.info/2008/10/20/openssh-going-flexible-with-forced-commands/ 
2. Configure the host in Connectbot including the correct private key
3. In "Post-Login automation", enter some command that shall be "passed" to the 
shellscript

What is the expected output? What do you see instead?
I expect that the command I entered in "Post-Login automation" is passed to the 
shellscript.
But that doesn't happen, nothing is passed to the script.

What version of the product are you using (you can see this by using Menu-> 
About in the Host List)?
1.7.1

What type of system are you trying to connect to?
Buffalo Linkstation Pro NAS with Debian 4 ("etch") in my private LAN.

If you are able to connect, what is the output of "echo $TERM", "uname -a",
and any other relevant information on the host?
uname -a:
Linux linkstation 2.6.16.57-lsp_eabi-dh_v3 #1 Sat Jan 26 14:38:06 EST 2008 
armv5tejl GNU/Linux
openssh version: 4.3p2-9etch3

Please provide any additional information below.
Device: HTC HD2 with CyanogenMod 7.2.0 RC0 based ROM (Android 2.3.7).

I expected the "Post-Login automation" to yield the same results that (pocket) 
putty's -m <file with commands> option does (or "Remote command" in the GUI).
See: 
http://the.earth.li/~sgtatham/putty/0.62/htmldoc/Chapter3.html#using-cmdline

When I still had WinMo 6.5 on my HTC HD2 I used pocket putty and everything was 
working as expected. The same holds true for putty on my PC.

I'm unsure whether this is a bug or a feature request because with forced 
commands most servers usually close the connection right after executing the 
forced command. So maybe you cannot call it a real login at all.

Original issue reported on code.google.com by moldowan.android@googlemail.com on 17 Dec 2011 at 6:15

[GoogleCodeExporter]

I need to correct my description a litte:
The command is not "passed" to the script, it needs to appear in the variable 
$SSH_ORIGINAL_COMMAND (see linked binblog.info article).

Please note that one or more of the options in authorized_keys mentioned in the 
binblog.info article cause Connectbot hang before the shellscript can be 
executed:

no-port-forwarding,no-X11-forwarding,no-pty

So you should omit those options to be able to see what the script is doing.
I will try to find out which option is causing the problem and I will 
eventually create another ticket for that issue.

Original comment by moldowan.android@googlemail.com on 17 Dec 2011 at 6:30

[GoogleCodeExporter]

Found the right spot:

In org.connectbot.transport.SSH.finishConnection(), calling 
session.execCommand(...) instead of calling session.startShell() does the trick!

I have yet to figure out how to display the response from the server because 
just "swapping" the two calls results in:

02-11 01:32:46.187: E/ConnectBot.Relay(13107): Problem while handling incoming 
data in relay thread
02-11 01:32:46.187: E/ConnectBot.Relay(13107): java.io.IOException: Remote end 
closed connection
02-11 01:32:46.187: E/ConnectBot.Relay(13107):  at 
org.connectbot.transport.SSH.read(SSH.java:531)
02-11 01:32:46.187: E/ConnectBot.Relay(13107):  at 
org.connectbot.service.Relay.run(Relay.java:116)

Original comment by moldowan.android@googlemail.com on 11 Feb 2012 at 1:45