0

I'm finding when SSHing into UNIX VMs from Windows that the console is next to unusable.

There seem to be 2 main problems:

  1. Escape characters (from colors and cursor keys)
  2. Overwriting of text (mainly in Nano, but also in the terminal)

The first issue seems to be able to be solved by using something like ConEmu.

But the second, I just cannot solve. Using the delete key anywhere, command history in the terminal, or up/down or page-up/down in Nano just overwrites swathes of text, with the result just being a garbled mess of old and new characters.

The only way I've found to update the screen is to use CTRL+L to toggle long lines, but it's not really a solution.

This happens in cmd.exe, Git bash and a few others I've tried. How do normal, sane people manage this (other than use OSX/Linux!) ?

Cheers, Dave

Dave Stewart
  • 125
  • 4
  • 3
    The only real way to save your sanity that I know of is to _not_ attempt to manage Linux/UNIX machines from Windows. – Michael Hampton Oct 14 '15 at 19:25
  • Which is why I've recently given in and bought a Mac. But I don't understand why all these console addons exist if this problem hasn't somehow been solved? – Dave Stewart Oct 14 '15 at 19:31
  • 1
    In your case, I don't know what's going on. ConEmu ought to be at least somewhat usable. But the Windows console itself is largely unchanged since, well, 1985 or so. I don't know of _anyone_ who likes it. – Michael Hampton Oct 14 '15 at 19:33
  • Which ssh client are you using? – Tilman Schmidt Oct 14 '15 at 19:34
  • never had that issue with putty unless I tried to read binary as text. – Jacob Evans Oct 14 '15 at 19:42
  • Just ConEmu which is currently wrapping Windows console I think, into a Vagrant box using "vagrant ssh" (I'm no expert on these matters) – Dave Stewart Oct 14 '15 at 19:42
  • When using the default consoles in windows you shouldn't expect any of the term codes to work since the console is not a terminal emulator. Telnet does provide term emulation. – Jim B Oct 14 '15 at 22:39
  • Looks like I should probably have posted this on SuperUser. My apologies, I usually post things on StackOverflow but didn't think that was the right forum, and my knowledge of the other StackExchange sites is limited. Feel free to kill this post! – Dave Stewart Oct 15 '15 at 09:36

2 Answers2

5

Use Putty or NoMachine, never had any of those issues described with either.

Jacob Evans
  • 7,886
  • 3
  • 29
  • 57
0

Thanks to the rest of the comments, I went the Putty route and found success.

Even though it's more of a faff to actually log in, it solves all the problems I outlined above.

I'm answering my own question, as my use case was for Laravel's Homestead, so I thought it would be useful to share how I did it.

EDIT: I rolled all this info, and some more, into a blog post outlining how to use ConEmu and OpenSSH to fix both problems whilst giving you more functionality than PuTTY alone: http://davestewart.io/blog/fix-windows-broken-ssh-console

Homestead is based on Vagrant, and I found info on how to use Putty with Vagrant here:

https://github.com/Varying-Vagrant-Vagrants/VVV/wiki/Connect-to-Your-Vagrant-Virtual-Machine-with-PuTTY

From testing within Cmder it gave me the clue that it was Windows' own ssh.exe that was the problem, so I simply added Putty as a new console (though you can run it on its own) and upon gaining access to the VM, I tested with Nano, and it "just worked":

enter image description here

I also found I can SSH in using Git's OpenSSH client from the command line.

cd <open ssh folder> ssh vagrant@127.0.0.1 -p 2222

Type "yes" then "vagrant" as the password. Voila! Working Nano.

If you want to save the host then run the command prompt as administrator first.

(Apologies if this is all totally obvious to all you sys admin types!)

Dave Stewart
  • 125
  • 4
  • Windows doesn't come with SSH.exe, its likely that dev. never put telnet into the app (which I suspect is part of the spec for ssh) – Jim B Oct 14 '15 at 22:43
  • 1
    You need to understand that what you have trouble with, is that the Unix system is misinformed about the capabilities of your terminal emulator (CMD.EXE with friends) as it sends the incorrect strings to control it. This is not the fault of your ssh program, but the terminal emulator. You should look into a better terminal emulator. Putty contains its own terminal emulator which works well. – Thorbjørn Ravn Andersen Oct 14 '15 at 22:49
  • @ThorbjørnRavnAndersen cmd.exe is not a terminal emulator, and hasn't been. The old DOS prompt had ANSI drivers available but CMD never did. Telnet and HyperTerminal are the only term emulators that I know of that ever came with windows. I'm not sure how SSH is supposed to handle terminals (if at all) but if its expecting cmd to provide a term, the developer is confused at best. – Jim B Oct 14 '15 at 23:48
  • @JimB CMD.exe accepts a stream of bytes and renders some as characters and some as instructions to do carriage return and line feed and backspace and bell and such. As a good old fashioned paper terminal did. So it emulates a paper terminal.... Unfortunately what we would like it to emulate is a vt100, which it doesn't. – Thorbjørn Ravn Andersen Oct 14 '15 at 23:56
  • Unfortunately the dos version of Kermit was not ported to Windows, but instead a commercial version for win95 was launched. That was the best telnet client for plain dos... – Thorbjørn Ravn Andersen Oct 14 '15 at 23:59
  • @ThorbjørnRavnAndersen. You can use ansicon or another term emulator. CMD doesn't emulate any terminals. See http://superuser.com/a/464852/2849 where this comes up quite often – Jim B Oct 14 '15 at 23:59
  • @ThorbjørnRavnAndersen DOS included ansi.sys to allow the console to interpret ansi term codes. – Jim B Oct 15 '15 at 00:01
  • I know that ansi.sys was needed to get vt100 escape sequences, and that for some obscure reason this wasn't ported to NT. – Thorbjørn Ravn Andersen Oct 15 '15 at 00:04
  • FYI, it seems that terminal emulator solves the escape characters problem, and the alternative SSH client fixes the overwriting problem. – Dave Stewart Oct 15 '15 at 00:04
  • @DaveStewart yup, my only point was that this isn't a windows issue, windows doesn't have native ssh support, you need some sort of terminal support and (like telnet on windows) I'd hope whoever writes a windows ssh included at least basic term support. – Jim B Oct 15 '15 at 00:22
  • @JimB cmd.exe _is_ a terminal editor but a very limited one. – Thorbjørn Ravn Andersen Oct 17 '15 at 22:06
  • @ThorbjørnRavnAndersen Do you have any docs that show that a winstation requires or uses any sort of terminal? Every app I've ever seen for windows since windows for workgroups has required terminal emulation in order to use any sort of TTY connection to unix, VMS, or RSTS. As an example even the venerable telnet command has a terminal emulator built in. – Jim B Oct 18 '15 at 00:45
  • which is because the terminal emulator in CMD.EXE (which interprets things like linefeed, backspace, and carriage return) is too limited for most purposes. Essentially it only emulates a paper terminal (a computer driven typewriter). – Thorbjørn Ravn Andersen Oct 18 '15 at 23:49