Shell output limited to 80x24 and prompt wraps

[jimcovert]

When I am connected to a tunnel using Core Tunnel and I establish an ssh session to the same remote bastion host that Core Tunnel is connected to the output in my terminal sessions becomes wonky. For example, the output of the top command is limited to 80x24 characters, scroll back in a terminal session becomes unpredictable, and my prompt on the remote host wraps over itself and becomes similarly unpredictable - making it very difficult to discern what commands and options I'm running.

I'm able to reproduce this in both the built-in apple Terminal.app and iTerm2 - both display the same behavior.

When I connect to these same bastion hosts via ssh - without using Core Tunnel - this behavior does not occur - it only happens when I'm using Core Tunnel, and as soon as I close that Core Tunnel connection I'm able to establish my own connection using ssh and none of the odd shell behavior occurs.

the screenshot below shows how the terminal output for top is restricted to 80x24 characters - this session is running over a connection established by Core Tunnel:

I'm limited to the amount of screenshots I can attach so I'm going to attempt to share other screenshots in replies to this post.

[jimcovert]

while this screenshot is running over a connection that was established outside of Core Tunnel. It's the same identically-sized window as the previous screenshot, but in a different tab.

[jimcovert]

this screenshot is attempting to show the weird behavior of the prompt and how it wraps - this is happening in the session which is using the tunnel established by Core Tunnel:

[jimcovert]

finally, the below screenshot shows how when I'm in the terminal session that runs over a connection that was established outside of core tunnel the same problem with the bash prompt does not occur - the text I write wraps as expected:

[yang (Yang.Y)]

Hi Jim,

Thank you very much for the detailed information
Since version 3.0 is on the way, I'll investigate and try to fix it in version 3.1.

Kindly Regards,

Yang

[mikael.fransson]

I have my ssh entries configured in ~/.ssh/config and referenced in Core Tunnel and I can't reproduce the issue you see. It works just fine.

This is my blog about ssh config entries, Simplify your day with SSH config file entries and self closing tunnels | A-Team Chronicles

This is a sample of my config file used now

# $HOME/.ssh/config
#
# Permissions: User R/W, NOT Writable by others
# chmod 700 $HOME/.ssh
# chmod 600 $HOME/.ssh/config

Host *
IdentityFile ~/.ssh/id_rsa
AddKeysToAgent yes
ServerAliveInterval 240
ServerAliveCountMax 2
TCPKeepAlive yes

Host ol8
	IdentityFile ~/.ssh/personal/id_rsa
	User opc
	Port 22
	HostName nnn.nnn.nnn.nnn

Clicking the open shell and using that terminal works just fine for me

[jimcovert]

We use proxy forwarding on all our jumpgates/bastion hosts, and this config was in place long before I started using Core Tunnel. Core Tunnel rendered the sections like this unnecessary but I have left them in place in the event that I want to connect without using Core Tunnel.

Host ssh.name-redacted-1.com
  LocalForward 2001 127.0.0.1:8080

below is my complete ~/.ssh/config, with domains and hostnames redacted.

ControlMaster auto
ControlPath   ~/.ssh/tmp/%C

Host *
 ServerAliveCountMax 10
 ServerAliveInterval 180
 UseRoaming no
 AddKeysToAgent yes
 UseKeychain yes
 IdentityFile ~/.ssh/id_rsa

Host ssh.name-redacted-1.com
  LocalForward 2001 127.0.0.1:8080
Host ssh.name-redacted-2.net
  LocalForward 2002 127.0.0.1:8080
Host ssh.name-redacted-3.com
  LocalForward 2003 127.0.0.1:8080
Host ssh.us-dev-1.name-redacted-4.com
  LocalForward 2004 127.0.0.1:8080
Host ssh.us-west-2.devname-redacted-4.com
  LocalForward 2004 127.0.0.1:8080
Host ssh.us-staging-1.name-redacted-4.com
  LocalForward 2005 127.0.0.1:8080
Host ssh.us-west-2.stagingredacted.com
  LocalForward 2005 127.0.0.1:8080
Host ssh.us-1.name-redacted-4.com
  LocalForward 2006 127.0.0.1:8080
Host ssh.us-west-2.name-redacted-4.com
  LocalForward 2006 127.0.0.1:8080
Host ssh.ca-1.name-redacted-5.com
  LocalForward 2007 127.0.0.1:8080
Host ssh.ca-1.name-redacted-4.com
  LocalForward 2007 127.0.0.1:8080
Host ssh.ca.name-redacted.name-redacted.com
  LocalForward 2007 127.0.0.1:8080
Host ssh.ap-1.name-redacted.com
  LocalForward 2008 127.0.0.1:8080
Host ssh.ap-1.name-redacted-4.com
  LocalForward 2008 127.0.0.1:8080
Host ssh.au.name-redacted.name-redacted.com
  LocalForward 2008 127.0.0.0:8080
Host localhost
  DynamicForward 2009
Host ssh.emea-1.name-redacted-4.com
  LocalForward 2010 127.0.0.1:8080

Host *.compute.internal
  StrictHostKeyChecking no
  UserKnownHostsFile /dev/null

[jimcovert]

I upgraded to Core Tunnel 3.0.1 today, but unfortunately the behavior with this version is identical to the behavior with the version in the 2.x release family - my shell output takes up a fraction of the window and my bash prompt overlaps itself when its length exceeds 80 characters.

[jimcovert]

for what it's worth the "open shell" link isn't clickable for me, but I assume that's because I'm using the built-in terminal.app rather than core shell. As mentioned before I am seeing the exact same behavior in iTerm

[jimcovert]

I have a coworker who was able to reproduce this issue, and he made some more progress on investigating the cause-

specifically telling the stty size on the remote host does allow it to take up the entire window of your terminal session, and it prevents the command line from wrapping at 80 characters and becoming garbled:

stty cols 145 rows 40

but it's not dynamic so you'd keep need to adjusting that if you adjust your terminal window size.

he also confirmed that disabling terminal multiplexing in the ssh_config prevents this from happening, but it also means that you're not benefiting from the greatness that you get from multiplexing.

Finally, I confirmed that leaving multiplexing enabled in ssh_config but disabling it in Core Tunnel prevents this problem from happening. The downside is that I have to do a separate auth and 2fa to a bastion host, but then I can establish multiple subsequent sessions to that same bastion host without going through the initial auth and the 2fa process because it's using the already existing multiplexed connection.

It's still confusing to me why core tunnel would be impacting the stty display size, but at least I have found a reasonable workaround. I may keep tinkering with this to see if I can identify a better solution.

[yang (Yang.Y)]

Hi Jim, thank you and your coworker so much for the detailed information. I'm going to investigate this issue and send you a beta binary in next couple of days.

Yang

[bmorgenthaler]

@jimcovert

arted using Core Tunnel. Core Tunnel rendered the sections like this unnecessary but I have left them in place in the event that I want to connect without using Core Tunnel.

I've been experiencing this as well. If I connect to one of my hosts though the tunnels established by Core Tunnel I'm stuck in an 80x24 terminal size. I can confirm too that it is related to multiplexing.

[yang (Yang.Y)]

We just released Core Tunnel 3.5 Beta, and invited you join our Beta Program.

The terminal size issue was caused by defective ssh multiplexing support. Core Tunnel 3.5 beta now gains full support for multiplexing directives (i.e. ControlPath and ControlMaster).

Please let me know if you find any bugs on this feature.

Thanks you very much for reporting the issue.

Yang

[jimcovert]

Excellent - I've only been using this for ~10 min but so far, so good. I'll report back later today or tomorrow with what I find!

[jimcovert]

I've had no issues so far with this beta version - nice work with the fix!!!