Note: IP is the local workstation’s IP where you want the GUI If you still get the “cannot open display” error, set the DISPLAY You can open any GUI application which will open it without any issue. $ ssh -XĮnable trusted X11 forwarding, by using the -Y option, $ ssh -YĪfter opening ssh connection to the remote host as explained above, While doing ssh use the option -X to enable X11 forwarding. $ xhost +Īccess control disabled, clients can connect from any host You can allow clients to connect from any host. Folks who use DSL usually have no trouble keeping a tunnel "on", while cable users like myself find that tunnels collapse within 10 minutes of being launched.įor all my criticisms, I would like to reiterate that this is a great little program that puts an easy-to-use GUI in front of the user for a powerful built-in CLI package that can be more than a bit daunting.From xhost+ : How to Fix “Cannot Open Display” Error While Launching GUI on Remote Server:Īnswer: You can fix the “cannot open display” error by following the xhost procedure mentioned in this article.Īllow clients to connect from any host using xhost+Įxecute the following command to disable the access control, by which Lastly, once a tunnel is up, it would be fantastic if Tunnel Builder could incorporate code from the freeware autoSSH to maintain that tunnel. The current incarnation only shows on/off - and "on" may or may not be "on". My only criticism of this program is that it will show a tunnel as "on" when it may not be.įurthermore, it would be great if the program could incorporate a color scheme that reflected the status of the three tunnel states: "off", "building", and "on". Furthermore, it offers support for multiple tunnels to multiple machines that are easy to start and stop. I like SSH Tunnel Manager because it is easy to set up and it offers a simple interface to configure the tunnels just as you want them. I use it to establish secure tunnels to and from my mail server. Best of all, it's free, so a big hat off to Yann Tynsoe for developing it in the first place.įor the most part, this program does everything it promises. While all the functions in SSHTB can be executed with CLI scripts, this has to be the easiest way to secure your connections with SSH. Nothing takes away from the fact that this is a great program for those of us who like to keep their internet connections secure. Lastly, it would have been nice if SSHTB2 could have imported the prior preference file instead of forcing the user to enter the data all over again. Silly rabbit, you were supposed to hit enter first! If you finish a line and then hit the "add" button, the line gets erased and you get to start over. Also, AutoSSH would re-establish broken connections automatically once the machine is hooked back up to the internet.Ī minor quibble is the somewhat unintuitive data entry for new tunnels. It would be great if SSHTB could incorporate the open-source code for AutoSSH, since that would eliminate a number of issues like the one mentioned above. IIRC, there are provisions within the SSH protocol to detect broken LAN connections. even three minutes after shutting off my connection to the internet, the tunnel is still being shown as "Connected". However, SSHTunnel is still having trouble detecting when tunnels are broken. It even shows the various port-forwarding connections being made. The new revision adds some great features! The tunnel now shows the connection being built, with several visual cues - red for no tunnel, yellow for tunnel startup, green for working tunnel. Thus, there seems to be a bug in SSHTB 2.0b that affects my machine (PBG4, OS 10.3.2). In comparison, version 1.03 allows me to leave the same tunnels open all day, as long as I have some activity every 2 minutes or so. I have reverted to 1.03 in the meantime since being on the bleeding edge has left me SSH-less. I had to restart the PB before SSHTB would work again. My underlying SSH components seem to be OK because I'd still be able to SSH in via the terminal application.Įven closing the tunnel manually and quitting SSHTB would not work. Rebuilding tunnels after a collapse would not work consistently - even though the application shows a working tunnel (i.e. I noticed this mainly in extended use - the SSH tunnels would collapse without warning, followed by beachballs of death in the applications dependant on port forwarding (mail, http, etc.) However, for whatever reason the new tunnel manager does not appear to be as stable maintaining tunnels as the older 1.03 client. I stand by my earlier review regarding the new interface.
0 Comments
Leave a Reply. |