Hangs when SSH-ing into Solaris shells after login

[GoogleCodeExporter]

What steps will reproduce the problem?
 1. Get shellinabox hosted on a Linux box
 2. Log in to that machine using shellinabox
 3. ssh somesolarisbox.com, authenticate

What is the expected output? What do you see instead?
 I expect to see bash/zsh/whatever on the Solaris box. Instead, the 
tab/window in my browser seems to stop responding key presses.

What version of the product are you using? On what operating system?
 2.10-1 on Debian Lenny (i386) from the .deb provided at code.google.com.

Please provide any additional information below.
 I have tried connecting to Solaris 10 and Opensolaris snv111 and snv133
machines using FireFox 3.5, 3.6, Opera 10.10, and Safari 4.

Original issue reported on code.google.com by tmcre...@gmail.com on 11 Mar 2010 at 1:45

[GoogleCodeExporter]

I can also confirm this problem with multiple different systems.

Also Shell in a box will not build on Solaris. So shell in a box will not work 
in anyway with solaris.

Original comment by joonas.t...@gmail.com on 19 Mar 2010 at 11:44

[GoogleCodeExporter]

Maybe it's related to termcap/terminfo and how it's processed by BSD and 
Solaris?  I know a lot of older systems complain about something as common as 
TERM=rxvt-unicode, so maybe changing the value of shellinabox's $TERM would fix 
it?

Original comment by jonathan...@gmail.com on 6 Jun 2011 at 9:56

[GoogleCodeExporter]

After connection from Linux (OEL6) to Solaris (11) and no output is given, the 
commands are processed!
When you issue 'exit' right after login to Solaris, the output is 'Connection 
to w.x.y.z closed.' (probably more will work to...)

SSH-ing with putty from Linux to Solaris works, so it seems only the processing 
off output from Solaris.

Original comment by ian.hoog...@gmail.com on 9 Dec 2011 at 12:00

[GoogleCodeExporter]

Has there been any movement on this bug?

I can confirm this bug exists with Shellinabox running on Debian 6 and CentOS 6 
when connecting to a Solaris 10 host. Problem exists if the shellinabox service 
is LOGIN or SSH.

Original comment by ja...@ring.gs on 6 Feb 2012 at 11:54

[GoogleCodeExporter]

Additionally, if Shellinabox is configured to SSH directly to a Solaris host, 
ala -s /:SSH:solaris.host.net it also fails.  (same behaviour as if logging 
into a Linux host and then ssh'ing to the Solaris host)

From my investigations I think it may be todo with the way Shellinabox does 
STDIN/STDOUT redirection. But I havent looked too deeply at the source code.

Original comment by ja...@ring.gs on 7 Feb 2012 at 12:26

[GoogleCodeExporter]

Further, telnet to a Solaris 11 host works fine.

Original comment by ja...@ring.gs on 7 Feb 2012 at 6:35

[GoogleCodeExporter]

Further. Running a telnet server on the Linux based Shellinabox server, and 
telnetting to localhost then SSH'ing to a Solaris host works fine.

As a stop gap, anyone else experiencing this bug may try this if your local 
security policy allows it:

Run a telnet server on localhost
Setup shellinabox to run telnet localhost as an unprivileged user rather than 
/bin/login

Original comment by ja...@ring.gs on 12 Feb 2012 at 9:22

[GoogleCodeExporter]

We use this work-around to make it works

- run shellinaboxd, putting a script that make a remote connection as first 
task to do
- when an user call shellinabox, that script makes a telnet connection on 
localhost
- then, using expect (bash scripting on *unix), the script makes a ssh 
connection on Solaris remote host

I hope this information could help someone (this problem make us crazy)

Original comment by valerio....@gmail.com on 6 Mar 2012 at 1:05

[GoogleCodeExporter]

I figured out the solution for this bug.  If you login to Linux and run stty, 
the terminal speed is 0.  Linux accepts this, but Solaris takes a baud speed of 
0 literally and sends/receives no characters (hangs).

There are problems with launcher.c.  First of all, the usage of 
cfsetispeed/cfsetospeed() is dubious.  The second argument requires a type 
speed_t, which is not just a standard integer.  These are #defined macros.  So 
instead of 38400, we really want B38400 (which does not expand to the integer 
38400 by the way).

Secondly, the calls to cfset*speed() aren't working as expected at all.  The 
only way I could get the terminal speed set properly was to include "| B38400" 
in the tt.c_cflag list.  Once the terminal speed is set to something sane like 
38400, running stty after login to a Linux box should also show this speed.  
And thus when connecting to Solaris, it will in turn get that speed as well.  
And the hang should go away.

Finally (unrelated to this bug), Solaris 10 doesn't like ^? for the backspace 
key.  The default on Solaris 10 is ^H.  So this patch also includes a fix for 
that, but only for launcher.c.  I believe more needs to be done with vt100.jspp 
before ^H works properly.  An improvement would be a way to toggle this in 
configure so it hits all necessary files.  Not everyone uses Linux exclusively 
and not everyone agrees that ^? should be backspace.  I know it's easy to fix 
with stty, but a Solaris (or even HP-UX) shop typically likes to use ^H across 
the board.  Feel free to remove the VERASE portion of the patch if you do not 
want this.

Patch:
--- shellinabox-2.14/shellinabox/launcher.c.orig 2012-08-18 00:49:59.816968852 
-0400
+++ shellinabox-2.14/shellinabox/launcher.c 2012-08-27 18:56:12.966625229 -0400
@@ -1479,13 +1480,14 @@
// Set initial terminal settings
struct termios tt = { 0 };
tcgetattr(0, &tt);
- cfsetispeed(&tt, 38400);
- cfsetospeed(&tt, 38400);
+ cfsetispeed(&tt, B38400);
+ cfsetospeed(&tt, B38400);
tt.c_iflag = TTYDEF_IFLAG & ~ISTRIP;
tt.c_oflag = TTYDEF_OFLAG;
tt.c_lflag = TTYDEF_LFLAG;
- tt.c_cflag = (TTYDEF_CFLAG & ~(CS7|PARENB|HUPCL)) | CS8;
- tt.c_cc[VERASE] = '\x7F';
+ tt.c_cflag = (TTYDEF_CFLAG & ~(CS7|PARENB|HUPCL)) | CS8 | B38400;
+ //tt.c_cc[VERASE] = '\x7F';
+ tt.c_cc[VERASE] = '\x08';
tcsetattr(0, TCSAFLUSH, &tt);

// Assert root privileges in order to update utmp entry.

Original comment by storm...@yahoo.com on 6 Sep 2012 at 10:57

[GoogleCodeExporter]

Very much thanks for this solution!

Works like a charm! :)

Original comment by afteixe...@gmail.com on 22 Jan 2013 at 8:02

[GoogleCodeExporter]

The patch as given doesn't look right for inclusion.  According to the termios 
man page, the inclusion of B38400 in the c_cflag is not POSIX.  If someone who 
can test this is able to include

  cfsetspeed(&tt, B38400)

and observe that it solves the Solaris hang then I'll include it in an update.

BTW, the ^H/DEL change isn't likely to make everyone happy.  I'm pretty sure 
you can work around this by changing the local terminal settings for the 
Solaris session.

Original comment by beewoo...@gmail.com on 28 Nov 2013 at 7:19

[GoogleCodeExporter]

We've had both of those fixes (cfsetspeed and the ^H/DEL one) in production
for a year or so now without any observed issues accessing Solaris 10 and
EL5/EL6 hosts.

Original comment by ja...@ring.gs on 28 Nov 2013 at 7:47

[GoogleCodeExporter]

Hi,

here is a POSIX compliant patch for setting default terminal speed. We have to 
call
cfsetospeed() after we change c_cflag, otherwise speed setting can be 
overwritten.

This is also integrated in our new fork on github:
https://github.com/shellinabox/shellinabox/ 

@@ -1509,13 +1509,13 @@ static void childProcess(struct Service *service, int 
width, int height,
   // Set initial terminal settings
   struct termios tt = { 0 };
   tcgetattr(0, &tt);
-  cfsetispeed(&tt, 38400);
-  cfsetospeed(&tt, 38400);
   tt.c_iflag = TTYDEF_IFLAG & ~ISTRIP;
   tt.c_oflag = TTYDEF_OFLAG;
   tt.c_lflag = TTYDEF_LFLAG;
   tt.c_cflag = (TTYDEF_CFLAG & ~(CS7|PARENB|HUPCL)) | CS8;
   tt.c_cc[VERASE] = '\x7F';
+  cfsetispeed(&tt, B38400);
+  cfsetospeed(&tt, B38400);
   tcsetattr(0, TCSAFLUSH, &tt);

   // Assert root privileges in order to update utmp entry.

Original comment by luka.kra...@gmail.com on 11 Mar 2015 at 9:03