Remote login... Oh Boy
JD Austin
jd at twingeckos.com
Mon Jul 23 11:24:46 MST 2012
Second on Cygwin...
If you have to use windoze use an X server that has the GNU tools you're
used to :)
On Mon, Jul 23, 2012 at 7:42 AM, kitepilot at kitepilot.com <
kitepilot at kitepilot.com> wrote:
> Xcapable SSH client like Hummingbird.
>>
> NOOOO!!!!
> Cygwin! :)
> ET
>
>
> Lisa Kachold writes:
>
>> Set your local display variable and if the ports are open and OpenX is
>> running, you will get an echoed Xterminal session to open locally. If you
>> are using Windows locally, you will need an Xcapable SSH client like
>> Hummingbird.
>> An X program needs two pieces of information in order to connect to an X
>> display.
>> -
>> It needs the address of the display, which is typically :0 when you're
>> logged in locally or :10, :11, etc. when you're logged in remotely (but
>> the number can change depending on how many X connections are active).
>> The
>> address of the display is normally indicated in the DISPLAY environment
>> variable.
>> -
>> It needs the password for the display. X display passwords are called
>> *magic
>> cookies*. Magic cookies are not specified directly: they are always
>>
>> stored in X authority files, which are a collection of records of the
>> form
>> “display :42 has cookie 123456”. The X authority file is normally
>> indicated in the XAUTHORITY environment variable. If $XAUTHORITY is not
>> set, programs use ~/.Xauthority.
>> You're trying to act on the windows that are displayed on your desktop. If
>> you're the only person using your desktop machine, it's very likely that
>> the display name is :0. Finding the location of the X authority file is
>> harder, because with gdm as set up under Debian squeeze or Ubuntu 10.04,
>> it's in a file with a randomly generated name. (You had no problem before
>> because earlier versions of gdm used the default setting, i.e. cookies
>> stored in ~/.Xauthority.)
>> Getting the values of the variables
>> Here are a few ways to obtain the values of DISPLAY and XAUTHORITY:
>> -
>> You can systematically start a screen session from your desktop,
>> perhaps
>> automatically in your login scripts (from ~/.profile; but do it only if
>> logging in under X: test if DISPLAY is set to a value beginning
>> with :(that should cover all the cases you're likely to encounter)).
>> In
>> ~/.profile:
>> case $DISPLAY in
>> :*) screen -S local -d -m;;
>> esac
>> Then, in the ssh session:
>> screen -d -r local
>> -
>> You could also save the values of DISPLAY and XAUTHORITY in a file and
>> recall the values. In ~/.profile:
>> case $DISPLAY in
>> :*) export | grep -E ' (DISPLAY|XAUTHORITY)='
>>
>>> ~/.local-display-coordinates.**sh;;
>>>
>> esac
>> In the ssh session:
>> . ~/.local-display-coordinates.**sh
>> screen
>> -
>> You could detect the values of DISPLAY and XAUTHORITY from a running
>> process. This is harder to automate. You have to figure out the PID of
>> a
>> process that's connected to the display you want to work on, then get
>> the
>> environment variables from /proc/$pid/environ (eval export
>> $(</proc/$pid/environ tr \\0 \\n | grep -E
>> '^(DISPLAY|XAUTHORITY)=')¹).
>> Copying the cookies
>> Another approach is to not try to obtain the value of $XAUTHORITY in the
>> ssh session, but instead to make the X session copy its cookies into
>> ~/.Xauthority. Since the cookies are generated each time you log in, it's
>> not a problem if you keep stale values in ~/.Xauthority.
>> There can be a security issue if your home directory is accessible over
>> NFS
>> or other network file system that allows remote administrators to view its
>> contents. They'd still need to connect to your machine somehow, unless
>> you've enabled X TCP connections (Debian has them off by default). So for
>> most people, this either does not apply (no NFS) or is not a problem (no X
>> TCP connections).
>> To copy cookies when you log into your desktop X session, add the
>> following
>> lines to ~/.xprofile or ~/.profile (or some other script that is read when
>> you log in):
>> case $DISPLAY:$XAUTHORITY in
>> :*:?*)
>> # DISPLAY is set and points to a local display, and XAUTHORITY is
>> # set, so merge the contents of `$XAUTHORITY` into ~/.Xauthority.
>> XAUTHORITY=~/.Xauthority xauth merge "$XAUTHORITY";;
>> esac
>> ¹ In principle this lacks proper quoting, but in this specific instance
>> $DISPLAY and $XAUTHORITY won't contain any shell metacharacter.
>>
>> On Sun, Jul 22, 2012 at 1:03 PM, Joseph Sinclair
>> <plug-discussion at stcaz.net>**wrote:
>>
>>> The closest to your old rlogin approach would be "ssh -X
>>> yourserver.ip.address <x program to run, e.g. meld>" you might need to
>>> fiddle with some settings to get it working, however.
>>> On 07/22/2012 12:56 PM, Stephen wrote:
>>> > ssh transfers i think would be the fastest/easiest. there are some gui
>>> > clients that can do this.
>>> >
>>> > On Sun, Jul 22, 2012 at 12:55 PM, Wayne Davis
>>> > <waydavis.phx.lists at gmail.com> wrote:
>>> >> Ok,
>>> >>
>>> >> Years ago, when i worked for frontier global-center, I remember that
>>> we
>>> >> could "rlogin" to a system and "Startx". At least I REMEMBER it this
>>> way.
>>> >> My recollection was that I was running the GUI LOCALLY and metatdata
>>> was
>>> >> being transferred across. VERY fast & efficient screens.
>>> >>
>>> >> A: AM I recalling wrongly?
>>> >> B: I'm wanting to set up a server box on my network for files,
>>> music,
>>> >> video that will be headless (No monitor or mouse connected)
>>> >>
>>> >> Running Kubuntu 12.04 as primary OS on all boxes here.
>>> >> I see rlogin, ssh, blah blah blah.......
>>> >>
>>> >>
>>> >> I'm looking for EFFICIENT GUI presentation, File transfers.
>>> >>
>>> >> xvnc11 works but is slow, teamviewer is making connections outside my
>>> >> network to operate AND is wine based :-(
>>> >>
>>> >> What should I use that will keep it S I M P L E (if possible) and
>>> secure (
>>> >> I am behind a M0n0wall WRAP firewall) I want to be able to connect at
>>> will.
>>> >>
>>> >>
>>> >> Is this going to be a major pain?
>>> >>
>>> >>
>>> >> Thanks everyone for your thoughts :-)
>>> >>
>>> >> ------------------------------**---------------------
>>> >> PLUG-discuss mailing list - PLUG-discuss at lists.plug.**phoenix.az.us<PLUG-discuss at lists.plug.phoenix.az.us>
>>> >> To subscribe, unsubscribe, or to change your mail settings:
>>> >> http://lists.PLUG.phoenix.az.**us/mailman/listinfo/plug-**discuss<http://lists.PLUG.phoenix.az.us/mailman/listinfo/plug-discuss>
>>> >
>>> >
>>> >
>>>
>>> ------------------------------**---------------------
>>> PLUG-discuss mailing list - PLUG-discuss at lists.plug.**phoenix.az.us<PLUG-discuss at lists.plug.phoenix.az.us>
>>> To subscribe, unsubscribe, or to change your mail settings:
>>> http://lists.PLUG.phoenix.az.**us/mailman/listinfo/plug-**discuss<http://lists.PLUG.phoenix.az.us/mailman/listinfo/plug-discuss>
>>>
>>
>>
>> --
>> (503) 754-4452 Android
>> (623) 239-3392 Skype
>> (623) 688-3392 Google Voice
>> **
>> <http://it-clowns.com>Safeway.**com
>> Automation Engineer
>>
> ------------------------------**---------------------
> PLUG-discuss mailing list - PLUG-discuss at lists.plug.**phoenix.az.us<PLUG-discuss at lists.plug.phoenix.az.us>
> To subscribe, unsubscribe, or to change your mail settings:
> http://lists.PLUG.phoenix.az.**us/mailman/listinfo/plug-**discuss<http://lists.PLUG.phoenix.az.us/mailman/listinfo/plug-discuss>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.PLUG.phoenix.az.us/pipermail/plug-discuss/attachments/20120723/d0528b70/attachment.html>
More information about the PLUG-discuss
mailing list