One thing I have discovered with all this excercise is that when the 64 bit vers of studio 12.04LTS locks up and freezes on the local machine I can avoid the freeze ups by logging on and running the 64 bit machines via the remote x sessions; have yet to be able to duplicate the freeze ups this way.
when they freeze they lock out CTRL-ALT-Fx so you can't log in to a term session and do an init 6 orderly shutdown. I doubt that I would be able to log in using a remote session to get out of the lock either, but might have access still if I was logged in on a remote session when fault occurred; yet to be confirmed though. On 14/11/12 22:57, Geoff Barkman wrote: > On Ubuntu there is also GSTM - Gnome ssh tunnel manager that you can > graphically do the ssh tunneling and save settings so you don't have > to type in long commands in the terminal. Its available by the Ubuntu > package manager or you can download directly from sourceforge > http://sourceforge.net/projects/gstm/?source=directory > > On Thu, Nov 15, 2012 at 11:17 AM, Florent Peyraud <[email protected]> wrote: >> Hello >> Le 12/11/12 18:52, Fernando Della Torre a écrit : >> >> Hi there! >> >> If you're under ubuntu you can enable the remote desktop (VNC kind) and use >> it through a SSH tunnel. >> >> We in Tryphon are almost using this method, but to avoid having to tune our >> customer's internet modem/router in order to open their SSH port, we usually >> ask them to SSH toward a special 'box' account on our infrastructure with a >> special command line so that all useful ports are 'tunnelled'. For example >> from the target rivendellAllbox they could type : >> >> ssh -p 2722 -N -R2222:localhost:22 -R8888:localhost:80 -R5901:localhost:5900 >> [email protected] >> >> Doing this, we can log on our support server, then connect locally to ports >> 2222, 8888 or 5901 to access respectively remote SSH, HTTP or VNC servers. >> And for our headless boxes, they can do the same, even from MacOS X or >> Windows (with putty) with something like : >> >> ssh -p 2722 -N -R2222:streambox.local:22 -R8888:streambox.local:80 >> [email protected] >> >> The -N option allows to establish the SSH connection even if the 'box' >> account has /bin/false as shell in the /etc/passwd file >> >> As you may imagine, this method suffers from different problems : one could >> try to squat all ports on our server, For the time being, this has never >> append, but we already think of something to randomize the connection port >> for each connection, or map it to our server only when a remote support is >> scheduled... We are not short of ideas ;) >> >> Hope this can help >> Best regards >> >> Florent >> >> >> >> >> >> Atenciosamente, >> >> >> >> Fernando Della Torre >> >> Tecnologia da Informação >> >> (: +55 16 8137-1240 >> >> (: +55 16 9137-2886 >> >> *: [email protected] >> >> V.D.I.T. Soluções em Virtualização >> >> >> >> >> >> A utilização deste e-mail não implica em autorização ou outorga de poderes >> para seu usuário praticar qualquer ato em nome das empresas citadas, cuja >> representação considera-se válida se praticada exclusivamente por >> representante legal ou procurador devidamente constituído, na forma >> estabelecida em seu respectivo estatuto ou contrato social >> >> >> >> >> 2012/11/12 Andy Sayler <[email protected]> >>> Hi Andy, >>> >>> To the best of my knowledge SSH is not designed for "Screen Sharing", and >>> provides no way to do it. >>> >>> When you connect to a remote machine via SSH, you are creating a new user >>> session, completely separate from any local user sessions (or other remote >>> session) already running on the remote machine. When you use SSH with X >>> server forwarding (the -X option), the GUIs are actually being generated on >>> your local machine, not on the remote machine at all (in fact, the remote >>> machine need not even have X installed). The combination of the fact that >>> each SSH session is isolated from other user sessions, and the fact that X >>> over SSH runs locally means that there is no way to "screen share" using >>> SSH. >>> >>> Some terminal multiplexers (i.e. GNU Screen) will allow you to perform >>> terminal "screen sharing" between multiple users, and you can use this in >>> conjunction with SSH to share your shell, but I don't believe the sharing >>> capabilities extend to X sessions and GUIs. >>> >>> If you want a traditional GUI "screen sharing" experience, you'll probably >>> need to seek out a program designed for that purpose like TeamViewer or >>> another remote help/desktop app. If you use Google Chrome, it also offer a >>> multi-platform remote desktop/sharing app: >>> https://chrome.google.com/webstore/detail/chrome-remote-desktop/gbchcmhmhahfdphkhkmpfmihenigjmpp. >>> Some versions of VNC may also support this functionality, but I'm less >>> familiar with that. >>> >>> In short, SSH isn't really designed for sharing your session or screen >>> with local users. You'll have to look for another program if you want to do >>> that. >>> >>> Good luck, >>> Andy >>> WMFO >>> [email protected] >>> www.andysayler.com >>> >>> >>> On Mon, Nov 12, 2012 at 10:09 AM, VE4PER/ Andy <[email protected]> wrote: >>>> Has anyone used ssh connection to actually view a remote desktop as a >>>> way to see and trblshoot w/s problems? >>>> >>>> I use ssh -a -X userid@IPaddress with server running in the w/s allowing >>>> login. It gives me terminal access in real time and allows me to run new >>>> instances of window/GUI pgms remotely, however I am not able to actually >>>> see or share the existing desktop. >>>> >>>> Is there something wrong with the syntax I am using to gain remote >>>> desktop GUI access and control to be able to be more assistance to the >>>> remote operator? >>>> >>>> Have used other viewers as well, yet seem only to be able to run in >>>> console mode or X displays of specific applications rather than viewing >>>> full desktop? >>>> >>>> Thanks >>>> >>>> Andy >>>> _______________________________________________ >>>> Rivendell-dev mailing list >>>> [email protected] >>>> http://lists.rivendellaudio.org/mailman/listinfo/rivendell-dev >>> >>> >>> _______________________________________________ >>> Rivendell-dev mailing list >>> [email protected] >>> http://lists.rivendellaudio.org/mailman/listinfo/rivendell-dev >>> >> >> >> _______________________________________________ >> Rivendell-dev mailing list >> [email protected] >> http://lists.rivendellaudio.org/mailman/listinfo/rivendell-dev >> >> >> >> _______________________________________________ >> Rivendell-dev mailing list >> [email protected] >> http://lists.rivendellaudio.org/mailman/listinfo/rivendell-dev >> > _______________________________________________ > Rivendell-dev mailing list > [email protected] > http://lists.rivendellaudio.org/mailman/listinfo/rivendell-dev > _______________________________________________ Rivendell-dev mailing list [email protected] http://lists.rivendellaudio.org/mailman/listinfo/rivendell-dev
