Re: Remote login... Oh Boy

Top Page
Attachments:
Message as email
+ (text/plain)
+ (text/html)
+ (text/plain)
Delete this message
Reply to this message
Author: Derek Trotter
Date:  
To: Main PLUG discussion list
Subject: Re: Remote login... Oh Boy
Here at home I have a linux box and a windows box. I installed xming on
the windows box and configured the linux box to allow logins from a
remote x server. I used putty for the ssh connection from the windows
box. On my windows box I can have either the whole desktop from the
linux box or an individual program. It was easy to set up. If I can
set it up it has to be easy.

On 7/23/2012 11:24, JD Austin wrote:
> 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,
> <mailto:kitepilot@kitepilot.com> <
> <mailto:kitepilot@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
>         <
>         <mailto:plug-discussion@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
>             > <
>             <mailto:waydavis.phx.lists@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 -
>             
>             <mailto:PLUG-discuss@lists.plug.phoenix.az.us>
>             >> To subscribe, unsubscribe, or to change your mail settings:

>             >>
>             http://lists.PLUG.phoenix.az.us/mailman/listinfo/plug-discuss

>             >

>             >

>             >

>
>             ---------------------------------------------------
>             PLUG-discuss mailing list -
>             
>             <mailto:PLUG-discuss@lists.plug.phoenix.az.us>
>             To subscribe, unsubscribe, or to change your mail settings:
>             http://lists.PLUG.phoenix.az.us/mailman/listinfo/plug-discuss

>
>
>
>         -- 
>         (503) 754-4452 <tel:%28503%29%20754-4452> Android
>         (623) 239-3392 <tel:%28623%29%20239-3392> Skype
>         (623) 688-3392 <tel:%28623%29%20688-3392> Google Voice
>         **
>         <http://it-clowns.com>Safeway.com
>         Automation Engineer

>
>     ---------------------------------------------------
>     PLUG-discuss mailing list - 
>     <mailto:PLUG-discuss@lists.plug.phoenix.az.us>
>     To subscribe, unsubscribe, or to change your mail settings:
>     http://lists.PLUG.phoenix.az.us/mailman/listinfo/plug-discuss

>
>
>
>
> ---------------------------------------------------
> PLUG-discuss mailing list -
> To subscribe, unsubscribe, or to change your mail settings:
> http://lists.PLUG.phoenix.az.us/mailman/listinfo/plug-discuss


---------------------------------------------------
PLUG-discuss mailing list -
To subscribe, unsubscribe, or to change your mail settings:
http://lists.PLUG.phoenix.az.us/mailman/listinfo/plug-discuss