Bitvise Software
Mack Mosely
I am using Bitvise SSH Server on my Windows machine for remote access. The login shell is ZSH, and I am using Oh My Zsh with it. However, I have also tried BASH and got the same problem. Therefore I guess this problem is with Bitvise SSH Server, not my Cygwin shells or the client-side terminal emulators.
My assumption is there's some special character defined in the Oh My Zsh theme that is not processed correctly when passing through Bitvise. However I couldn't find out what that is exactly. The Oh My Zsh themes look good locally without a Bitvise SSH connection, and they look good on all Linux machines I have. Therefore I think it should be something with Bitvise.
As suggested in the comments, I ran set in both environments, and got the outputs dumped into two text files: bitvise.txt and local.txt. Now the biggest issue is I cannot compare them using diff because diff claims they are binary files (and they differ). I am not sure if this has something to do with the weird spaces.
The problem seems to be harder than I expected. I found a folder "C:\Program Files\Bitvise SSH Server\TermInfo" which contains the terminal info files. I replaced the files in that folder with the similar files I copied from a normal Ubuntu machine, but didn't help. I also tried the "cygwin" term info that is installed with Cygwin, no luck... Actually the "cygwin" file that comes with Cygwin is the same with the one that comes with Ubuntu...
When I SSH into the Bitvise SSH Server, I can do exec /bin/bash to replace the current session with Bash. However in that Bash, if I SSH into some other Linux machine that uses Zsh and Oh My Zsh, the same problem persists.
For example, a character that has width 0 in MinTTY might have width 1 in the Windows console, and would advance the cursor. Or a character that has width 1 in MinTTY might have width 2 in the Windows console.
Bitvise SSH Server runs your terminal shell in a hidden Windows console, which is necessary to be able to run Windows console programs. Due to this architecture, zsh has to look right in a Windows console in order to render properly via Bitvise SSH Server.
Four weeks later I finally figured out the problem myself. Thanks to denis bider who seems to come from the support team of Bitvise SSH Server. His explanation of on how Bitvise runs shells in Windows console is the key to solve this problem.
The problem I actually had was, the Oh My Zsh themes I am using have characters that are displayed in other ways in my Windows console. However, I found that it was actually because my Windows console code page is set to 936 (Simplified Chinese) because of my Windows local settings (for non-Unicode characters). I found that if I manually change my code page to 437 (U.S. English) in the Bitvise SSH session, the output becomes correct.
Therefore, the solution is to set the default code page of the Bitvise SSH Windows console to 437. This can be done in Registry, more specifically, in key HKCU\Console\Bitvise toterms.exe, there is a CodePage to be set to 437 (decimal). I also removed FaceName because it doesn't sound necessary at all.
However, setting this alone is not enough, because I found everytime a Bitvise SSH session starts, the value is set back to 936. Therefore, I need to change permissions of HKCU\Console\Bitvise toterms.exe to deny writing access from Everyone. Steps: 1. Right click on "Bitvise toterms.exe", and click "Permissions...". In the dialog, click Advanced. In the new dialog, click "Add...", then input "Everyone". Finally, check the following permissions for denied as is shown:
Dear Mike,
First of all Thank you for taking time to help me.
I am a beginner to SFTPs, etc.
I will surely try to run your script but there is a question I want to ask.
In the script you posted, where do we mention the destination folder details?
Because I have a requirement where I need to move some files to a specific folder on a linux server using bitvise.
Bitvise xterm SSH Client not able to open Remote Desktop. All that happens when I try to Remote Desktop connect is that I get a shell as I would when I normally use Bitvise in terminal mode. When I do an startx from the bitvise SSHed in terminal, it launches the Desktop on the linux box (I can see the monitor from my PC station). LOL
I tried this:
The problem is with debian default setup. It sets it up so that only root can log into X. In order to change this you need to edit the /etc/X11/Xwrapper.config file. For the syntax of that, check out the man page for 'Xwrapper.config'. All you need to add is the 'allowed_users=anybody' option.
Why do you want the full desktop?
What are you planning to run in the remote desktop session?
Can you run individual applications in the SSH session?
Did you try PuTTY and enable the X forwarding feature (You seem to have Xming installed and running which is good)
I can run normal commands in the SSH session. I guess I don't exactly understand your question. When I use Bitvise I get a normal terminal and I can run regular command line thing in it. When I try to run GUI stuff it loads on the remote box and does not spawn any kind of XClient. When I use the XLauch, I can then run a terminal in the graphical mode and spam individual apps, but they are messed up with no real title bar. You can see from the screenshot how messed up it is.
I have not tried putty but Bitvise is supposed to support it so I suspect its not a tool problem but a settings problem. It's a perfectly valid SSH client. Bitvise also has an X FOrwarding feature and I have tried to enable that and its failed as well. Bitvise in no way works. Only the XLaunch works but again poorly.
Our products can be used in ways that don't require much knowledge aboutthe internet. You can just type in the address of the server you'reconnecting to, open an SFTP window and start transferring files.However, if you will be using the more advanced features of ourproducts, such as tunneling, you will need to understand the basics ofhow the Internet is structured. This guide is an attempt at relayingsome of that understanding.
Everycomputer connected to the internet has an Internet Protocol or IPaddress which identifies the computer on the internet. In the currentlymost widely used version of the Internet Protocol - version 4 - IPaddresses are 4 bytes long and are expressed in the form nn.nn.nn.nn.Each nn is a number between 0 and 255.
Whenyou connect to a web server to browse a web page, the DNS name of theweb server, e.g. www.bitvise.com, is automatically translated by thesoftware in your machine to an IP address in the nn.nn.nn.nn form. Thisaddress is then used to connect to the actual web server.
IPaddresses are difficult to remember, so the internet provides atranslation service which translates memorable names into associated IPaddresses. This facility is called the Domain Name System orDNS. You use DNS implicitly every time you type in an address such as'www.bitvise.com' - your browser asks your operating system fortranslation into an IP address, and the operating system either returnsa cached result, or inquires with a DNS server operated by your ISP.This server in turn either returns a cached result or inquires withanother DNS server.
Nocomputer is directly connected to every other computer on the internet.Instead, each computer is a member of one or more subnets. Subnets, inturn, are connected to each other by machines called routers orgateways, which belong to multiple subnets, forwarding internet trafficfrom one subnet to the other and reverse.
Inorder to successfully communicate with other computers throughout theinternet, your computer must know what subnet it is part of, so that itknows what IP addresses are outside your local subnet and must berelayed through the gateway. In addition, your computer must of coursealso know the IP address of the gateway.
Public IP addresses. Most IP addresses in the IPv4 address range have the purpose of uniquely identifying a computer on the internet. The IP address 207.155.248.18, for example, is a public IP address that at some point uniquely identified one of the servers hosting the www.bitvise.com website. This is the type of IP address through which a server must be reachable in order to be accessible to computers throughout the internet.
Private subnets. Special ranges of the IPv4 address range have been set aside for use in private networks, where the computers in such a network do not need to be directly accessible from the internet as servers (but may nevertheless access the internet through a gateway, as clients). These ranges include:
TheInternet Protocol itself is a relatively rudimentary protocol whichprovides only the capability of delivering small chunks of data toother computers. The Internet Protocol does not provide reliability:chunks of data that are sent using the Internet Protocol may be lost.They also may arrive in an order different to the order in which thechunks were sent.
For sometypes of data transfer, the (un)reliability afforded by the InternetProtocol is fine. When streaming video, for example, it does not matterif chunks that make up intermediate frames of the video are lost. Whatmatters is that most of the data arrives relatively quickly, allowingthe video to be played with reasonable quality and on the fly. The User Datagram Protocol,or UDP, is a simple protocol layered on top of the Internet Protocolthat provides this level of reliability. UDP is used for purposes suchas relaying video and audio streams as well as for networked games; allenvironments where responsiveness and fast delivery are more importantthan perfect reliability.
Forother types of data transfer, however, this level of reliability is notenough. When transferring a file, for example, you want to transfer allof its contents in perfect order and integrity; you don't want anychunks of it to accidentally be lost. When accessing a web page,likewise, you want all the text to be transferred without error. Datatransfers that require this higher level of reliability use the Transmission Control Protocol,or TCP. Like UDP, TCP is a protocol layered on top of the InternetProtocol, but it is more complex than UDP: it contains mechanisms toensure that data is received in order and that, if any chunks are lost,they are resent. The reliability provided by TCP has costs in terms ofresponsiveness. Before any data can be sent using TCP, the twocomputers must engage in a short back-to-forth to establish a TCPconnection. If any data are lost during transmission, delivery ofsubsequent data awaits until the data that were lost are retransmittedand delivered. When there is a high rate of data loss on a connection,this may cause transmission to be jerky.
64591212e2